SKILL.md
CLI Consistency Review
Systematic review of a CLI tool's command interface to ensure consistent naming, conventions, and documentation alignment.
Workflow
Step 1: Inventory Commands
- Run the CLI with
--helpor-hto get the top-level command list - For each subcommand, run
<cmd> <subcmd> --helpto get its full interface - Build an inventory table:
| Command | Positional Args | Flags | Output Formats |
|---------------|------------------|--------------------|----------------|
| pull | owner/repo | --issues, --prs | table, json |
| search | [query] | --type, --limit | fzf |
| prune | owner/repo | --confirm, --dry-run| table |
Step 2: Convention Analysis
Check for consistency across all commands:
- Positional vs Flag arguments:
- Is the same concept (e.g., owner/repo) passed as positional in some commands and as --repo flag in others? - Recommendation: Pick one approach and apply everywhere
- Flag naming:
- Are similar concepts named consistently? (e.g., --output vs --format vs -o) - Do boolean flags follow the same pattern? (--dry-run vs --confirm vs --yes) - Are shorthand flags (-f, -o) assigned consistently?
- Pluralization:
- Subcommand names: singular vs plural (e.g., list files vs list file) - Flag names: --issue vs --issues
- Default behaviors:
- Are defaults consistent? (e.g., if one command defaults to --format=table, do others?) - Are destructive commands safe by default? (require --confirm or --force)
- Error messages:
- Do error messages follow a consistent format? - Are they actionable (tell the user what to do)?
Step 3: Documentation Alignment
- Compare the README documentation with actual
--helpoutput:
- Are all commands documented? - Do the documented flags match the actual implementation? - Are examples up to date and runnable?
- Check help text quality:
- Does each command have a one-line description? - Are flag descriptions clear and consistent in style? - Do examples in --help text work?
Step 4: Report
Present findings:
CLI Consistency Review:
Inconsistencies Found:
1. [Issue] — [Commands affected] — [Suggested fix]
2. ...
Documentation Gaps:
1. [What's missing] — [Where]
2. ...
Recommendations:
1. [Convention to adopt] — [Rationale]
2. ...
Step 5: Apply Fixes
For each accepted fix:
- Update the command implementation (flag names, defaults, etc.)
- Update help text and descriptions
- Update README to match
- Run
--helpagain to verify alignment
Best Practices Reference
- Positional arguments: Use for the primary subject (e.g.,
owner/repo). Limit to 1-2 positional args. - Flags: Use for modifiers and options. Always provide
--long-form; add-sshorthand only for frequently used flags. - Boolean flags: Use
--flagto enable (default off). For "default on" behaviors, use--no-flagto disable. - Output format: If supporting multiple formats, use
--format=table|json|yamlconsistently. - Destructive operations: Default to dry-run or require explicit
--confirm. - Verbosity: Use
--verbose/-vconsistently. Consider--quiet/-qas well.
Examples
Example 1: Full CLI review
User: "review our cli arguments and make sure they are aligned"
Action:
1. Run --help for all commands
2. Build inventory table
3. Identify naming inconsistencies
4. Check README alignment
5. Present report with specific fixes
Example 2: Pre-release check
User: "make sure our command implementation and comments are aligned"
Action:
1. Compare help text with actual behavior
2. Verify README examples work
3. Check for undocumented flags
4. Update docs to match implementation