cap-define

cap-define — 收敛阶段：模糊点子 → 获批规格

入口先执行 ../cap/SKILL.md 的“研发上下文门禁”：.cap 检查不可跳过，知识库注入失败可记录后离线继续。

全程契约：开始实质工作前读取并执行 ../cap-flow/references/progress-protocol.md 与 ../cap-flow/references/task-reconnaissance.md。先播报当前动作和下一步；新任务没有新鲜 .cap/task-context.md 时，先调查当前仓库代码，不能只依赖 PROFILE。

把"想做点什么"变成一份获批的、无歧义、能被 cap-plan 直接吃进去的规格。

铁律(HARD-GATE):spec 拿到用户批准之前,不写任何实现代码、不搭脚手架、不调任何实现类阶段。 需求看起来越简单越危险——"简单"往往是没被检视的假设,返工最多都出在这。规格可以很短(简单需求几句话), 但必须呈现并获批。

本阶段是 cap-flow 派来的收敛器:知识与状态都是纯文件,引擎 = 一个能 Read/Edit/Bash/Grep 的模型。 唯一的终态 = 产出获批 spec.md + 把交接写回 STATE,由 cap-flow 路由到 cap-plan。

---

0. 可移植前置（每次入口先做）

共享 references 的位置:本文引用的 role-routing.md、divergence-frames.md、roles/<role>.md、 web-review/playbook.md 物理上都在编排器目录 cap-flow/references/ 下,不在本阶段目录里。解析路径一律 指向 cap-flow/references/...(相对 skills 根)或经软链接定位,别当相对本目录读。

本阶段要在 Claude 和 Codex 上都能跑。两条降级范式贯穿始终:

0.1 交互降级 —— 纯文本编号选项（默认）

凡向用户提问(澄清、选方案、确认范围、过门),默认用纯文本编号列表,不硬依赖任何富交互控件:

需要你定一个点:
  1) 选项 A —— 说明 / 取舍
  2) 选项 B —— 说明 / 取舍
  3) 其它(你来描述)
回个编号即可(或直接补充文字)。

宿主有结构化提问控件可以用,但回退路径永远是上面这种编号文本。若用户选"其它"又没填内容 → 输出一行 "你想补充什么?" 然后停下等,别重问、别自答。

0.2 并行降级 —— 能并行就并行，不能就串行

本阶段的外部研究(§3 可选)若要多源调研:探测宿主有无并行能力——有 → fan-out 子调研,各写各的临时 笔记;无 → 串行 inline 跑同一份 playbook。任何时候不得两个写手同写 STATE.md / spec.md(单写者)。

---

1. 入口条件

进入本阶段应满足(cap-flow 保证;独立调用时自检):

条件	要确认的事
有 <target-repo>/.cap/PROFILE.md,或确认是 greenfield	有 PROFILE 即可;brownfield 缺 PROFILE 应先 cap-understand
STATE.stage 为 shape,或这是一个全新特性的开始	读 .cap/STATE.md;无 STATE = 新特性,本阶段初始化一份
手头有一个待澄清的"点子 / 需求 / 变更意图"	来自用户原话

入口动作:先看一眼 <target-repo>/.cap/ 有没有 PROFILE / STATE / 既有 spec,再:

• 读 PROFILE.md → 拿技术栈、约定、surface-map(模块 / glob / 默认角色 / 验证项),当 Explore 的地图。
• 读 STATE.md(若有)→ 看 Decisions log 里有没有相关旧决策,别重复问已定的事。

1.0 入口先做：改动面 → 角色 + 验证项 预解析

即便本阶段还没真动代码,也要先定本特性"打算动哪块 surface",因为它决定:

• 要不要在 spec 里前置 eval 契约(动 AI / 模型 / 策略 → 必须,见 §5);
• 后续 build / verify / review 会装哪些角色卡、跑哪些验证项。