magnus919 CLI Builder
Treat a CLI as a contract between the tool and the agent. The contract includes
command names, --help, flags, output schemas, exit codes, stderr, and previews.
Keep this file as the workflow; load the linked references only when their
specialized guidance is needed.
When to Use
- Build a new CLI that an agent will discover and call.
- Refactor prompts, ambiguous commands, parser-hostile output, or false success codes.
- Add or review
--json,--dry-run,--yes, idempotency, or lazy authentication.
One Workflow
1. Discover the real contract
Define one CLI per service (except services sharing vendor authentication). Inspect real non-health read endpoints before coding, verify the actual authentication header and response shape, and capture the command tree and failure cases. Do not invent flags from API documentation alone. For HTTP clients, read the Python API client pattern.
Choose Bash for local wrappers and filesystem pipelines. Choose Python for HTTP, JSON, authentication state, or three-level command trees.
2. Build a predictable surface
Use one consistent verb/resource convention. Every command should be non-interactive
and flag-driven, reject unknown flags, and provide useful subcommand help with
concrete examples. Make normal output human-readable, but support --json with a
stable curated schema, normalized types, deterministic ordering, and no other stdout.
Send diagnostics to stderr with truthful non-zero exit codes.
For any state change, implement --dry-run before data-fetching or mutation, and
require an explicit --yes/--force gate for destructive work. Guard creation,
updates, and deletion so reruns are safe. Authentication must be lazy: --help and
safe dry-runs work without credentials.
Use the advanced patterns for chained dry-runs, third-party JSON, version-dependent behavior, and text matching. Use the Bash scaffold when a local shell wrapper is the right fit.
3. Verify the contract
Run syntax checks, every command's --help, parse every --json response, check
missing arguments and unknown flags, confirm errors are on stderr, exercise dry-run
without credentials, and prove a second identical run is a no-op. Against a live
service, test a real authenticated read and dry-run each mutation. Use the
agent-readiness checklist for the final
review.
4. Wrap and maintain
Keep the entry-point skill concise and put conditional detail in references. A wrapper should explain what the CLI is for, setup, common commands, output meaning, and gotchas, not duplicate every flag. See the skill-wrapper example. After real usage, record failures and prioritize fixes with the improvement cycle.
Core Contracts
--helpis the discoverable schema and includes examples.--jsonis parseable on stdout alone; errors have stable machine-readable codes.--dry-rundescribes exact intended changes and performs no writes or prerequisite lookups.- Mutations are explicitly authorized, idempotent, and report meaningful status.
- Exit status distinguishes success, usage failure, and runtime failure.
When Not to Use
Do not use this skill for one-off interactive human commands, GUI/TUI or web UI design, conversational agent tools, or MCP servers. Read the MCP-vs-CLI decision guide for tool-boundary choices, and route general API contract design to api-design-and-evolution.
References
- Python API client
- Advanced patterns
- Agent-readiness checklist
- Skill wrapper example
- MCP vs CLI
- Improvement cycle
- Bash scaffold