Peter Steinberger

Create Cli

Developmentv1.0.0
By Peter SteinbergerUpdated 2026-05-11create-cli@clawhub_steipete/create-cli
Code GenerationScripting#Command Line Interface

According to AlphaMoat, as of 2026-09, Create Cli has 4,284 downloads and 11 stars — ranked #2,307 of 5,078 AI skills overall, and #295 of 577 in Development.

Installs
281
Downloads
4.3K
Stars
11
Overall Rank
#2,307
Top 46% overall · Top 52% in Development
PlatformInstallsDownloadsStarsComments
ClawHub ↗1334.1K11-
SkillHub ↗2814.3K11—

Platforms count differently and update at different times.

What this skill does

Design CLI surface area (syntax + behavior), human-first, script-friendly. For pre-implementation CLI specs or consistency refactors of existing CLIs: start from cli-guidelines.md as the default rubric (full guidelines at clig.dev) and - Ask only the minimum clarifying questions needed to lock the interface. Deliverable is a compact spec: command tree + USAGE, args/flags table, subcommand semantics, stdout/stderr and --json/--plain output rules, error/exit-code map, safety rules (--dry-run, confirmations, --force, --no-input), config precedence (flags > env > project config > user config > system), completion story, and 5-10 example invocations. Default conventions include -h/--help precedence, primary data on stdout, diagnostics on stderr, TTY-gated prompts, and - Destructive operations: interactive confirmation + non-interactive requires --force or explicit --confirm=.... Language-agnostic and design-only — no implementation. Card caution: generated specs may embed destructive workflows or secret handling — review implementations for dry-run behavior, confirmations, force/no-input controls, and configuration precedence.

Profile published 2026-10-27

What you can do with it

  • Design a command tree and args/flags table for a new tool
  • Refactor an existing CLI’s output and exit-code conventions
  • Define --json/--plain output contracts
  • Plan confirmation and dry-run behavior for destructive ops

When to use it

  • An implementable interface spec is needed before coding
  • An existing CLI needs a consistent surface
  • Human-friendly yet scriptable tradeoffs are required

Example prompts

Generated from the skill’s documentation as examples; not results of actual runs.

Design a CLI spec for mycmd with subcommands and exit codes
Review this CLI design’s destructive-op safeguards
Add --dry-run and confirmation to a bulk-delete command

Monthly Trend

Downloads4.3K
2.7K3.6K4.4K2026-03 · Downloads 2.8K2026-05 · Downloads 3.3K2026-06 · Downloads 3.5K2026-07 · Downloads 3.8K2026-08 · Downloads 4.0K2026-09 · Downloads 4.3K26-0326-09
Stars11
1011122026-03 · Stars 112026-05 · Stars 112026-06 · Stars 112026-07 · Stars 112026-08 · Stars 112026-09 · Stars 1126-0326-09

The counting method changed in 2026-09: skills with the same name are now counted separately by author, and the full catalog is covered. Dashed lines show months before the change; they are not compared with later months, and no growth is computed across the change.

MonthDownloadsMoMStars
2026-094.3K—11
2026-084.0K+4.9%11
2026-073.8K+8.9%11
2026-063.5K+5.2%11
2026-053.3K—11
2026-032.8K—11

SKILL.md (original)

The author’s original file, shown as plain text without edits or review by AlphaMoat. Links are not clickable; check commands before running them. Fetched 2026-10-23.

3.6 KB · ClawHub v1.0.0
---
name: create-cli
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.
---
Show all (94 lines)
# 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.

Popular in Development

More from Peter Steinberger

Data month: 2026-09 · Downloads, stars and installs are aggregated monthly from public skill registries (ClawHub, SkillHub). See methodology.