create-cli

核心用法

create-cli 是一个纯文档型指导技能，专注于命令行界面（CLI）的前期设计阶段。当用户需要从零设计 CLI 规范或重构现有 CLI 时，该技能提供系统化的设计框架。核心流程包括：首先读取内置的 CLI 设计指南（基于 clig.dev 社区标准），然后通过最小化提问快速锁定需求（命令名称、目标用户、输入输出约定、交互模式、配置层级等），最终输出可直接落地的 CLI 规范文档。

显著优点

1. 权威背书：直接引用 clig.dev 这一业界公认的 CLI 设计指南，确保设计决策符合社区最佳实践。
2. 语言无关：不绑定特定编程语言或解析库，输出的规范可被任何技术栈实现。
3. 交付物完整：提供命令树、参数表、退出码映射、安全规则、配置优先级、Shell 补全方案等全套设计资产。
4. 人性化优先：内置 TTY 检测、NO_COLOR 支持、Ctrl-C 处理等细节，平衡人类可读与机器可解析。
5. 安全内建：默认要求破坏性操作需确认，提供 --dry-run、--force、--no-input 等安全开关的设计模板。

潜在缺点与局限性

• 非实现工具：仅输出设计规范，不生成可执行代码，开发者仍需手动实现。
• 模板化约束：对于高度定制化的 CLI（如交互式 TUI、复杂状态机），标准模板可能需要扩展。
• 无自动化验证：不检查设计规范与实际实现的一致性，需团队自行维护。
• 社区标准局限：clig.dev 偏向 Unix 传统，对 Windows-native 或企业级 GUI 化 CLI 的覆盖有限。

适合的目标群体

• 后端/工具开发者：需要为内部平台或开源项目设计 CLI 工具。
• DevOps 工程师：构建自动化脚本友好的命令行工具。
• 技术产品经理：评审团队 CLI 设计的一致性和可用性。
• 开源维护者：统一多命令工具的交互体验。

使用风险

• 设计-实现鸿沟：规范文档可能被误读或执行偏差，建议配合代码审查。
• 过度设计：新手可能套用全部模板导致 CLI 过于复杂，需根据实际场景裁剪。
• 版本漂移：clig.dev 指南会演进，内置引用文档可能滞后于上游。

核心用法

create-cli 是一个纯文档型技能，专注于在编码前设计命令行工具的完整接口规范。用户只需提供命令名称、目标用户（人/脚本/两者）、输入输出偏好等最小信息，即可获得可直接交付开发的标准化 CLI 规格。

典型工作流：
1. 读取内置的 cli-guidelines.md 作为设计基线
2. 通过快速澄清问题锁定需求（通常 3-5 个关键问题）
3. 输出包含命令树、参数表、退出码、配置优先级、示例用法的完整规格文档

显著优点

• 标准化输出：强制遵循 clig.dev 的 CLI 人机交互最佳实践，避免"每个命令行风格都不一样"的混乱
• 安全优先设计：内置 --dry-run、确认提示、--no-input、信号处理等安全模式的规范要求
• 双模友好：同时考虑人类交互（TTY 检测、颜色、进度）与脚本调用（--json、--plain、确定性的退出码）
• 配置体系完整：明确定义 flags > env > project config > user config > system 的优先级链，支持 XDG 规范
• 零实现漂移：严格区分"设计参数"与"实现细节"，防止讨论范围蔓延

潜在局限

• 语言无关性：不绑定具体解析库（如 Python argparse、Go cobra、Rust clap），需开发者自行映射到实现
• 无代码生成：仅输出 Markdown 规格，不生成可编译的骨架代码（相比 cookiecutter、plop.js 等工具）
• 生态依赖：最佳实践引用 clig.dev，若该指南更新而技能未同步，可能存在 slight 偏差
• 复杂 CLI 边界：对于需要插件系统、动态子命令发现、GUI 嵌入等高级场景，模板需大量自定义扩展

适合人群

• CLI 工具开发者：在投入编码前固化接口契约，减少后期 breaking change
• DevOps/SRE 团队：统一内部工具集的用户体验标准
• 技术写作者：生成结构化的帮助文档草稿
• 开源维护者：为 PR review 提供客观的 CLI 设计检查清单

常规风险

• 设计过度：可能诱导为简单脚本输出过于繁复的规格，建议配合"最小可行 CLI"判断
• 实现偏差：规格与最终代码可能不一致，需配套测试（如 CLI 快照测试）保障
• 平台假设：默认假设类 Unix 环境，Windows PowerShell/CMD 的特殊处理需额外说明