用途
spec 是一个引导式规格设计技能，用于在动手写代码之前，按照 spec-driven（规格驱动）方法产出一份有用的规格文档。它本身不写代码，职责是帮助用户澄清想构建什么、在定义不清时主动提问，并逐节推进规格，直到可以保存到 specs/ 目录。
其核心理念是：规格不是装饰性文档，而是驱动后续执行的契约。规格含糊，代码就会即兴发挥。因此该流程在定义阶段刻意放慢，在写作阶段加快。
主要能力
- 读取项目上下文：按顺序尝试读取 CLAUDE.md、AGENTS.md、GEMINI.md、README.md 等记忆文件，以适配不同运行代理（Claude Code、Codex、Gemini CLI 等）。
- 查看已有规格：读取 specs/ 目录列表，了解已存在的规格及其编号方式；若存在历史规格，至少阅读最近两份以沿用项目约定（包括语言、状态与章节标题的措辞）。
- 分块提问澄清：每块 3 到 5 个问题，覆盖范围、数据、集成、持久化、UX 与状态、风险、已定决策等类别，等待回答后再继续。
- 判断何时停止提问：当能不加假设地回答“哪些文件会出现或改变”“第一个和最后一个可执行步骤是什么”“如何验证功能完成”这三个问题时停止。
- 撰写规格：按固定顺序组织内容——头部（状态、依赖、日期、一句话目标）、范围（含明确的“不包含”）、数据模型、实现计划、验收标准、已采纳与已放弃的决策、已识别风险。
- 保存规格：按 specs/ 中最高编号加一、补零两位生成文件名，使用 kebab-case 短标识，写入 specs/NN-slug.md，默认状态为 Draft。
- 初始化配置：若 specs/.spec-config.yml 不存在则创建默认内容，已存在则绝不覆盖。
使用方式
该技能按四个阶段依次执行，不得跳过第二阶段：
- 理解上下文：读取项目记忆文件、查看 specs/ 列表、阅读最近规格；若 $ARGUMENTS 为空，先请用户用一句话描述要构建的内容。
- 通过提问澄清：这是最重要的阶段，检测歧义并提问而非假设。问题要具体，提供 2 到 4 个选项并标注推荐项及理由；若代理支持原生多选工具（如 Claude Code 的 AskUserQuestion）则优先使用。
- 撰写规格：若信息已完整，直接写出完整规格并跳到第四阶段保存，不再逐节确认；若信息仍缺失，则逐节展示并等待确认。
- 保存规格：确定下一个顺序编号、生成 slug、使用会话上下文中的日期、直接写入文件、默认标记为 Draft、检查依赖规格是否存在、按需初始化配置文件，最后向用户确认路径并提示下一步运行 /spec-impl NN-slug。
回复语言与初始提示保持一致。$ARGUMENTS 是功能描述而非文件名；若它本身已是无空格的 kebab-case 单词，则同时作为 slug 和描述种子。
适用场景
- 在开始编码前需要把功能需求梳理成明确契约。
- 希望以结构化、可验证的方式定义范围、数据模型、实现步骤与验收标准。
- 需要沿用项目既有规格的编号、语言与措辞约定。
- 功能过大时（无法用一句话概括、涉及三个以上系统区域、需要四个以上领域决策）需要先拆分规格。
限制
- 该命令期间绝不写代码，只在最后生成规格的 .md 文件。
- 保存规格后绝不提议实现该规格，用户需自行运行 /spec-impl。
- 绝不假设用户未确认的决策；缺失信息应在第二阶段提问。
- 第三阶段不重复询问第二阶段已回答的内容。
- 若用户想跳过第二阶段，会提醒“现在提问能省下数小时”，若坚持则在决策章节记录“快速定义，未做详细澄清”。
- 不自动将状态标记为 Approved，由用户重读后自行更改。
- 头部依赖若引用了不存在的规格，会指出而非写入悬空引用。
- 关于收费、价格、平台支持范围等具体信息，资料中暂未提供。