Design command-line interface parameters and UX: arguments, flags, subcommands, help text, output formats, error messages, exit codes, prompts, config/env precedence, and safe/dry-run behavior. Use when you’re designing a CLI spec (before implementation) or refactoring an existing CLI’s surface area for consistency, composability, and discoverability.
75
93%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Design CLI surface area (syntax + behavior), human-first, script-friendly.
references/cli-guidelines.md from this skill directory and apply it as
the default rubric.Ask, then proceed with best-guess defaults if user is unsure:
--json, --plain, exit codes.--no-input? confirmations for destructive ops?When designing a CLI, produce a compact spec the user can implement:
--json/--plain; --quiet/--verbose.--dry-run, confirmations, --force, --no-input.-h/--help always shows help and ignores other args.--version prints version to stdout.--json for machine output; consider --plain for stable line-based text.--no-input disables prompts.--force or explicit --confirm=....NO_COLOR, TERM=dumb; provide --no-color.Fill these sections, drop anything irrelevant:
mycmd...mycmd [global flags] <subcommand> [args]mycmd init ...mycmd run ...-h, --help--version-q, --quiet / -v, --verbose (define exactly)--json / --plain (if applicable)0 success1 generic failure2 invalid usage (parse/validation)5b69c2a
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.