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--repoflag in others? - Recommendation: Pick one approach and apply everywhere
- Is the same concept (e.g.,
-
Flag naming:
- Are similar concepts named consistently? (e.g.,
--outputvs--formatvs-o) - Do boolean flags follow the same pattern? (
--dry-runvs--confirmvs--yes) - Are shorthand flags (
-f,-o) assigned consistently?
- Are similar concepts named consistently? (e.g.,
-
Pluralization:
- Subcommand names: singular vs plural (e.g.,
list filesvslist file) - Flag names:
--issuevs--issues
- Subcommand names: singular vs plural (e.g.,
-
Default behaviors:
- Are defaults consistent? (e.g., if one command defaults to
--format=table, do others?) - Are destructive commands safe by default? (require
--confirmor--force)
- Are defaults consistent? (e.g., if one command defaults to
-
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
--helptext 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