create-cli
Scannednpx machina-cli add skill jmerta/codex-skills/create-cli --openclawCreate CLI
Design CLI surface area (syntax + behavior), human-first, script-friendly.
Do This First
- Read
references/cli-guidelines.mdand apply it as the default rubric. - Upstream/full guidelines: https://clig.dev/ (propose changes: https://github.com/cli-guidelines/cli-guidelines)
- Ask only the minimum clarifying questions needed to lock the interface.
Clarify (fast)
Ask, then proceed with best-guess defaults if user is unsure:
- Command name + one-sentence purpose.
- Primary user: humans, scripts, or both.
- Input sources: args vs stdin; files vs URLs; secrets (never via flags).
- Output contract: human text,
--json,--plain, exit codes. - Interactivity: prompts allowed? need
--no-input? confirmations for destructive ops? - Config model: flags/env/config-file; precedence; XDG vs repo-local.
- Platform/runtime constraints: macOS/Linux/Windows; single binary vs runtime.
Deliverables (what to output)
When designing a CLI, produce a compact spec the user can implement:
- Command tree + USAGE synopsis.
- Args/flags table (types, defaults, required/optional, examples).
- Subcommand semantics (what each does; idempotence; state changes).
- Output rules: stdout vs stderr; TTY detection;
--json/--plain;--quiet/--verbose. - Error + exit code map (top failure modes).
- Safety rules:
--dry-run, confirmations,--force,--no-input. - Config/env rules + precedence (flags > env > project config > user config > system).
- Shell completion story (if relevant): install/discoverability; generation command or bundled scripts.
- 5–10 example invocations (common flows; include piped/stdin examples).
Default Conventions (unless user says otherwise)
-h/--helpalways shows help and ignores other args.--versionprints version to stdout.- Primary data to stdout; diagnostics/errors to stderr.
- Add
--jsonfor machine output; consider--plainfor stable line-based text. - Prompts only when stdin is a TTY;
--no-inputdisables prompts. - Destructive operations: interactive confirmation + non-interactive requires
--forceor explicit--confirm=.... - Respect
NO_COLOR,TERM=dumb; provide--no-color. - Handle Ctrl-C: exit fast; bounded cleanup; be crash-only when possible.
Templates (copy into your answer)
CLI spec skeleton
Fill these sections, drop anything irrelevant:
- Name:
mycmd - One-liner:
... - USAGE:
mycmd [global flags] <subcommand> [args]
- Subcommands:
mycmd init ...mycmd run ...
- Global flags:
-h, --help--version-q, --quiet/-v, --verbose(define exactly)--json/--plain(if applicable)
- I/O contract:
- stdout:
- stderr:
- Exit codes:
0success1generic failure2invalid usage (parse/validation)- (add command-specific codes only when actually useful)
- Env/config:
- env vars:
- config file path + precedence:
- Examples:
- …
Notes
- Prefer recommending a parsing library (language-specific) only when asked; otherwise keep this skill language-agnostic.
- If the request is “design parameters”, do not drift into implementation.
Attribution
This skill was copied from steipete/agent-scripts. Upstream: https://github.com/steipete/agent-scripts License: MIT (see LICENSE)
Overview
Create a compact spec for CLI interfaces that captures commands, arguments, flags, subcommands, help text, output formats, error messages, exit codes, prompts, and config/env precedence. It emphasizes user-first ergonomics, script-friendliness, and discoverability before implementation or refactor.
How This Skill Works
Start by clarifying the interface: name, primary users, inputs, outputs, and config precedence. Then deliver a compact spec including a command tree with USAGE, an args/flags table, subcommand semantics, output rules, an error/exit-code map, safety rules, a shell-completion plan, and 5–10 example invocations.
When to Use It
- When designing a CLI spec before implementation or refactoring.
- When refactoring an existing CLI for consistency and discoverability.
- When standardizing UX across a tool suite with shared conventions.
- When planning safety features like dry-run, prompts, and force controls.
- When defining config/env precedence for predictable behavior across environments.
Quick Start
- Step 1: Read references/cli-guidelines.md and establish the command tree and global flags.
- Step 2: Create the USAGE synopsis and an Args/flags table with types, defaults, and examples.
- Step 3: Define output rules, error/exit codes, safety rules, config/env precedence, and provide 5–10 example invocations.
Best Practices
- Start from CLI guidelines and apply the rubric as the default.
- Draft the command tree and USAGE before writing any code.
- Make safety features explicit: dry-run, confirmations, and force/no-input handling.
- Provide machine-friendly output (--json) alongside clear human-readable output (--plain).
- Respect color/TTY settings (NO_COLOR, TERM) and offer a --no-color option.
Example Use Cases
- Backup tool CLI with dry-run, force/no-input options and color controls.
- Deployment CLI with subcommands like init, apply, and destroy, emphasizing idempotence and confirmations.
- Data-import CLI that accepts input from files/URLs and outputs JSON for automation.
- Tool-suite with shared global flags and consistent error codes across multiple CLIs.
- Destructive operation flow that prompts for confirmation but allows non-interactive overrides via --force.