home / skills / phrazzld / claude-config / cli-development

cli-development skill

/skills/cli-development

This skill guides you in designing robust CLI tools with patterns, help messages, and common frameworks to improve usability and consistency.

npx playbooks add skill phrazzld/claude-config --skill cli-development

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

Files (2)
SKILL.md
2.9 KB
---
name: cli-development
description: |
  Command-line tool development patterns, conventions, and toolchain. Use when:
  - Building CLI applications
  - Designing command interfaces  
  - Choosing CLI frameworks (Commander.js, oclif, Ink, Cobra, Thor)
  - Implementing help and error messages
  - Following Unix conventions
  Keywords: CLI, command line, terminal, help text, exit codes,
  flags, arguments, Commander, Thor, Cobra, oclif
effort: high
---

# CLI Development

Verb-noun commands, progressive disclosure, helpful errors.

## Command Structure

**Verb-noun pattern:**
```
tool create project
tool deploy app
tool logs get
tool config set key value
```

**Max 2 levels deep. Use common verbs:** create, delete, list, show, update, get, set.

## Flags

```
-h, --help         Always support both
-v, --verbose      Increase output detail
-f, --force        Skip confirmations
-o, --output json  Format specifier
--dry-run          Show what would happen
```

**Boolean flags don't take values. Value flags use space or `=`.**

## Help Text

```
USAGE
  tool deploy <app> [flags]

DESCRIPTION
  Deploy an application to the specified environment.

FLAGS
  -e, --env string    Target environment (default: "staging")
  -f, --force         Skip confirmation prompt
  --dry-run           Show what would be deployed

EXAMPLES
  # Deploy to staging
  tool deploy my-app

  # Deploy to production with confirmation bypass
  tool deploy my-app --env production --force

SEE ALSO
  tool deploy logs    View deployment logs
  tool deploy status  Check deployment status
```

## Error Messages

```
Error: Configuration file not found

The file 'config.yaml' does not exist in the current directory.

To fix this:
  1. Run 'tool init' to create a new config file
  2. Or specify a path with --config /path/to/config.yaml

See 'tool init --help' for more information.
```

**Include:** what went wrong, context, specific fix, help reference.

## Exit Codes

| Code | Meaning |
|------|---------|
| 0 | Success |
| 1 | General error |
| 2 | Misuse (invalid arguments) |
| 126 | Not executable |
| 127 | Command not found |

## Output

**Human-readable by default, machine-readable on request:**
```bash
tool list users              # Pretty table
tool list users --format json  # JSON output
tool list users -o yaml        # YAML output
```

## Progressive Disclosure

- Simple commands with sensible defaults
- Advanced options available but not prominent
- Help organized by experience level
- Discovery through `--help` and suggestions

## Anti-Patterns

- Cryptic abbreviations (`-x` without long form)
- Stack traces in user output
- Silent failures (no output on error)
- Required flags for common cases
- Deep command hierarchies (>2 levels)
- Inconsistent verbs across commands

## Toolchain

See `references/toolchain.md` for framework-specific guidance:
- **Commander.js** (default for Node.js)
- **oclif** (enterprise CLIs)
- **Ink** (React for terminals)
- **Cobra** (Go CLIs)
- **Thor** (Ruby CLIs)

Overview

This skill captures best practices and patterns for building command-line tools, covering command structure, flags, help text, error handling, exit codes, and toolchain choices. It focuses on practical, Unix-friendly conventions to make CLIs discoverable, reliable, and scriptable. Use it to design consistent command interfaces and choose appropriate frameworks and output formats.

How this skill works

The skill inspects command and subcommand layouts (verb-noun, max two levels), recommended flags and flag behavior, help and example sections, and error message templates. It maps outputs to human- and machine-readable modes and prescribes exit codes. It also recommends framework choices by language and use case.

When to use it

  • Designing or refactoring a CLI command hierarchy
  • Defining flags, default behaviors, and output formats
  • Writing help text, examples, and error messages
  • Choosing a CLI framework (Commander, oclif, Cobra, Thor, Ink)
  • Ensuring scripts and automation handle exit codes correctly

Best practices

  • Use verb-noun commands with at most two levels (e.g., tool deploy app)
  • Always support -h/--help and -v/--verbose; boolean flags take no value
  • Provide human-readable default output and machine formats via -o/--output or --format
  • Write errors that state what failed, relevant context, a specific fix, and a help reference
  • Keep advanced options discoverable but not prominent; use progressive disclosure
  • Follow standard exit codes (0 success, 1 general, 2 misuse, 126/127 execution issues)

Example use cases

  • Designing a new CLI: define verbs, top-level commands, and example usage
  • Implementing consistent help text with USAGE, DESCRIPTION, FLAGS, EXAMPLES, SEE ALSO
  • Adding machine-readable output for automation (JSON/YAML) alongside pretty tables
  • Improving UX by converting cryptic flags to long forms and removing required flags for common flows
  • Selecting a framework: Commander/oclif for Node, Cobra for Go, Thor for Ruby, Ink for rich terminal UIs

FAQ

Should I allow flags to use = or space for values?

Yes. Support both `--flag=value` and `--flag value` to match user expectations.

How deep should command hierarchies go?

Limit to two levels (verb and noun). Deeper hierarchies complicate discovery and increase cognitive load.