Note that fully hidden groups stay out of GROUP_DESCRIPTIONS
Following the rule as written is what put apply back in the top-level group listing right after every command in it was hidden: the table drives that listing on its own, with no regard for whether anything in the group is visible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
536fcd5c6c
commit
0d45f0979b
@@ -24,7 +24,9 @@ matching guide before starting:
|
|||||||
|
|
||||||
All commands start with `omarchy-`. Prefixes indicate purpose.
|
All commands start with `omarchy-`. Prefixes indicate purpose.
|
||||||
|
|
||||||
The authoritative command group list lives in `bin/omarchy` in `GROUP_DESCRIPTIONS`. Keep `GROUP_DESCRIPTIONS` updated when adding a new command prefix.
|
The authoritative list of user-facing command groups lives in `bin/omarchy` in `GROUP_DESCRIPTIONS`. Keep `GROUP_DESCRIPTIONS` updated when adding a new command prefix users are meant to browse to.
|
||||||
|
|
||||||
|
A group whose commands are all `# omarchy:hidden=true` gets no entry. That table drives the top-level group listing on its own, so an entry there advertises the group even when every command in it is hidden. `apply-` and `provision-` are deliberately absent for that reason; both still route, and `omarchy <group>` still prints a group header without one.
|
||||||
|
|
||||||
Common prefixes include:
|
Common prefixes include:
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user