create-cli
This specification defines command structures, input contracts, and safety protocols for creating script-friendly CLI tools.
Install
mkdir -p .claude/skills/create-cli && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/3039" && unzip -o skill.zip -d .claude/skills/create-cli && rm skill.zipInstalls to .claude/skills/create-cli
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
CLI UX/spec: args, flags, help, output, errors, config, dry-run.Key capabilities
- →Designs command-line argument and flag structures
- →Defines standard error codes and help patterns
- →Implements safety conventions like dry-runs
- →Specifies config and environment variable precedence
How it works
It applies established CLI guidelines to generate a specification that mandates consistent flag behavior, help formatting, and exit codes.
Inputs & outputs
When to use create-cli
- →Defining CLI argument specs
- →Designing error and help text patterns
- →Creating CLI interface documentation
About this skill
Create CLI
Design CLI surface area (syntax + behavior), human-first, script-friendly.
Do This First
- Read
agent-scripts/skills/create-cli/references/cli-guidelines.mdand 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/--helpalways shows help and ignores other args.--versionprints version to stdout.- Primary data to stdout; diagnostics/errors to stderr.
- Add
--jsonfor machine output; consider--plainfor stable line-based text. - Prompts only when stdin is a TTY;
--no-inputdisables prompts. - Destructive operations: interactive confirmation + non-interactive requires
--forceor 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:
- Name:
mycmd - One-liner:
... - USAGE:
mycmd [global flags] <subcommand> [args]
- Subcommands:
mycmd init ...mycmd run ...
- Global flags:
-h, --help--version-q, --quiet/-v, --verbose(define exactly)--json/--plain(if applicable)
- I/O contract:
- stdout:
- stderr:
- Exit codes:
0success1generic failure2invalid usage (parse/validation)- (add command-specific codes only when actually useful)
- Env/config:
- env vars:
- config file path + precedence:
- 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.
When not to use it
- →Designing complex GUIs
- →Web-based API service definitions
Limitations
- →Cannot generate the implementation code, only the specification
- →Requires user input to define specific command-line intents
How it compares
It prioritizes scriptability and industry-standard CLI usability patterns over custom interface design.
Compared to similar skills
create-cli side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| create-cli (this skill) | 1 | 3mo | No flags | Beginner |
| mermaid-diagrams | 8 | 6mo | No flags | Beginner |
| design-review | 0 | 5mo | No flags | Intermediate |
| design-system | 0 | 1mo | No flags | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by steipete
View all by steipete →You might also like
mermaid-diagrams
davila7
Comprehensive guide for creating software diagrams using Mermaid syntax. Use when users need to create, visualize, or document software through diagrams including class diagrams (domain modeling, object-oriented design), sequence diagrams (application flows, API interactions, code execution), flowcharts (processes, algorithms, user journeys), entity relationship diagrams (database schemas), C4 architecture diagrams (system context, containers, components), state diagrams, git graphs, pie charts, gantt charts, or any other diagram type. Triggers include requests to "diagram", "visualize", "model", "map out", "show the flow", or when explaining system architecture, database design, code structure, or user/application flows.
design-review
Harries
设计文档评审。当用户需要评审设计文档质量、检查设计合理性、发现设计缺陷,或询问"帮我评审设计文档"、"检查设计质量"时使用。
design-system
nguyennd93
Guided, section-by-section GDD authoring for a single game system. Gathers context from existing docs, walks through each required section collaboratively, cross-references dependencies, and writes incrementally to file.
functional-design
Fuga578
機能設計書を作成するための詳細ガイドとテンプレート。機能設計書作成時にのみ使用。
architecture-decision-records
wshobson
Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architectural choices, or establishing decision processes.
deepwiki-rs
sopaco
AI-powered Rust documentation generation engine for comprehensive codebase analysis, C4 architecture diagrams, and automated technical documentation. Use when Claude needs to analyze source code, understand software architecture, generate technical specs, or create professional documentation from any programming language.