home / skills / zenobi-us / dotfiles / creating-cli-tools

creating-cli-tools skill

safe

/ai/files/skills/devtools/creating-cli-tools

This skill helps you design clear CLI surface and behavior for scripts and humans by specifying commands, flags, and UX guidelines.

npx playbooks add skill zenobi-us/dotfiles --skill creating-cli-tools

Review the files below or copy the command above to add this skill to your agents.

Files (3)

SKILL.md

3.6 KB

---
name: creating-cli-tools
description: >
  Design command-line interface parameters and UX: arguments, flags, subcommands,
  help text, output formats, error messages, exit codes, prompts, config/env
  precedence, and safe/dry-run behavior. Use when you’re designing a CLI spec
  (before implementation) or refactoring an existing CLI’s surface area for
  consistency, composability, and discoverability.
---

# Create CLI

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

## Do This First

- Read `agent-scripts/skills/create-cli/references/cli-guidelines.md` and 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/--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.

Overview

This skill designs command-line interface parameters and UX for tools that manage workstation setup across Linux, Windows, and macOS. It produces a compact, implementable CLI spec covering commands, flags, I/O, error codes, config precedence, and safe/dry-run behavior. Use it before implementation or when refactoring to improve consistency, composability, and discoverability.

How this skill works

I inspect the desired command surface: command name, primary users (humans vs scripts), input sources, output contract, interactivity, and platform constraints. I then produce a focused CLI spec: command tree and usage, flags/args table, subcommand semantics, I/O rules, exit codes, config precedence, safety rules, completion story, and example invocations. I ask only essential clarifying questions and apply sensible defaults from CLI guidelines if you are unsure.

When to use it

Designing a new CLI for provisioning or workstation setup before writing code
Refactoring an existing CLI to improve discoverability and scripting behavior
Defining safe defaults: dry-run, confirmations, and exit codes for automation
Aligning cross-platform behavior for Linux, macOS, and Windows
Specifying machine-readable output (JSON/plain) and error semantics for CI

Best practices

Start with one-line command purpose, primary user, and input/output contract before detailing flags
Prefer human-first defaults with explicit machine output via --json and stable --plain
Make destructive actions require confirmation when TTY and require --force for non-interactive runs
Follow a clear precedence: flags > env vars > project config > user config > system config
Keep stdout for primary data and stderr for diagnostics; use distinct exit codes for parse vs runtime errors

Example use cases

Designing a cross-platform `setup` command that provisions dotfiles and packages with --dry-run and --json
Refactoring an installer CLI to expose a `validate` subcommand that exits 2 on invalid config
Specifying a `sync` subcommand that reads manifests from a file or stdin and supports --plain for stable output
Creating a safe `apply` command that requires interactive confirm by default and --force for CI
Documenting shell completion install commands and a generation command for packaging

FAQ

What minimal questions will you ask before designing the CLI?

Command name and one-line purpose, target users (humans/scripts), input and output formats, interactivity expectations, config model, and supported platforms.

Do you decide parsing libraries or implementation details?

No—this skill stays language-agnostic and focuses on the interface and behavior. I can recommend libraries only if you request implementation guidance.