Dev cli consistency audit
A lazy engineer's toolkit — why do it yourself when a Skill can?
npx -y skills add jackchuka/skills --skill dev-cli-consistency-auditAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 15 stars15 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Reviews a CLI tool's command interface for consistency in argument naming, flag conventions, help text, and README alignment. Use when building CLI tools or before releasing CLI updates. Triggers: "review CLI arguments", "align CLI conventions", "CLI consistency check", "make sure commands are aligned", "review command interface".
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
4.3 KB, as published. Nobody here has run it
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