Requirement Elicitation

需求挖掘（Requirement Elicitation）—— cc-master dev skill

你已经会各种访谈技巧——five whys、jobs-to-be-done、开放式提问。这个 skill 装的是技巧清单装不下的东西：对「一个用户请求到底是什么」的信念（conviction），和「何时、挖多深」的品味（taste）。这里故意没有问题清单；一个握住信念的模型，即兴出的问题比任何脚本都好。

它在本仓的位置：这是 cc-master dev 流的需求发现闸，取代通用的 superpowers:brainstorming（这一步内置于本仓、接地到本仓的形态，让造 / 评 / 治三件套有一个自洽的上游）。它是 发现 → 准入（curating）→ 造 body（skillsmith）→ 度量（grounding） 这条链最上游的一环。

核心信念（道）

用户的字面话是症状——往往是对一个没说出口的问题猜出来的解法——绝不是需求本身。 "加个导出按钮"是用户在替你干活：他感到了某种疼，私下假设了一个修法，把这个假设递给了你。照着假设造，你可能交付一个让疼痛原封不动的功能。需求，是那个让他想要这个按钮的东西。

cc-master 把这条信念落在它自己的形态上，而不是某套外部领域模型里。orchestrator 的 board 以一个 goal 为根，整张任务依赖图都从它派生——goal → DAG → tasks。坐下来想想这意味着什么：整条下游工作的源头是一次「解读」。 如果这次解读错了，整张依赖图——每个被派发的任务、每次端点验收——都是从一个谎言正确地推导出来的。下游再严谨也修不好一个读错的源头。需求发现，是整个系统要么被夯实、要么被毒化的那一刻。

造 skill 时同理：真实需求是 发现 → 准入 → 造 → 度量 这条链的根。读错它，三件套会忠实地在一个错前提上各自执行到底——curating 给一个不该存在的能力跑出漂亮的 scoresheet，skillsmith 把它的 body 写得形质俱佳，grounding 还煞有介事地度量它。全程无误，全程错。

这正是本仓「no-silent-failure / gate-green ≠ passed」那条红线在需求发现阶段的同构：端点验收逼你区分「闸绿了」和「真过了」；需求发现逼你区分「用户原话」和「你的推断」、「猜出来的需求」和「确认过的需求」。系统从不让一次解读冒充一个逐字事实——对话里你也别。

命名即建模：发现就是第一次建模

Eric Evans 把领域建模的前端叫 knowledge crunching：领域模型与统一语言（ubiquitous language）既不是从专家嘴里抄录、也不是设计者凭空发明，而是从专家与设计者的协作对话中涌现。这里的领域专家就是用户。你不是在誊抄一张订单，你是在和用户一起共同发现一个关于他的问题的模型。

每一次需求对话本身已经是第一次建模会议：你和用户收敛到的那些词，就是候选的统一语言——它们日后会硬化进这个 skill 的 description / DESIGN.md、或 board 的 goal 陈述。所以发现阶段的命名是承重的，当它承重来对待。

发现的品味（The Discovery Sensibility）

这些是要握住的判断，不是要执行的步骤——每一条在 discovery_moves.md 里展开（连同它为什么能逼出真相、做好与做砸长什么样）：

• 追 job，别追 feature。 每个被请求的功能背后，都有一个用户想搞定的 job。功能只是这个 job 的一个候选「雇员」——通常不是最好的那个。
• 没有一个它真在疼的具体实例，你就还没理解这个需求。 用户陈述的抽象（"我需要更好的可见性"）是未经验证的理论；一个最近的具体片段（"上周二我花了一小时重建 agent 夜里干了什么"）才是证据。把片段抠出来。
• 把痛点和提议的方案分开。 绝对尊重痛点；松松地握住方案。前者用户是不容置疑的权威，后者他和你一样是个猜的。
• 够向「极度具体」。 含糊的需求产出含糊的设计。需求真正栖身之处，是那个最窄、最具体到扎心的版本。
• 用用户自己的话把需求复述回去。 这既是验证（他现在就纠正你的误读，而不是等你造完），也是语言锻造（他的纠正就是正在诞生的统一语言）。

协作的姿态（The Collaborative Stance）

好的设计文化靠的是对话，不是审讯，也不是独白。别要求用户给你一份 spec——他没有，假装他该有就是推诿。也别消失一阵、回来甩一份成品设计让他盖章——那是在浪费他的判断力。工作节奏是：带一个 **strawman（草人）**给用户去反应、讨论，然后推荐。人纠正一个具体的错东西，远比凭空指定一个抽象的对东西在行——strawman 把用户的默会知识转换成纠正，而那恰是你直接问问不出来的知识。本仓的设计节奏就是这条：strawman → 讨论 → 推荐。用户共同思考，你共同发现。

设计闸（The Design Gate）

发现流向设计，设计流过一道闸：在一份设计被呈现、用户批准之前，不准有任何实现动作——不写代码、不搭脚手架、不调用任何实现型 skill（包括不要跳进 skillsmith 去写 body）。 这与「感觉上多简单」无关。"简单"的请求恰恰是未经审视的假设最能作乱的地方，因为没人觉得需要检查；一个真正简单的改动，它的设计也许就三句话——但呈现它不是可选项。

闸上活着三个判断：

• 先定范围，再抠细节。 如果请求捆了几个独立子系统，在精修任何东西之前先把这点标出来——拆分先于设计，每一块再各走自己的「发现 → 设计 → 计划」循环。花在打磨一个本该拆开之物的细节上的问题，是浪费的问题。（当这次拆分是关于「这是不是该拆成几个 skill」时，把它交给 curating-skill-portfolios 的「先拆」判定。）
• 带方案来，别带既成事实。 呈现 2–3 个候选路子，带 trade-off 和一个推荐——把 strawman 姿态用在设计高度上。当一个命名清晰的真分叉冒出来时，用本仓既有的裁决手段（/codex 第二意见 / eng-review）出证据支撑的判决，而不是把它当作业丢给用户。
• 先落地设计，再让用户读。 经验证的设计写进 design_docs/plans/（gitignored 草稿，永不入版本控制）；值得永久保留的决策与形状，按 adrs/AGENTS.md 的约定晋升到 adrs/ / design_docs/。用户在实现计划开始前先读这份书面设计——他在这道闸上的纠正，是你这辈子能拿到的最便宜的纠正。

红线与反模式（术）

• 反模式：理解之前就上方案。 在没搞清真实痛点时就造那个字面请求——你把交付优化得很好，交付的却可能是个无关紧要的东西。
• 反模式：把用户提议的方案当成需求。 他的方案是关于需求的线索，不是需求本身；锁死在它上面会堵掉更好的答案，还把他的猜测裹上你的权威发出去。
• 反模式：诱导证人。 嵌着你假设的问题（"那你会想要这个是异步的吧？"）收割的是附和，不是信息——用户的礼貌会确认你种下的任何东西。
• 反模式：没有具体实例的抽象。 如果你和用户都指不出一个该需求在疼的具体片段，你俩都在空想——你其实还没理解它。
• 红线：绝不把一个猜出来的需求当成已确认的来往下走。 这就是「no-silent-failure」用在发现上：一个未经验证的解读被无声地往下游传，就是发现阶段版本的「吞掉异常」。如果你并不真的知道真实需求，就明明白白说出来、去挖——就像端点验收逼你诚实标注「闸绿 ≠ 真过」一样，这里也别让「我以为」冒充「我确认」。

移交（Hand-off）

当真实需求被说清、被用户对着一个具体实例确认、词汇也在稳定下来——发现就完成了它的活。从这里：

• 若需求落成「造 / 改一个 skill」 → curating-skill-portfolios 判要不要建 / 放哪 / 会不会重叠（带着你锻造出的词汇当输入），过了准入再 cc-master-skillsmith 写 body、grounding-skill-evals 度量。
• 若需求落成一次 feature / hook / 文档改动 → 走本仓正常实现流（按 AGENTS.md §4：superpowers:test-driven-development 主导 Red-Green-Refactor，卡住用 superpowers:systematic-debugging 或 /investigate）。
• 若竞争方案在对话里冒出来 → 用 /codex / eng-review 仲裁，别回头去重新litigate需求。
• 编排层面的事（怎么把已批准的 goal 拆图、派发、驱动到完成）→ master-orchestrator-guide；其中 workflow 脚本怎么写 → authoring-workflows。

在 orchestrator 模式下

当你作为长 horizon master orchestrator 运行（如 cc-master 的 as-master-orchestrator），直接应用这个 skill：和用户的前台需求发现对话是指挥自己的活，绝不外包。它与后台执行并行——对话需要的侦察（reconnaissance）派个 sub-agent 去做，对话本身继续。设计闸映射到编排 board 上，就是一个 user-blocked 决策节点：批准是一条只有用户能解的异步依赖；它一可预见就立刻 surface，只有依赖这个答案的工作才等。

这一节只点边界，不复述编排的 how——「前台对话 ∥ 后台执行」的调度机制、async-HITL、p95 hedging 全在 master-orchestrator-guide（镜头 7 + references/async-hitl.md）。本 skill 管「挖什么需求、为什么」，那个 skill 管「怎么把对话当 async worker 调度」。