cli-development-guidelines
CLI Development Guidelines
When to activate this skill
- You are designing, implementing, or reviewing a command-line tool.
- The user mentions (explicitly or implicitly):
--help, flags, subcommands, exit codes, stdout/stderr, piping, JSON output, color, prompts, config files, env vars, “works in CI”, install/uninstall, telemetry.
What this skill produces
- A CLI contract (what users can rely on): commands, flags, IO behavior, exit codes, config/env, examples, and safety behavior.
- Draft help output and docs structure (example-first).
- A compliance audit (when runnable) using
scripts/cli_audit.py.
Non-negotiable CLI citizenship
- Exit codes:
0on success.- Non-zero on failure (and ideally meaningful, documented codes).
- Streams:
stdoutis for primary output and machine-readable output.stderris for errors, warnings, progress, and “what I’m doing” messaging.
- Discoverability:
--help(and usually-h) shows help and exits.--versionprints version and exits.
- Interactivity:
- Prompts only when
stdinis a TTY. - Provide
--no-inputto force non-interactive behavior.
- Prompts only when
- Scripting friendliness:
- No ANSI color / spinners when output isn’t a TTY.
- Support
NO_COLORand--no-color. - Consider
--jsonand--plainfor stable output.
Workflow
Sketch the CLI contract first
- Start from the user’s jobs-to-be-done (what they’re trying to accomplish).
- Decide:
- Command shape: single command vs subcommands (
noun verbis common). - Inputs: args vs flags vs stdin vs prompts vs config/env.
- Outputs: human default, plus machine modes (
--json,--plain,--quiet). - Safety: confirmations,
--dry-run,--force, secret handling.
- Command shape: single command vs subcommands (
Use:
Implement with safe defaults
- Use a CLI parsing library (don’t hand-roll).
- Make “boundary-crossing” actions explicit:
- Network calls
- Writing files not explicitly provided
- Mutating remote state
- Avoid footguns:
- Don’t accept secrets via flags or environment variables.
- Don’t print stack traces by default.
- Don’t assume TTY (detect it).
Validate and iterate
- Run an automated sanity check (when possible):
python scripts/cli_audit.py -- <your-cli> [subcommand]
- Fix in this order:
- Broken stdout/stderr separation
- Incorrect exit codes
- Help that’s missing or undiscoverable
- Unsafe defaults (destructive ops, secrets, hidden network writes)
- Unscriptable output (no stable modes)
Use:
- Checklist
scripts/cli_audit.py
Reference library
- Core reference: references/REFERENCE.md
- Quick audit checklist: references/CHECKLIST.md
- Evaluation prompts: references/EVAL_PROMPTS.md
Templates and scripts
- CLI spec template:
templates/cli-command-spec-template.json - Help text template:
templates/help-text-template.md - Error message template:
templates/error-message-template.md - Audit a CLI:
scripts/cli_audit.py
More from outfitter-dev/agents
graphite-stacks
This skill should be used when the user asks to "create a stack", "submit stacked PRs", "gt submit", "gt create", "reorganize branches", "fix stack corruption", or mentions Graphite, stacked PRs, gt commands, or trunk-based development workflows.
76code-review
This skill should be used when reviewing code before commit, conducting quality gates, or when "review", "fresh eyes", "pre-commit review", or "quality gate" are mentioned.
34hono-dev
This skill should be used when building APIs with Hono, using hc client, implementing OpenAPI, or when "Hono", "RPC", or "type-safe API" are mentioned.
28software-craft
This skill should be used when making design decisions, evaluating trade-offs, assessing code quality, or when "engineering judgment" or "code quality" are mentioned.
28subagents
This skill should be used when coordinating agents, delegating tasks to specialists, or when "dispatch agents", "which agent", or "multi-agent" are mentioned.
25context-management
Manage context window, survive compaction, persist state. Use when planning long tasks, coordinating agents, approaching context limits, or when "context", "compaction", "tasks", or "persist state" are mentioned.
24