Cobra CLI Command Grouping and Gating · Entire
Check if Cobra Golang CLI Tooling Allows Command Grouping
Yes. Cobra has cobra.Group — groups commands in help output without nesting them under shared parent.
How:
rootCmd.AddGroup(&cobra.Group{ID: "auth", Title: "Authentication:"})
loginCmd.GroupID = "auth"
logoutCmd.GroupID = "auth"
rootCmd.AddCommand(loginCmd, logoutCmd)
login and logout stay top-level commands (entire login, not entire auth login), but help lists them under "Authentication:" header.
Rules:
- Set
Group.ID, reference via childGroupID. AddGroupon parent before adding grouped children, else Cobra panics at help render.- Built-in
help/completiongroups: set withSetHelpCommandGroupID/SetCompletionCommandGroupID.
Limits:
- Pure display grouping. No shared flags, no shared
PreRun, no invocation nesting. - One level — group headers in one command's help list. Not hierarchical.
Summary
This repo already uses real parent groups (session, checkpoint) for canonical paths + hidden top-level shortcuts. cobra.Group = alternative when you want flat commands but grouped help.
Brainstorming Ideas Into Designs
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
Process
- Explore project context — check files, docs, recent commits.
- Ask clarifying questions — one at a time, understand purpose/constraints/success criteria.
- Propose 2-3 approaches — with trade-offs and your recommendation.
- Present design — in sections scaled to their complexity, get user approval after each section.
- Write design doc — save to
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.mdand commit. - Spec self-review — quick inline check for placeholders, contradictions, ambiguity, scope.
- User reviews written spec — ask user to review spec file before proceeding.
- Transition to implementation — invoke writing-plans skill to create implementation plan.
Key Principles
- One question at a time - Don't overwhelm with multiple questions.
- Multiple choice preferred - Easier to answer than open-ended when possible.
- YAGNI ruthlessly - Remove unnecessary features from all designs.
Experimental Candidates
Here's the full hidden inventory, split into Experimental candidates vs Leave-alone:
| Command | File | Note |
|---|---|---|
experts |
experts_cmd.go | has --tui |
search |
search_cmd.go | top-level, no hint |
tokens / tokens profile |
tokens_profile.go | already under labs |
investigate |
investigate/cmd.go | explicitly "hidden while maturing" |
review |
review/cmd.go | explicitly "hidden while maturing" |
import |
import_cmd.go | |
blame / why |
attribution.go | attribution subtree |
runner |
runner_group.go | |
checkpoint policy |
checkpoint_policy.go | ⚠️ subcommand of checkpoint, not root |
Action
Which do you want in the gated experimental set? (default recommendation: experts, search, tokens, investigate, review, import).