Agent skill
cli-development-guidelines
This skill should be used when designing, implementing, or reviewing CLI tools, or when flags, subcommands, help text, exit codes, or `--cli-dev` are mentioned.
Install this agent skill to your Project
npx add-skill https://github.com/outfitter-dev/agents/tree/main/plugins/cli-dev/skills/cli-development-guidelines
Metadata
Additional technical details for this skill
- version
- 0.1.0
- upstream
- clig.dev + POSIX/GNU/Heroku/12-factor + Agent Skills spec
SKILL.md
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:
- CLI reference
- CLI spec template
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
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
stack-feedback
Creates GitHub issues for problems discovered while using @outfitter/* packages. Use when finding bugs, missing features, unclear documentation, or improvement opportunities.
stack-architecture
Design stack-based systems using @outfitter/* packages. Use when planning new projects, choosing packages, designing handler architecture, or when "architecture", "design", "structure", "plan handlers", or "error taxonomy" are mentioned.
stack-templates
Templates for creating handlers, CLI commands, MCP tools, and daemon services following Outfitter Stack conventions. Use when scaffolding new components, creating handlers, adding commands, or when "create handler", "new command", "add tool", "scaffold", "template", or "daemon service" are mentioned.
stack-audit
Scan codebase for Outfitter Stack adoption candidates. Identifies throw statements, console usage, hardcoded paths, and custom errors. Use when assessing adoption scope or checking readiness.
stack-review
Audits code for Outfitter Stack compliance including Result types, error handling, logging patterns, and path safety. Use for pre-commit reviews, code quality checks, migration validation, or when "audit", "check compliance", "review stack", or "stack patterns" are mentioned.
stack-patterns
Reference for Outfitter Stack patterns including Result types, Handler contract, Error taxonomy, and @outfitter/* package conventions. Use when learning the stack, looking up patterns, understanding packages, or when "Result", "Handler", "error taxonomy", "OutfitterError", "CLI output", "pagination", "MCP server", "MCP tool", "structured logging", "redaction", "test handler", "daemon", "IPC", or "@outfitter/*" are mentioned.
Didn't find tool you were looking for?