create-cli

Document CLI surface area specifications with arguments, flags, and exit codes.

Updated Aug 12, 2018
One-click install
npx skills add https://github.com/ivanov-i/dots --skill create-cli-ivanov-i
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: create-cli
Source: https://github.com/ivanov-i/dots/tree/main/codex/skills/create-cli
Command: npx skills add https://github.com/ivanov-i/dots --skill create-cli-ivanov-i

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Designing CLI 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.

Core Features & Use Cases

  • 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; --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).
  • 5–10 example invocations (common flows; include piped/stdin examples).

Quick Start

Draft a concise CLI spec for a hypothetical tool and validate it against human-first and script-friendly design criteria.

Frequently Asked Questions about create-cli

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a clean CLI surface area for arguments, flags, and subcommands?

A CLI specification defines arguments, flags, subcommands, help text, and exit codes. It ensures consistency, composability, and discoverability by codifying expected user interactions and safe behaviors like dry-run before implementation begins.

What is the correct precedence for command-line config, environment variables, and flags?

The correct precedence for command-line config is flags overriding environment variables, which override project config, then user config, and finally system config. This hierarchy ensures explicit user inputs take priority over global defaults.

How do I structure stdout, stderr, and exit codes for script-friendly command-line tools?

Structure stdout for primary data output using formats like --json or --plain, and reserve stderr for errors and verbose logs. Map top failure modes to specific exit codes so calling scripts can programmatically react to different error states.

What safety rules should I include when refactoring a CLI for dry-run and confirmations?

Include safety rules like --dry-run for previewing state changes, interactive confirmations for destructive actions, --force to bypass prompts, and --no-input for non-interactive environments. These prevent accidental data loss during command execution.

Does this CLI design approach work for both new tools and refactoring existing command-line interfaces?

Yes, this CLI design approach works for drafting a specification for a hypothetical new tool and refactoring an existing command-line interface. It scopes arguments, output rules, and config precedence to improve consistency across both scenarios.