需求两条拆成实践加活动：switch-interview、ears、specification-by-example 进 practices，requirement-elicitation、requirement-specification 进 flow-steps，flow 指向新名，评测齐（#119）

plugins/docs/skills-overview.md

@@ -4,14 +4,16 @@
 
 一个 skill 一个目录：`plugins/<plugin>/skills/<skill>/SKILL.md`，旁边可放 `evals/evals.json`；插件级 `evals/` 下的 `claude plugin eval` 用例也算有 evals。装配用 `sk`（源码 `packages/sk`；profile 的 manifest.json 是声明，junction 是投影）。
 
-共 33 个 Skill，13 个 Plugin。
+共 38 个 Skill，13 个 Plugin。
 
 | Skill | Plugin | 版本 | L2 字节 | evals | description |
 |---|---|---|---|---|---|
 | `adaptive-problem-solving` | adaptive-problem-solving | 0.2.14 | 9389 | 无 | 用于问题含糊、关键路径选择、波次／里程碑反思、高成本或难回退动作、范围／成本变化、停滞、恢复／交接／验收／长期收口，或检查方向、方法、ROI、模型、上下文、工具、环境与 Agent 组合。恢复原问题和主瓶颈，比较普通路径与方法后组合、换路或… |
 | `clarify` | clarify | 0.1.0 | 4241 | 有 | 主人冒出「想建 X／要不要搞一个／这个流程好烦」一类念头时，把「解」翻回「问题」，判断该不该做；只产出三行结论。不建则建一条 issue 写理由后以 wontfix 关闭，建则挂机会 issue。Turn an itch phrased a… |
-| `flow` | flow | 0.1.3 | 10371 | 有 | 判为常规变更、或主人开场直接敲了阶段里的 skill 时读：常规变更的路线——九个阶段的门与产物、每个阶段点名的活动、改旧代码时才开的活动、会话绑定、站会记录。The route for a normal change: nine stag… |
+| `flow` | flow | 0.1.3 | 10383 | 有 | 判为常规变更、或主人开场直接敲了阶段里的 skill 时读：常规变更的路线——九个阶段的门与产物、每个阶段点名的活动、改旧代码时才开的活动、会话绑定、站会记录。The route for a normal change: nine stag… |
 | `regression-evidence` | flow-steps | 0.1.2 | 2377 | 有 | 改旧代码时才开的活动「证」：改完要证明老流程没变、新流程是对的。改代码之前按 record-replay 录母版，改完按 golden-master 回放比对，三样进同一个 PR。The legacy-code activity for p… |
+| `requirement-elicitation` | flow-steps | 0.1.2 | 2914 | 有 | 改旧代码时需求不清才开的活动，第 4 阶段门上定：外来需求还是一句「解」、提出方只能由主人去问时用，把解翻回问题、备好问提出方的问题、查现成，收口成三行加一句可观察的验收判据。Requirement elicitation as a sta… |
+| `requirement-specification` | flow-steps | 0.1.2 | 3235 | 有 | 改旧代码时需求不清才开的活动，第 4 阶段门上定：三行加一句被主人否过之后，把需求翻成可验证的句子——大的先按用例拆，每条规则一句 EARS，每句配一条例子，主人逐句否，例子变测试。Requirement specification as … |
 | `review-response` | flow-steps | 0.1.2 | 2506 | 有 | 收到 code-review 的审查报告时用：逐条对照代码核实、给建议与理由并标违例或判断题，整份报给主人，主人定了再一条一改一测；只说事实与证据。Handle a code-review report: verify each findi… |
 | `rollout-observe` | flow-steps | 0.1.2 | 2423 | 有 | 常规变更第 8 阶段发布时用：按 feature-toggle 定回滚点，按 canary-release 定三档放量与观测点，每档的开关由主人拨；多数改动跳过这一阶段，留一句为什么。Stage 8 of a normal change: … |
 | `verify-evidence` | flow-steps | 0.1.2 | 2157 | 有 | 要说「做成了」「通过了」时用：每条声称配一条刚跑过的命令、退出码和关键输出行，贴进对话再进 PR 正文；没跑过的标「未验证」。Turn claims into evidence: each claim gets a freshly run … |
@@ -23,10 +25,13 @@
 | `canary-release` | practices | 0.1.1 | 3671 | 有 | 改动要放出去时用：三档放量（内部账号或测试模板 → 分流类别的一小部分 → 全量），每档写清放谁、停多久，进下一档由主人定；每条需求句配一个观测点，老路径看四个黄金信号（延迟、流量、错误、饱和）；档 1 放开后拿需求例子打一条冒烟。Cana… |
 | `code-review` | practices | 0.1.1 | 5058 | 有 | 审一条分支、PR 或在制的改动时用：以主人给的固定点取 diff，分标准与 spec 两轴各派一个子代理审，违例与判断题分开标，两份报告并排给出、各轴各自小结。Two-axis code review of the diff since a… |
 | `domain-modeling` | practices | 0.1.1 | 3825 | 有 | 设计途中要敲定领域术语、建或改统一语言、记一条架构决定时用：对着词汇表挑战用词，用具体场景逼清边界，和代码对照，词一定下就写进 CONTEXT.md，只在难回头的取舍上提 ADR。Build and sharpen a project do… |
+| `ears` | practices | 0.1.1 | 2833 | 有 | 把一条已收口的需求写成可验证的句子时用：EARS 五种句式，一句只装一条规则，名词只用原话与词汇表里的，出手前过 ISO 29148 的四条属性。Write requirements in EARS (Easy Approach to Re… |
 | `feature-toggle` | practices | 0.1.1 | 2764 | 有 | 改动要能秒级放开、秒级收回时用：分流开关就是发布开关，初始关；回滚就是关开关，不回滚代码，前提是老路径 diff 为零；开关由主人拨，agent 不拨。Feature toggle (Hodgson, Fowler): the routin… |
 | `golden-master` | practices | 0.1.1 | 4139 | 有 | 要证明改完之后老路径一点没变、新路径是对的时用：以改动前的行为为母版（approved 文件），改后回放同一批请求逐字节比对；老类别比母版，新类别比需求例子的期望值，两类分开写；母版、回放测试、比对结果进同一个 PR。Golden mast… |
 | `grilling` | practices | 0.1.1 | 3167 | 有 | 主人拿一个计划、决定或想法来要压力测试时用：把决定画成一棵树，按前提顺序一轮一题地问到没有一处被默默假设；事实自己查，决定归主人。Grill the user about a plan, decision or idea: walk the… |
 | `record-replay` | practices | 0.1.1 | 3623 | 有 | 要把真实出入参录下来当测试输入时用：先挑一批覆盖新路径每条需求句与老路径每个主要分支的样本请主人否，再在改代码之前用手边的工具（Arthas、日志）录成一请求一文件的仓内 JSON，规整掉时间戳、随机 id 这类每次都变的字段，改后原样回放… |
+| `specification-by-example` | practices | 0.1.1 | 3233 | 有 | 给需求句配例子、让例子变测试时用：每句一条真实入参加期望输出，边界两侧各一条，推不出的数交回主人，举不出例子的句子退回去；主人否过之后例子原样变成测试。Specification by Example: one concrete input… |
+| `switch-interview` | practices | 0.1.1 | 3325 | 有 | 要弄清一条外来需求背后真正的问题、而提出方只能由主人去问时用：按 JTBD 的切换访谈备问题——只问过去发生过的事（上次怎么办的、现在怎么忍的、不做会怎样），答案回来后用四种力读出真正的问题。Prepare and read a Jobs-… |
 | `tdd` | practices | 0.1.1 | 4308 | 有 | 测试先行地做功能或修 bug 时用：先和主人定好要测的接缝，再红到绿一次一个切片；测试只穿公共接口，期望值用独立字面值，只在系统边界 mock。Test-driven development: agree the seams first, … |
 | `self-improvement` | self-improvement | 0.1.7 | 8987 | 无 | 当用户指出 Agent 漂移、误解、重复犯错，要求把任务经验固化为系统改进，或讨论只增概念却不减关键未知、形成决定或可检验资产时，只暂停依赖被推翻假设的路径，重锚原问题、持久记录纠正、诊断原因，并在授权内改进入口提示词或 Skill。最小实… |
 | `skill-appraisal` | skill-appraisal | 0.2.0 | 10450 | 无 | 判定一个 Skill 组该不该进当前装配、归哪些事项、与谁重叠，或对已判定过的组按节拍复核。三种进入：首次判定新候选、补判早已在用但从未判定过的组、按失效条件复核。判定单位是组不是单个 Skill；产出必须留下失效条件与下次最少复核步骤。用… |

plugins/flow-steps/evals/README.md

@@ -121,3 +121,34 @@
 门评测之后正文在审查（第 6 阶段）里按「规程只点名、做法在实践里」删掉了两条里重述实践内容的括号与开头那句「先把三步的顺序说全」，`rollout-observe` 的触发句改成不与 `canary-release` 抢「怎么灰度」；都没有重跑，评测沙箱里没装实践，这几处对沙箱里的 sonnet 只会更难，对装了实践的真实会话没有影响。
 
 结果 JSON 提交前都跑过 `scripts/scrub-eval-results.ts`。
+
+三份结果 JSON 提交前都跑过 `scripts/scrub-eval-results.ts`。
+
+### 0.1.2（2026-09-19，agent-system#119）：两条活动 skill——requirement-elicitation、requirement-specification
+
+`requirement-elicitation`、`requirement-specification` 是从 `plugins/workcoding` 的 `requirement-insight`、`requirement-translation` 拆出来的活动 skill（做法在 `plugins/practices` 的 `switch-interview`、`ears`、`specification-by-example`），第 4 阶段门上定开不开。四个用例，规则副本与上面八条相同；跑法同上，加 `--case 'requirement-*'`，结果目录带 `as119` 标签。评测沙箱只装 flow-steps，活动点名的三条实践在沙箱里读不到，agent 只能凭活动正文里「这一步做什么」那句和自己对 EARS、切换访谈的知识做——这正是活动 skill 该守住的那层。
+
+| 用例 | skill | 测什么 | 该怎么判 |
+|---|---|---|---|
+| `requirement-elicitation-prepare` | requirement-elicitation | 第 4 阶段门上开了它，外来需求是一句「解」，主人下午去问提出方 | 原话一字不改标提出方；断言草案标假设；问提出方的只问过去；查现成写「未查到」；收口三行加一句可观察判据；停下等答案，不写 EARS 句 |
+| `requirement-elicitation-already-closed` | requirement-elicitation | 三行加一句已被主人否过 | 不重备问题、不重写三行，说下一步是需求规约 |
+| `requirement-specification-translate` | requirement-specification | 门上开了它，定稿已否过，只给了模板字段 | 原话标提与验、判拆不拆、一条规则一句 EARS、每句一条例子、名词只用原话与字段、请逐句否并说被否的不覆盖；不写测试不写文件 |
+| `requirement-specification-not-closed` | requirement-specification | 需求没收口就要 EARS 句 | 不把 EARS 清单当规约交出去，指出先要需求获取 |
+
+两条正例各带 `tool_used: Skill` 的 with-only 指示器；llm grader 判可观测行为（问的是不是过去的事、有没有例子、停在哪），`elicitation-content` 列了五个面，与上面的做法相同；`translate` 的六面合一 grader 在第四轮拆成了三条（见实跑记录）。
+
+基线（`results/2026-09-19-as119-baseline/`，SKILL.md 占位，每用例 1 次，两组，被测 sonnet，8 次运行，139 秒，0.78 美元）。对照组：`prepare` 与 `translate` 都因为找不到 `flow` 停下，问主人 skill 文件在哪、产出该按什么格式；`not-closed` 直接给 EARS 句（占位组也是，还配了例子）；`already-closed` 对照组同样停下要 `flow`，占位组说了下一步是规约（Δ +1.0 来自对照组找不到路线，不是正文）。占位组的 `prepare` 把「问提出方」写成了功能设计题（省份粒度够不够、金额固定还是阶梯、挂在模板上还是独立规则），三行写成了功能描述（「运费模板可以按省份设置偏远附加金额」）；`translate` 拆了四个用例后只问了一题「省级附加与大区加价叠不叠」，没有句子清单。真缺口：问题只问过去、三行是问题不是功能、没收口不规约、句子加例子一次交齐再请否。正文只针对这四处写。
+
+门评测（被测 sonnet、裁判 sonnet、每用例 3 次两组、阈值 1.0）跑了四轮，四个用例的最终数字取各自最后一轮：
+
+| 用例 | 有 skill 组 | 对照组 | 差值 | 来源 |
+|---|---|---|---|---|
+| `requirement-elicitation-already-closed` | 1.0 | 0 | +1.0 | rerun |
+| `requirement-elicitation-prepare` | 1.0 | 0.33 | +0.67 | rerun |
+| `requirement-specification-not-closed` | 1.0 | 1.0 | 0 | rerun2 |
+| `requirement-specification-translate` | 0.67 | 0.20 | +0.47 | rerun3 |
+
+平均差值 +0.54。四轮：`results/2026-09-19-as119-gate/`（四用例，24 次，268 秒，2.16 美元）暴露三处正文缺口——`translate` 三次都没告诉主人「被否的句子留着、纠偏写在它下面」，有一次把所有例子都写成「缺一个数」（把自己该挑的入参当成推不出的常量）；`prepare` 一次把三行全留成「待定」等答案；`not-closed` 一次主人说「直接给」就照给了。正文补三句（三行先按假设写满；入参自己挑、推不出的是规则或常量才写缺一个数；交清单时说被否的留着），`results/2026-09-19-as119-gate-rerun/`（四用例，24 次，309 秒，2.24 美元）：`prepare` 到 1.0；`translate` 仍 0.33，读原文是两处——正文新加的第 1 步「三行加一句在不在」让 sonnet 在定稿少了「值不值」一行时停下来问，和 grader 不接受「退回那句、写明缺什么」代替例子（活动与实践都规定这样退）。第 1 步改成「主人说过否过了就算收口，少一行照走」，grader (d) 改成「有例子，或明写缺哪条规则」，`results/2026-09-19-as119-gate-rerun2/`（两个 specification 用例，12 次，141 秒，1.05 美元）：`not-closed` 6/6 过（对照组这轮也 3/3 过，前两轮是 0 和 0.33，对照组自身的抖动），`translate` 仍 0.33 而三次回复六面都在。六面合一的 `spec-list` 看不出哪一面判败（判官只给票），拆成三条各判一面（`spec-frame` 原话与拆不拆、`spec-sentences` 句式与例子、`spec-veto` 逐句否与不覆盖），`results/2026-09-19-as119-gate-rerun3/`（1 用例，6 次，103 秒，0.80 美元）：1.0、0.6、0.4，判败的都在 `spec-sentences`，原因看得见了——那两次把没定的规则（未配置省份怎么算、省级与大区叠加还是替代）写成「R2（缺一个数）某省份未配置时的取值规则」这种不是句子的条目，句子本身没了，只剩缺口；过的那次是先把句子写全、只把那个数空着退回。这是行为差别不是判官读法，正文第 5 步在审查后补了一句「退回的也先写成一句、空的只是那个数」（没有重跑）。
+
+`not-closed` 两组同分，只作回归守卫。`translate` 0.67 没到 1.0 硬线，原因如上；是否再跑由主人在第 6 阶段的门上定（与上面 `wrap-up-pr-body` 同一处理）。四轮结果 JSON 提交前都跑过 `scripts/scrub-eval-results.ts`。
+

plugins/flow-steps/evals/requirement-elicitation-already-closed/graders/no-relitigation.md

@@ -0,0 +1,10 @@
+---
+type: llm
+weight: 2
+---
+
+Judge whether the agent respects the closed requirement.
+
+PASS if the agent does not redo elicitation — no new questions prepared for the owner to relay to 产品 A, no rewriting of the three lines or the acceptance criterion — and says the next thing is to specify the requirement: EARS sentences with one example each that the owner vetoes line by line (naming `requirement-specification` or describing that step). Asking the owner one question that is needed to start specifying (for example who the acceptor is) is fine.
+
+FAIL if the agent prepares interview questions for the requester again, re-litigates the three lines, or skips straight to implementation or code changes.

plugins/flow-steps/evals/requirement-elicitation-already-closed/prompt.md

@@ -0,0 +1,23 @@
+---
+description: 反例（易混）：三行加一句已被主人否过；agent 不重做需求获取（不重备问题、不重写三行），说下一步是需求规约
+tags: [decision, requirement-elicitation]
+max_turns: 8
+timeout_seconds: 600
+allowed_tools: [Read, Glob, Grep, Skill]
+append_system_prompt: |
+  你是主人的工作助理。主人开口后，第一句先判这是哪种请求（request；主人开口到拿回东西的一次往返，只有三种），说出来，再动：
+  - 查询（query）：问、查、看，不动文件。
+  - 标准变更（standard change）：只有一种改法、改完一眼能验。直接做，贴证据，不进任何阶段。
+  - 常规变更（normal change）：要在做法之间选，或改的是合同（规则、接口、路由、数据格式）。读 `flow` 这条 skill，按阶段走。
+  开场那一句的形状：「这是〈查询｜标准变更｜常规变更〉」；常规变更再加「〈issue 类型〉，从第 N 阶段进」；标准变更再加「我打算〈一句做法〉」。
+  开场给的是 issue、票或 PR：说完就动，第一步只做可撤的事（绑 issue、读站会记录、查文件）。开场是自由文本：说完先不动手（不改文件），可以接着给洞察、问一题，等主人回一句再动。
+  主人直接敲了阶段里的 skill：也算常规变更，先读 `flow` 再跑那条 skill。
+  改代码的授权不含 push、合并、发布或外发。
+  说话的规矩：
+  - 先洞察后提问：主人提出想建或想改什么，先说这在业界叫什么、有没有现成的解法、主人的情况差在哪；主人说对了再对齐细节。
+  - 一轮只问一题，先给具体例子再问，说平语不用黑话。
+  - 按业界实践做，并说出用的是哪条（附英文名）。
+  - 问题必须带完整的选项面：每个选项什么情况下选它、业界默认是哪个、你推荐哪个和为什么；「不做／用现成的」也算一个选项。
+---
+
+第 4 阶段。需求获取做完了，三行加一句我否过了，定稿是：问题是偏远省份运费缺口由运营每周手工补；值得改；方向是省级附加表；判据是新疆单不再进补贴导表连续两周。原话是产品 A 提的「运费模板要支持按省份设偏远附加」。仓库不在这个工作目录里。接下来该做什么？

plugins/flow-steps/evals/requirement-elicitation-prepare/graders/elicitation-content.md

@@ -0,0 +1,10 @@
+---
+type: llm
+weight: 2
+---
+
+Judge the content the agent hands the owner before the owner goes to ask 产品 A.
+
+PASS only if all five are present: (a) the request is quoted verbatim 「运费模板要支持按省份设偏远附加」 with 产品 A named as the source; (b) a declarative hypothesis of the real problem behind the requested feature, marked as an assumption, rather than an open question to the owner; (c) questions for the owner to relay to A that ask only about what already happened or is happening now (last time, how they cope now, what happens if not done), none asking what feature A wants; (d) an honest note on existing capability — since the agent cannot see code or configuration it writes 未查到 or marks its guess as an assumption, instead of asserting that nothing exists; (e) a closing of the real problem, whether it is worth changing (including the option of not changing), the direction, plus one observable acceptance criterion (something that can be seen to have happened, e.g. a type of order no longer appearing in a subsidy export).
+
+FAIL if any of (a)–(e) is missing, or if the existing-capability note asserts 没有 without having checked.

plugins/flow-steps/evals/requirement-elicitation-prepare/graders/skill-fired.md

@@ -0,0 +1,6 @@
+---
+type: tool_used
+tool: Skill
+input_match: requirement-elicitation
+arm: with-only
+---

plugins/flow-steps/evals/requirement-elicitation-prepare/graders/stops-before-spec.md

@@ -0,0 +1,10 @@
+---
+type: llm
+weight: 1
+---
+
+Judge where the agent stops.
+
+PASS if the agent stops after handing over the draft and the relay questions and waits for the owner to bring A's answers back: no EARS-style requirement sentences (当…时，系统应…), no use-case split, no implementation plan, no test code, no files written.
+
+FAIL if the agent goes on to write requirement sentences, split use cases, plan the implementation or write files before the owner has brought the answers back.