Name: Create Cli
Author: Peter Steinberger

據 AlphaMoat 統計,截至 2026-09,Create Cli 累計下載 4,284 次、獲 11 個星標,在全部 5,078 個 AI 技能中排名第 2,307 位,在「開發程式設計」分類(577 個)中排名第 295 位。

累計安裝

281

累計下載

4284

星標

全站排名

#2,307

全站前 46% · 「開發程式設計」前 52%

平台	累計安裝	累計下載	星標	評論
ClawHub ↗	133	4134	11	-
SkillHub ↗	281	4284	11	—

各平台的計數口徑不同,統計時間不一致。

這個技能是做什麼的

Design CLI surface area (syntax + behavior), human-first, script-friendly. 面向實現前的 CLI 規格設計或既有 CLI 的一致性重構：先讀 cli-guidelines.md 作為預設評分標準（完整版見 clig.dev），- Ask only the minimum clarifying questions needed to lock the interface. 交付物是一份緊湊規格：命令樹與 USAGE、引數/標誌表、子命令語義、stdout/stderr 與 --json/--plain 輸出規則、錯誤與退出碼對映、安全規則（--dry-run、確認機制、--force、--no-input）、配置優先順序（flags > env > 專案配置 > 使用者配置 > 系統）、補全方案與 5-10 個示例呼叫。預設約定包括 -h/--help 優先、主資料走 stdout、診斷走 stderr、僅 TTY 時提示互動、- Destructive operations: interactive confirmation + non-interactive requires --force or explicit --confirm=.... 保持語言無關、只做設計不寫實現。card 提醒：生成的規格可能包含危險操作或金鑰處理邏輯，實現後需複查 dry-run、確認、force/no-input 與配置優先順序等安全行為。

資料釋出於 2026-10-27

可以用來做什麼

為新工具設計命令樹與參數列
重構既有 CLI 的輸出與退出碼約定
定義 --json/--plain 等輸出契約
規劃破壞性操作的確認與 dry-run 行為

什麼時候用

CLI 實現前需要一份可落地的介面規格
既有命令列工具需要統一風格
需要人友好且指令碼友好的介面權衡建議

示例提示詞

以下是根據技能文件生成的示例,不代表實際執行結果。

為 mycmd 設計包含子命令與退出碼的 CLI 規格

審查這個 CLI 設計的破壞性操作保護

給批次刪除命令補上 --dry-run 與確認流程

月度資料趨勢

累計下載4284

星標11

2026-09 起統計方法調整:同名技能按作者分別統計,並覆蓋全部技能。圖中虛線為調整前的月份,與之後的資料不直接比較,也不計算跨越調整的增長。

月份	累計下載	環比	星標
2026-09	4284	—	11
2026-08	3997	+4.9%	11
2026-07	3812	+8.9%	11
2026-06	3500	+5.2%	11
2026-05	3327	—	11
2026-03	2826	—	11

SKILL.md 原文

以下是作者釋出的原始檔案,按純文字顯示,本站未做修改或稽核;其中的連結不可點選,命令請核實後再執行。抓取於 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.
---

展開全部(共 94 行)

# 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.