Get the FREE Ultimate OpenClaw Setup Guide →

create-cli

Scanned
npx machina-cli add skill jmerta/codex-skills/create-cli --openclaw
Files (1)
SKILL.md
3.7 KB

Create CLI

Design CLI surface area (syntax + behavior), human-first, script-friendly.

Do This First

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/--help always shows help and ignores other args.
  • --version prints version to stdout.
  • Primary data to stdout; diagnostics/errors to stderr.
  • Add --json for machine output; consider --plain for stable line-based text.
  • Prompts only when stdin is a TTY; --no-input disables prompts.
  • Destructive operations: interactive confirmation + non-interactive requires --force or 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:

  1. Name: mycmd
  2. One-liner: ...
  3. USAGE:
    • mycmd [global flags] <subcommand> [args]
  4. Subcommands:
    • mycmd init ...
    • mycmd run ...
  5. Global flags:
    • -h, --help
    • --version
    • -q, --quiet / -v, --verbose (define exactly)
    • --json / --plain (if applicable)
  6. I/O contract:
    • stdout:
    • stderr:
  7. Exit codes:
    • 0 success
    • 1 generic failure
    • 2 invalid usage (parse/validation)
    • (add command-specific codes only when actually useful)
  8. Env/config:
    • env vars:
    • config file path + precedence:
  9. 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)

Source

git clone https://github.com/jmerta/codex-skills/blob/main/create-cli/SKILL.mdView on GitHub

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

  1. Step 1: Read references/cli-guidelines.md and establish the command tree and global flags.
  2. Step 2: Create the USAGE synopsis and an Args/flags table with types, defaults, and examples.
  3. 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.

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers