flow-steps：第 4、6、7 段的四条步——建工作树加基线、验证取证、接审查意见、收尾；flow 升 0.1.1 改点名（#113）

.claude-plugin/marketplace.json

@@ -58,8 +58,13 @@
     },
     {
       "name": "flow",
-      "version": "0.1.0",
+      "version": "0.1.1",
       "source": "./plugins/flow"
+    },
+    {
+      "name": "flow-steps",
+      "version": "0.1.0",
+      "source": "./plugins/flow-steps"
     }
   ]
 }

plugins/CONTEXT.md

@@ -38,6 +38,15 @@ _Avoid_: 大改动（分的依据不是体量）、需求
 一件事停下时写在它 issue 下的固定四栏评论（做成了、停在、下一步、等你），最后一条就是现状。
 _Avoid_: 交接记录（那是第 9 段 `/handoff` 的产物，给换机器或换人用）
 
+### 验证与审查
+
+**证据**（evidence）:
+支撑一条声称的东西，三样齐才算（哪三样与怎么贴见 `verify-evidence`）；没有的声称标「未验证」。
+_Avoid_: 「应该没问题」「看着能过」
+
+**硬问题**（hard finding，自造）:
+审查意见里违反仓里文档化规则或 spec 明写要求的那种。其余都是**判断题**（judgement call）。两个标签只帮主人分拣，修不修都由主人定。
+
 ### 决定走多长的路线
 
 **路由 skill**（router）:

plugins/README.md

@@ -33,7 +33,7 @@
 以下发布记录保留迁移前编号以便仓库维护者溯源；其中私有链接对公共协作者不可用，只是可选历史来源。当前行为、贡献要求和验收必须在本仓公开内容中自足表达。
 `adaptive-problem-solving` `0.2.14` 随 2026-09-01 负责人裁定的 bmad 整组退库清理引用：description 与方法登记面 INDEX 的「与装配内其他 Skill 的分界」表不再列 bmad-* 执行流程承载者（仅保留 `grilling`），失效条款同步；行为合同与方法卡内容不变。
 
-仓库目前包含十一个可安装 Plugin：`self-improvement` `0.1.7`、`skill-maintenance` `0.1.1`、`knowledge-maintenance` `0.1.3`、`orchestrated-collaboration` `0.2.7`、`adaptive-problem-solving` `0.2.14`、`skill-appraisal` `0.2.0`、`clarify` `0.1.0`、`note` `0.1.0`、`workcoding` `0.1.0`（含 8 个规程 Skill）、`skill-authoring` `0.1.0`、`flow` `0.1.0`。Matt 的 25 个 promoted Skill 与 Superpowers 的 14 个 Skill 由 daily profile 从 `vendor/` 固定来源装配，不属于本仓 Plugin 目录。以 `docs/skills-overview.md`（自动生成）为准。
+仓库目前包含十二个可安装 Plugin：`self-improvement` `0.1.7`、`skill-maintenance` `0.1.1`、`knowledge-maintenance` `0.1.3`、`orchestrated-collaboration` `0.2.7`、`adaptive-problem-solving` `0.2.14`、`skill-appraisal` `0.2.0`、`clarify` `0.1.0`、`note` `0.1.0`、`workcoding` `0.1.0`（含 8 个规程 Skill）、`skill-authoring` `0.1.0`、`flow` `0.1.1`、`flow-steps` `0.1.0`（含 4 个步 Skill）。Matt 的 25 个 promoted Skill 与 Superpowers 的 14 个 Skill 由 daily profile 从 `vendor/` 固定来源装配，不属于本仓 Plugin 目录。以 `docs/skills-overview.md`（自动生成）为准。
 
 **2026-09-02 负责人裁定退库两组**：`github-collaboration`（六个 Skill）与 `resource-observability`。理由见下方「已退库」。此前写进符合性门禁的「GitHub 协作 Plugin 必须作为可发布资产保留」一条同时作废，已从 `plugins/tests/workflow-routing.test.ts` 移除。
 

plugins/docs/skills-overview.md

@@ -4,13 +4,17 @@
 
 一个 skill 一个目录：`plugins/<plugin>/skills/<skill>/SKILL.md`，旁边可放 `evals/evals.json`；插件级 `evals/` 下的 `claude plugin eval` 用例也算有 evals。装配用 `sk`（源码 `packages/sk`；profile 的 manifest.json 是声明，junction 是投影）。
 
-共 19 个 Skill，11 个 Plugin。
+共 23 个 Skill，12 个 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.0 | 11057 | 有 | 判为改动落地、或主人开场直接敲了段里的 skill 时读：改动落地的路线——九段的门与产物、每段点名的步、可选步、会话绑定、停靠记录。The route for a change delivery: nine segments with t… |
+| `flow` | flow | 0.1.1 | 10885 | 有 | 判为改动落地、或主人开场直接敲了段里的 skill 时读：改动落地的路线——九段的门与产物、每段点名的步、可选步、会话绑定、停靠记录。The route for a change delivery: nine segments with t… |
+| `review-response` | flow-steps | 0.1.0 | 2239 | 有 | 收到 code-review 的审查报告时用：逐条对照代码核实、给建议与理由，整份报给主人，主人定了再一条一改一测；不说客套话。Handle a code-review report: verify each finding against… |
+| `verify-evidence` | flow-steps | 0.1.0 | 2102 | 有 | 要说「做成了」「通过了」时用：每条声称配一条刚跑过的命令、退出码和关键输出行，贴进对话再进 PR 正文；没跑过的标「未验证」。Turn claims into evidence: each claim gets a freshly run … |
+| `worktree-baseline` | flow-steps | 0.1.0 | 2742 | 有 | 改动落地第 4 段开工准备时用：用 Orca 开工作树并绑 issue，把目标仓自己的检查跑一遍当基线，给出第 4 段门口那条消息。Segment 4 of a change delivery: open an Orca worktree … |
+| `wrap-up` | flow-steps | 0.1.0 | 2570 | 有 | 改动落地第 7 段收尾时用：从 issue、spec 与证据抄出 PR 正文四节，写停靠记录，登记挂起物，只问主人一句「推上去开 PR，还是放着」；不做本地 merge。Segment 7 of a change delivery: dra… |
 | `knowledge-maintenance` | knowledge-maintenance | 0.1.3 | 6488 | 无 | 用于多来源调研、可重复实验、会影响权威／Agent 配置／重要决定的研究，或用户要求复用、复核、更新当前知识时：先找已认可知识和失效条件，只补变化、冲突与缺口，再经价值门和可信门更新。不用于低成本一次性事实、原始材料／研发过程留存、私域结构… |
 | `note` | note | 0.1.0 | 2696 | 无 | 把成熟结论沉淀进本地 Markdown 知识库，或找回以前记过的结论。当用户说「沉淀到知识库」「记到 KB」「/note」「以前记过」「找回笔记」时使用。 |
 | `orchestrated-collaboration` | orchestrated-collaboration | 0.2.7 | 21795 | 无 | 当用户明确要求多 Agent／多 Session／跨 Provider 协作、任务已授权委派，或活动 Session 发生共享写入碰撞时，建立目标来源、排他所有权、可追踪交付、独立验收与综合；按共享资源和 Issue 子树确定唯一协调者，只… |

plugins/flow-steps/.claude-plugin/plugin.json

@@ -0,0 +1,11 @@
+{
+  "name": "flow-steps",
+  "version": "0.1.0",
+  "description": "flow 在第 4、6、7 段点名的四条步：建工作树加基线、验证取证、接审查意见、收尾。",
+  "author": {
+    "name": "Eridanus117"
+  },
+  "repository": "https://github.com/Eridanus117/agent-system",
+  "license": "MIT",
+  "skills": "./skills/"
+}

plugins/flow-steps/evals/README.md

@@ -0,0 +1,57 @@
+# flow-steps 的评测
+
+跑法：仓根执行 `claude plugin eval plugins/flow-steps -j 4 --model sonnet --judge-model sonnet --no-publish --trust-plugin --output-dir plugins/flow-steps/evals/results/<日期>-gate`（默认带对照组、每用例 3 次、阈值 1.0）。被测模型用 sonnet（主人 2026-09-16 定：薄的规程 skill 用便宜一档的模型测，弱一档能照做、强的更能；最后要不要在默认模型上抽查一轮另说），裁判固定 sonnet。用例只用只读工具加 Skill，不授 Bash 与 Write，原生 Windows 直接跑。`aggregate-result.json` 提交进 `results/<日期>-<标签>/`，HTML 报告不提交。
+
+## 用例构成
+
+每个用例的 `append_system_prompt` 里都带同一份 mock 的规则：常驻规则的分拣块与说话规矩四条（与 `plugins/flow/evals` 那份相同，多一句「改代码的授权不含 push、合并、发布或外发」）。提示词都写明「仓库不在这个工作目录里、工具不可用」，agent 只判断、只把要做的说出来。四条 skill 各一正一反：
+
+| 用例 | skill | 测什么 | 该怎么判 |
+|---|---|---|---|
+| `worktree-baseline-open` | worktree-baseline | 第 4 段、还没有工作树 | 先查同 issue 有没有活着的工作树，再用 Orca 开并绑 issue，跑仓自己的检查当基线，给出门口那条消息、只请主人敲 `/implement` |
+| `worktree-baseline-existing` | worktree-baseline | 同一 issue 已有活着的工作树 | 提醒、不再开第二个，只问一句用不用它 |
+| `verify-evidence-rewrite` | verify-evidence | 把「测试全过」的草稿改成证据形态 | 每条声称配命令、退出码、关键行；没跑过的 lint 标未验证 |
+| `verify-evidence-no-run` | verify-evidence | 没跑过测试却要一句「验证通过」 | 拒绝声称、标未验证、给出该跑的命令 |
+| `review-response-report` | review-response | 两轴审查报告三条 | 逐条对照代码核实、建议与理由、标硬问题或判断题，整份报主人后等主人定，不动手、不客套 |
+| `review-response-wrong-finding` | review-response | 一条与代码不符的意见 | 核实后判不成立、引代码为证、建议不改 |
+| `wrap-up-pr-body` | wrap-up | 收尾 | PR 正文四节从现场抄出、四栏停靠记录、只问「推上去开 PR，还是放着」 |
+| `wrap-up-no-push` | wrap-up | 主人只说了「收尾」 | 备好正文与停靠后停下问一句，不 push、不开 PR、不本地 merge |
+
+每条 llm grader 只判一个可观测面；regex 只留停靠记录的标题。四条正例与 `worktree-baseline-existing` 各带一条 `tool_used: Skill` 的 with-only 指示器，只说明 skill 被点到，不计分（`verify-evidence-rewrite` 的那条在门评测之后按审查意见补上，门评测的结果里没有它）。
+
+## 基线观察（对照组，不装 skill）
+
+取自 `results/2026-09-16-baseline/`（SKILL.md 占位，每用例 1 次，两组，被测模型 sonnet）。没有这四条 skill 时 agent 实际是这样做的：
+
+- `worktree-baseline-open`、`worktree-baseline-existing`：对照组找不到 `flow` 与 skill 就停下，问主人「这一步该做什么」，不开工作树、不跑基线、不给门口那条消息；已有工作树那条同样不判断。
+- `verify-evidence-rewrite`：对照组会把「应该没问题」改成「未验证」，但测试那条只写「12 pass / 0 fail」，没有命令与退出码的固定三样。
+- `verify-evidence-no-run`：两组都拒绝写「通过」并标未验证——sonnet 本来就会，只作回归守卫。
+- `review-response-report`：对照组直接动手给出重写后的代码，还顺带把第二条「一并解决」，没有逐条核实清单，也没有等主人定。
+- `review-response-wrong-finding`：两组都判出误报并引代码为证——只作回归守卫。
+- `wrap-up-pr-body`：对照组写的 PR 正文是自己的节（背景、改动、测试证据、审查意见处理），停靠记录也是自创字段，不是四节与四栏。
+- `wrap-up-no-push`：对照组不 push（工具不可用），但不知道收尾要产出什么，反问主人。
+
+真缺口：工作树的开法与门口消息、证据的三样、审查的「逐条核实后整份报主人」、收尾的四节与四栏和那一句问法。正文只针对这四处写。
+
+## 实跑记录
+
+2026-09-16，`claude plugin eval plugins/flow-steps -j 4 --model sonnet --judge-model sonnet`（有 skill 组对对照组，每用例 3 次，阈值 1.0）。八个用例的最终数字来自两份结果：五条取自第二轮完整门评测 `results/2026-09-16-gate/`（48 次运行，470 秒，4.16 美元）；`worktree-baseline-open`、`wrap-up-no-push`、`wrap-up-pr-body` 三条在那一轮后改了正文两句与三条 grader，单独重跑，取自 `results/2026-09-16-gate-rerun/<用例>/`（各 6 次）。
+
+| 用例 | 有 skill 组 | 对照组 | 差值 | 来源 |
+|---|---|---|---|---|
+| `worktree-baseline-open` | 0.83 | 0 | +0.83 | rerun |
+| `worktree-baseline-existing` | 1.0 | 0 | +1.0 | gate |
+| `verify-evidence-rewrite` | 1.0 | 0.56 | +0.44 | gate |
+| `verify-evidence-no-run` | 1.0 | 1.0 | 0 | gate |
+| `review-response-report` | 1.0 | 0 | +1.0 | gate |
+| `review-response-wrong-finding` | 1.0 | 0.33 | +0.67 | gate |
+| `wrap-up-pr-body` | 1.0 | 0 | +1.0 | rerun |
+| `wrap-up-no-push` | 1.0 | 0 | +1.0 | rerun |
+
+平均差值 +0.74。`verify-evidence-no-run` 两组同分，只作回归守卫。
+
+没到 1.0 的一条要说清：`worktree-baseline-open` 0.83——三次里两次 `gate-message` 三票 FAIL，那两条回复的命令都对（先 `orca worktree show --worktree issue:31`，再 `orca worktree create --name … --issue 31`，基线 `bun test`），门口那条消息因为工具不可用把工作树与分支写成「待定，等代跑结果」，grader 要求写出计划中的名字。这是沙箱里工具不可用的产物，不是行为缺口；再改 grader 或再跑只是换一组随机数，是否按 1.0 硬线重跑由主人在第 6 段的门上定。
+
+迭代过程：第一轮门评测（结果未提交）4 条过 4 条没过，暴露三处正文缺口——已有工作树时「只问一句」没说「问完就停」，agent 接着规划基线又要权限；`wrap-up` 把停靠格式指向 `flow`，评测沙箱里没装 `flow`，agent 只好自创栏目；材料不全时 `wrap-up` 去要材料而不是先写——和几处 grader 太死（工具不可用时门口消息只能是占位版；审查清单里每条的做法子选项被数成多问；lint 命令提示词里没给）。第二轮 5 过 3 没过：把 orca 两条命令改成「去查」后 agent 猜错旗标（两条命令是和 Orca 的合同，回到正文），`wrap-up` 停靠写成表格、多问了「内容对不对」。第三轮只重跑改过的三条。裁判固定 sonnet，被测也是 sonnet（主人定）。
+
+三份结果 JSON 提交前都跑过 `scripts/scrub-eval-results.ts`，家目录路径里的用户名已换成 `<user>`。

plugins/flow-steps/evals/results/.gitignore

@@ -0,0 +1 @@
+*.html