PluginBench
Skill
Pass
Audit score 90

cli-for-agents

cursor/plugins

Design CLIs that agents can run reliably: non-interactive flags, layered help, stdin/pipelines, and predictable structure.

What is cli-for-agents?

A reference for building or reviewing CLIs that work well with coding agents. Use this when designing commands, writing help text, or making a CLI automation-friendly. It covers non-interactive inputs, discoverability, error handling, idempotency, and dry-run patterns.

  • Enforce non-interactive-first design with flags instead of prompts
  • Structure help text with examples agents can copy-paste
  • Support stdin and pipeline composition for chaining commands
  • Provide fast, actionable error messages with correct invocations
  • Ensure idempotency so retries are safe
  • Add --dry-run and --yes flags for preview and automation

How to install cli-for-agents

npx skills add https://github.com/cursor/plugins --skill cli-for-agents
Claude Code
Cursor
Windsurf
Cline

How to use cli-for-agents

  1. 1.Review the 'Non-interactive first' section to ensure all inputs are flags, not prompts
  2. 2.Check your --help output includes Examples with real invocations
  3. 3.Verify error messages show a correct example command, not just the problem
  4. 4.Add --dry-run for destructive actions and --yes to skip confirmations
  5. 5.Test that the same command run twice is safe (idempotent or explicitly no-op)
  6. 6.Ensure success output includes machine-useful data (IDs, URLs, durations)

Use cases

Good for
  • Building a new CLI tool for deployment or infrastructure tasks
  • Adding a subcommand to an existing agent-facing CLI
  • Writing --help text that includes real, runnable examples
  • Reviewing a CLI to make it work reliably in headless/automated contexts
  • Designing error messages that guide agents toward correct usage
Who it's for
  • CLI tool developers
  • Backend engineers building deployment or admin tools
  • DevOps engineers creating automation-friendly commands
  • Anyone building tools that agents (Claude Code, Cursor) will invoke

cli-for-agents FAQ

Should I support interactive mode at all?

Yes, but only as a fallback when flags are missing. Non-interactive (flags) should be the primary path so agents can use the CLI without user input.

How detailed should --help be?

Keep each subcommand's help focused and include Examples. Agents discover incrementally (mycli, then mycli deploy --help), so avoid dumping the entire manual upfront.

What if my CLI doesn't have destructive actions?

Still follow the patterns for consistency. If there are no destructive actions, you may skip --dry-run, but keep --yes for any confirmation prompts.

How do I make errors agent-friendly?

Exit immediately with a clear message and show a correct example invocation. Include hints like 'Available tags: mycli build list --output tags' so agents can self-correct.

Why does command structure matter?

Consistent patterns (e.g., resource + verb like 'mycli service list' and 'mycli config list') let agents predict and compose commands without re-reading docs each time.

Full instructions (SKILL.md)

Source of truth, from cursor/plugins.


name: cli-for-agents description: >- Designs or reviews CLIs so coding agents can run them reliably: non-interactive flags, layered --help with examples, stdin/pipelines, fast actionable errors, idempotency, dry-run, and predictable structure. Use when building a CLI, adding commands, writing --help, or when the user mentions agents, terminals, or automation-friendly CLIs.

CLI for agents

Human-oriented CLIs often block agents: interactive prompts, huge upfront docs, and help text without copy-pasteable examples. Prefer patterns that work headlessly and compose in pipelines.

Non-interactive first

  • Every input should be expressible as a flag or flag value. Do not require arrow keys, menus, or timed prompts.
  • If flags are missing, then fall back to interactive mode—not the other way around.

Bad: mycli deploy → ? Which environment? (use arrow keys)
Good: mycli deploy --env staging

Discoverability without dumping context

  • Agents discover subcommands incrementally: mycli, then mycli deploy --help. Do not print the entire manual on every run.
  • Let each subcommand own its documentation so unused commands stay out of context.

--help that works

  • Every subcommand has --help.
  • Every --help includes Examples with real invocations. Examples do more than prose for pattern-matching.
Options:
  --env     Target environment (staging, production)
  --tag     Image tag (default: latest)
  --force   Skip confirmation

Examples:
  mycli deploy --env staging
  mycli deploy --env production --tag v1.2.3
  mycli deploy --env staging --force

stdin, flags, and pipelines

  • Accept stdin where it makes sense (e.g. cat config.json | mycli config import --stdin).
  • Avoid odd positional ordering and avoid falling back to interactive prompts for missing values.
  • Support chaining: mycli deploy --env staging --tag $(mycli build --output tag-only).

Fail fast with actionable errors

  • On missing required flags: exit immediately with a clear message and a correct example invocation, not a hang.
Error: No image tag specified.
  mycli deploy --env staging --tag <image-tag>
  Available tags: mycli build list --output tags

Idempotency

  • Agents retry often. The same successful command run twice should be safe (no-op or explicit "already done"), not duplicate side effects.

Destructive actions

  • Add --dry-run (or equivalent) so agents can preview plans before committing.
  • Offer --yes / --force to skip confirmations while keeping the safe default for humans.

Predictable structure

  • Use a consistent pattern everywhere, e.g. resource + verb: if mycli service list exists, mycli deploy list and mycli config list should follow the same shape.

Success output

  • On success, return machine-useful data: IDs, URLs, durations. Plain text is fine; avoid relying on decorative output alone.
deployed v1.2.3 to staging
url: https://staging.myapp.com
deploy_id: dep_abc123
duration: 34s

When reviewing an existing CLI

  • Check: non-interactive path, layered help, examples on --help, stdin/pipeline story, error messages with invocations, idempotency, dry-run, confirmation bypass flags, consistent command structure, structured success output.