create-cli

Design command-line interface parameters and UX specifications for CLI tools.

Updated Jan 5, 2026
One-click install
npx skills add https://github.com/d3ming/dot-agents --skill create-cli-d3ming
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: create-cli
Source: https://github.com/d3ming/dot-agents/tree/main/master/skills/create-cli
Command: npx skills add https://github.com/d3ming/dot-agents --skill create-cli-d3ming

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Designing command-line interfaces is often inconsistent, unclear, or unfit for both humans and automation; this Skill provides a disciplined rubric to define arguments, flags, subcommands, help, output formats, error handling, and configuration precedence before implementation to avoid costly UX and automation regressions.

Core Features & Use Cases

  • Deliverable-driven CLI specs: Produce a compact, implementable spec including command trees, USAGE synopsis, args/flags tables, subcommand semantics, and example invocations.
  • I/O and error contracts: Define stdout vs stderr behavior, JSON/plain modes, exit codes, and diagnostics suitable for scripting and interactive use.
  • Safety and configuration rules: Specify dry-run/force semantics, prompt behavior, config/env precedence (flags > env > project > user > system), and shell completion/distribution notes.
  • Use Cases: Creating a new tool interface, refactoring an inconsistent CLI, or standardizing CLI UX across an organization to improve discoverability and automation.

Quick Start

Design a CLI spec for a command named mycmd that includes a usage line, subcommands with clear semantics, an args and flags table (types and defaults), --json output mode, config precedence rules, safety flags like --dry-run and --force, and five example invocations.

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 command-line interface specification before implementation?▼

Designing a command-line interface specification involves defining the command tree, usage synopsis, args/flags tables, and subcommand semantics upfront. This approach produces a compact, implementable spec that prevents costly UX and automation regressions before writing any code.

What is the standard config precedence for CLI tools and flags?▼

Standard config precedence for CLI tools follows a strict hierarchy: flags override environment variables, which override project, user, and system configurations. Establishing this precedence ensures consistent behavior across interactive terminals and CI automation systems.

How do I structure stdout, stderr, and exit codes for scriptable CLI tools?▼

Structuring stdout, stderr, and exit codes requires defining clear I/O and error contracts. You should separate stdout for data output from stderr for diagnostics, implement JSON/plain modes, and specify exit codes suitable for both interactive use and scripting.

What safety flags should a command-line interface include for CI systems?▼

Safety flags for command-line interfaces should include dry-run and force semantics, alongside specific prompt behaviors. Defining these rules ensures your CLI operates safely across interactive terminals and automated CI systems without unintended side effects.

Can I use this CLI design rubric to refactor an existing command surface?▼

Yes, you can apply this CLI design rubric to refactor existing command surfaces. It helps standardize inconsistent interfaces by redefining arguments, flags, subcommands, and error contracts into a clear, implementable specification for humans and automation.

When do I need a formal CLI specification with a command tree and usage synopsis?▼

You need a formal CLI specification when creating a new tool interface or standardizing UX across an organization. Producing a command tree, usage synopsis, and example invocations ensures your command-line interface remains discoverable, scriptable, and consistent.