dev-cli-tooling-workflow

What it does and when to use it

Use to design, implement, review, or test CLI tools, flags, config precedence, terminal UX, errors, and docs.

How it works

1. Steps
2. Output
3. Do not

---
name: dev-cli-tooling-workflow
description: Use to design, implement, review, or test CLI tools, flags, config precedence, terminal UX, errors, and docs.
metadata:
  version: "0.3"
  updated: "2026-06-12"
---

# CLI tooling workflow

Use this workflow when a task changes or creates a command-line interface.

## Steps

1. Map the existing command surface.
   - Entry points
   - Help output
   - Subcommands
   - Flags and environment variables
   - Config file discovery
   - Output formats
   - Exit codes

2. Define user flows.
   - Human interactive use
   - Script/CI automation
   - Debug mode
   - Offline or failure behavior

3. Design compatibility.
   - Preserve existing flags and output where scripts may depend on them.
   - Add explicit non-interactive modes for automation.
   - Keep stdout/stderr separation intentional.

4. Implement ergonomically.
   - Clear help text
   - Useful error messages
   - Stable exit codes
   - Sensible defaults
   - Shell completion or config docs when appropriate

5. Validate.
   - Run `--help` or equivalent.
   - Run at least one success path and one failure path when feasible.
   - Add tests for parsing, config precedence, and exit behavior.

## Output

Return:

1. CLI surface
2. Compatibility notes
3. Implementation or review summary
4. Commands run
5. Remaining risks

## Do not

- Do not add prompts that block automation without a bypass.
- Do not silently change stdout, JSON shape, or exit codes.
- Do not invent config precedence without checking existing docs or code.

Versions

The database has no other skills named dev-cli-tooling-workflow.

Identical content appears in 1 other GitHub folders. We show one copy with the highest score.

Database snapshot: 13.11.2026 · package version fb6220d93b86 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

• 90cli-design-and-arg-parsing
  Design a CLI's command/subcommand surface, flags vs positionals, and config precedence (flags > env > file > default), then pick the idiomatic parser for the language. Use when starting a CLI or reworking a messy one.
• 100create-cli
  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…
• 100creating-cli-tools
  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…
• 100task-dev
  按 AAW task-dev 工作单实现一个明确的 T[N] 任务，并通过 CLI 持久化阶段状态。实现与测试先交 implementation.json，随后语义 Review、修复重验、CodeCheck 与候选提交信息合并交一份 completion.json。Use when the user asks to 实现当前 Task、执行 task-dev、继续或恢复 T1/T2 开发。支持严格模式（SR/AR 入口，以模块详细设计与测试用例设计为事实来源）与轻量模式（dev 入口，以 dev-design.md 与 test-design.md…
• 90dev-workflow
  Standardized Github operations, Diátaxis documentation framework, and visual assets. Use when: git workflow, github, gh cli, documentation, diataxis, restructure docs.
• 100create-cli
  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…