cli-for-agents
Original:🇺🇸 English
Translated
Use this skill whenever designing, building, or reviewing a command-line tool that AI agents or automation will invoke — covers non-interactive flags, layered --help with examples, stdin/pipeline composition, actionable errors, idempotency, dry-run, destructive-action safety, and predictable command structure. Trigger even if the user doesn't explicitly say "agent-friendly" — apply whenever they are writing `--help` text, adding a new subcommand, designing error messages, or reviewing a CLI's UX.
7installs
Sourcepproenca/dot-skills
Added on
NPX Install
npx skill4agent add pproenca/dot-skills cli-for-agentsTags
Translated version includes tags in frontmatterSKILL.md Content
View Translation Comparison →Agent-Friendly CLI Design Best Practices
Prescriptive design and review standards for Command-Line Interface Design targeting AI agents and scripts, not just humans typing at a prompt. Human-oriented CLIs often block agents: interactive prompts, huge upfront docs, help text without copy-pasteable examples, error messages without fixes, no dry-run mode. This skill prioritizes rules by blast radius — from "the agent cannot use this CLI at all" (CRITICAL) to "the agent has to read help one extra time" (MEDIUM).
Use this skill both when building a new CLI and when reviewing an existing one for agent-friendliness.
This skill contains 45 rules across 8 categories.
When to Apply
Reference these guidelines when:
- Writing text for any subcommand
--help - Designing new flags, arguments, or subcommands
- Crafting error messages or exit codes
- Adding destructive operations that need dry-run or confirmation
- Choosing between interactive prompts and flag-only inputs
- Shaping success output so agents can chain commands
- Reviewing an existing CLI for headless-usability regressions
Rule Categories by Priority
| Priority | Category | Impact | Prefix |
|---|---|---|---|
| 1 | Non-interactive Operation | CRITICAL | |
| 2 | Help Text Design | HIGH | |
| 3 | Error Messages | HIGH | |
| 4 | Destructive Action Safety | HIGH | |
| 5 | Input Handling | HIGH | |
| 6 | Output Format | MEDIUM-HIGH | |
| 7 | Idempotency & Retries | MEDIUM-HIGH | |
| 8 | Command Structure | MEDIUM | |
Note: is rated CRITICAL within the HIGH category because its specific failure — help text without examples — makes every other help rule moot. The category label reflects the average, not the worst case.
help-examples-in-helphelp-Quick Reference
1. Non-interactive Operation (CRITICAL)
- — Express every input as a flag first; prompts are TTY-only fallback
interact-flags-first - — Check
interact-detect-ttybefore promptingisatty() - — Replace arrow-key menus with flag-selected choices
interact-no-arrow-menus - — Support
interact-no-input-flagto force non-interactive mode--no-input - — Never use timed prompts or press-any-key screens
interact-no-timed-prompts - — Don't block on stdin when a TTY is attached
interact-no-hang-on-stdin
2. Help Text Design (HIGH)
- — Include copy-pasteable examples in every
help-examples-in-help--help - — Every subcommand owns its own
help-per-subcommand--help - — Show help when invoked with zero arguments
help-no-flag-required - — Top-level help is a navigational index
help-layered-discovery - — List both short and long forms for every flag
help-flag-summary - — Suggest what to run next in help and success output
help-suggest-next-steps
3. Error Messages (HIGH)
- — Exit fast on missing required flags
err-exit-fast-on-missing-required - — Include a concrete fix in every error message
err-actionable-fix - — Send errors to stderr, not stdout
err-stderr-not-stdout - — Use distinct non-zero exit codes for distinct failures
err-non-zero-exit-codes - — Include a correct example invocation in errors
err-include-example-invocation - — Reserve stack traces for
err-no-stack-traces-by-defaultmode--debug
4. Destructive Action Safety (HIGH)
- — Provide
safe-dry-run-flagfor every destructive command--dry-run - — Provide
safe-force-bypass-flag/--yesto skip confirmations--force - — Require typing the resource name for irreversible actions
safe-confirm-by-typing-name - — Never prompt when
safe-no-prompts-with-no-inputis set--no-input - — Exit successfully when delete targets are already gone
safe-idempotent-cleanup - — Design multi-step commands for crash-only recovery
safe-crash-only-recovery
5. Input Handling (HIGH)
- — Accept
input-accept-stdin-dashas filename for stdin and stdout- - — Prefer named flags over positional arguments
input-flags-over-positional - — Accept secrets through stdin or file, never as flag values
input-stdin-for-secrets - — Accept common flags through environment variables
input-env-var-fallback - — Never fall back to a prompt when a flag is missing
input-no-prompt-fallback
6. Output Format (MEDIUM-HIGH)
- — Provide
output-json-flagfor stable machine-readable output--json - — Stream large result sets as NDJSON
output-ndjson-streaming - — Bound default output size with
output-bounded-by-defaultand--limit--all - — Return chainable values on success, not just "Done"
output-machine-ids-on-success - — Disable ANSI color when
output-respect-no-coloror non-TTYNO_COLOR - — Avoid relying on decorative output to convey state
output-no-decorative-only - — One record per line for grep-able human output
output-one-record-per-line
7. Idempotency & Retries (MEDIUM-HIGH)
- — Make running the same command twice safe
idem-retry-safe - — Make create commands skip when target already exists
idem-create-or-skip - — Return the same output shape whether acting or skipping
idem-stable-output-on-skip - — Prefer "ensure state" semantics over delta application
idem-state-reconciliation - — Accept user-provided names instead of auto-generating IDs
idem-stable-identifiers
8. Command Structure (MEDIUM)
- — Use a consistent resource-verb command shape
struct-resource-verb - — Parse flags in any position relative to subcommands
struct-flag-order-independent - — Avoid catch-all handlers for unknown subcommands
struct-no-hidden-subcommand-catchall - — Use standard flag names (
struct-standard-flag-names,--help,--version,--verbose)--quiet
How to Use
When building a new CLI
Start at CRITICAL and walk down. The first two categories ( and ) are non-negotiable — if any rule in these is violated, the CLI is unusable by agents regardless of how good the rest is. After those, work through , , and — these are where most real-world friction lives. , , and are polish that compounds across many invocations.
interact-help-err-safe-input-output-idem-struct-When reviewing an existing CLI
Run through this checklist in priority order:
- Non-interactive path — invoke every subcommand with or under
--no-inputand see which hang</dev/null - Layered help — does list subcommands only, or dump everything?
mycli --help - Examples on — every subcommand's help should end with a runnable Examples section
--help - Error messages with invocations — does every error tell the caller exactly which flag to add?
- stdin/pipeline story — can you pipe output into input? Does mean stdin?
- - Exit codes — are usage errors (2), runtime failures (1), and transient failures (69) distinct?
- Dry-run — every destructive command has (or equivalent)
--dry-run - Confirmation bypass — every destructive command has /
--yes--force - Consistent command structure — do ,
service list,deploy listall exist and work the same way?config list - Structured success output — does return a
deploythe agent can use next?deploy_id
Individual rules
Read individual reference files for detailed explanations and code examples:
- Section definitions — Category structure and impact levels
- Rule template — Template for adding new rules
Reference Files
| File | Description |
|---|---|
| references/_sections.md | Category definitions and ordering |
| assets/templates/_template.md | Template for new rules |
| metadata.json | Version and reference information |