@heihei0299/matt-skills 2.1.2 → 2.1.5

package/.agents/skills/grill-to-spec/SKILL.md

@@ -15,29 +15,29 @@ disable-model-invocation: true
 调用 [`grill-with-docs`](.agents/skills/grill-with-docs/SKILL.md)，由 `grilling` 与 `domain-modeling` 完成采访、术语和设计决策。
 
 - glossary 按上游规则 inline 更新；
-- 只有确需 ADR 时才创建 ADR 草稿；
-- ADR 必须先展示完整草稿，用户明确确认后才写入，未确认不得落盘。
+- 只有确需 ADR 时才创建 ADR；
+- 决策共识形成后直接写入 ADR，不向用户展示 ADR 正文，不增加单独确认轮次。
 
-出口：用户确认共识已达成，且所有 ADR 草稿都已获得单独确认或明确不写入。
+出口：用户确认共识已达成，且已确定的 glossary/ADR 已写入。
 
 ### ② 发布 spec
 
 将已确认的共识交给 [`to-spec`](.agents/skills/to-spec/SKILL.md)，完成代码库理解、seam 提案和 spec 组装。
 
-- 将 seam 提案并入最终 spec 草稿，不单独制造一次重复确认；
-- 发布前展示完整 spec 草稿，用户一次明确确认后才写入 `.scratch/<feature-slug>/spec.md`；
+- 将 seam 提案作为共识的一部分确认，不展示由此生成的文档正文；
+- 共识（含 seam）达成后，直接写入/发布 spec 与 issue，不设置发布前确认；
 - 发布时使用 `ready-for-agent`，格式细则只读取 [`references/rules.md`](references/rules.md)。
 
-出口：spec 已发布，路径、状态和未纳入范围已报告。
+出口：spec/issue 已写入或发布，只报告路径或标识、状态和未纳入范围。
 
 ## 回合连续性
 
-本 skill 是 Long-Horizon Skill。阶段 ① 达到出口后立即进入阶段 ②；正常的阶段切换、进度汇报或“接下来生成 spec”不是回合终点。仅在必须获得用户确认的 ADR/spec 草稿、明确外部阻塞、用户主动停止或整个 skill 出口时暂停。确认完成后在同一任务链继续推进到下一可验证出口，不要求用户额外回复“继续”。
+本 skill 是 Long-Horizon Skill。阶段 ① 达到出口后立即进入阶段 ②；正常的阶段切换、进度汇报或“接下来生成 spec”不是回合终点。仅在必须获得用户确认的设计问题、明确外部阻塞、用户主动停止或整个 skill 出口时暂停。文档写入/发布不另起确认回合，不要求用户额外回复“继续”。
 
 ## 本 skill 独有门禁
 
-- ADR：草稿 → 用户确认 → 落盘，任何情况不例外；
-- spec：共识与 seam 合并为一个最终草稿，只设置一次发布前确认；
+- ADR：决策共识 → 直接落盘，不展示正文、不设置独立确认；
+- spec/issue：共识与 seam 达成后直接写入/发布，不展示正文、不设置发布前确认；
 - 全程不写代码、不修改测试、不执行实现。
 
 ## 异常

package/.agents/skills/grill-to-spec/references/rules.md

@@ -11,16 +11,21 @@
 ## ADR 增量规则
 
 - 只有同时满足“难逆转 / 无上下文费解 / 存在真实权衡”时才提议 ADR。
-- ADR 草稿必须完整展示并获得用户明确确认后才落盘；这是本 skill 的独有硬门禁。
+- 决策共识形成后直接落盘；不向用户展示 ADR 正文，不增加独立确认轮次。
 - 不把 ADR 当 glossary 一样静默 inline 更新。
 
 ## Spec 增量规则
 
 - Spec 的结构与字段全部委托 `to-spec`，本文件不维护第二份模板。
-- seam 提案并入最终 spec 草稿，不再制造独立的一次确认。
-- 发布前只做一次最终 spec 明确确认；确认后写入并标记 `ready-for-agent`。
+- seam 提案作为共识的一部分确认，不展示由此生成的 spec 正文。
+- 共识（含 seam）达成后直接写入并标记 `ready-for-agent`，不设置发布前确认。
 - 全文沿用已经确认的 glossary 词汇，并尊重所触区域既有 ADR。
 
+## Issue 增量规则
+
+- 按已配置的 issue tracker 直接发布 issue；issue 正文不在对话中展示。
+- 发布后只报告 issue 标识、状态和未纳入范围，不复制正文。
+
 ## 反模式
 
 - 不复制 `to-spec` 的章节清单、User Story 模板或 Implementation Decisions 细则。

package/.agents/skills/implement-review-loop/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: implement-review-loop
+description: "Implement changes with one executor model and one independent reviewer model, iterating on only the changed surface until no actionable issues remain."
+disable-model-invocation: true
+---
+
+Use two distinct roles:
+
+- **Executor**: implements the requested change, fixes findings, and runs the smallest relevant verification.
+- **Reviewer**: independently reviews the latest diff and relevant verification results. It does not perform the implementation.
+
+Workflow:
+
+```text
+Executor implements
+→ targeted verification
+→ Reviewer reviews latest diff
+→ if findings exist: Executor fixes only those findings
+→ targeted re-verification
+→ Reviewer re-reviews changed parts and unresolved findings
+→ repeat until Reviewer reports no actionable issues
+```
+
+Rules:
+
+- Keep implementation, testing, and review scoped to the current change and directly affected paths.
+- Prefer targeted tests: changed test files, affected modules, regression cases, or the original reproduction path.
+- Do not rerun equivalent checks after every small edit.
+- Reviewer should inspect the latest diff first, then only enough surrounding code to validate behavior and integration.
+- On subsequent rounds, review the new changes plus unresolved findings; do not restart a whole-project review.
+- Expand test or review scope only when the change crosses modules, modifies shared/public contracts or core infrastructure, targeted evidence is insufficient, final release/merge validation requires it, or the user explicitly requests it.
+- Findings must be concrete and actionable. Separate blockers from optional improvements.
+- Stop the loop when the Reviewer has no actionable findings and targeted verification is green.
+- Do not let the Reviewer silently become the Executor; preserve role independence throughout the loop.

package/.agents/skills/implement-review-loop/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Implement Review Loop"
+  short_description: "Implement with an independent review loop"
+policy:
+  allow_implicit_invocation: false

package/.agents/skills/tdd-implement/SKILL.md

@@ -16,7 +16,7 @@ disable-model-invocation: true
 - **多 issue**：`.scratch/<feature>/issues/` 下存在多个 `Type: task` 文件时，先读取 [orchestration.md](references/orchestration.md)，按 `Blocked by` 构建 DAG、Kahn 分层，再由主代理按层串行完成各 issue。
 - `Type: research`、`prototype`、`grilling` 分流到对应技能，不进入本技能。
 
-多 issue 的 A0-A5 是编排控制活动，不是额外的产品交付阶段：依赖图、分层、串行调度、层收敛、全量收敛和回退/冲突处理的详规只在 [orchestration.md](references/orchestration.md) 中维护。
+多 issue 的 A0-A5 是编排控制活动，不是额外的产品交付阶段：依赖图、分层、串行调度、层收敛、最终收敛和回退/冲突处理的详规只在 [orchestration.md](references/orchestration.md) 中维护。
 
 ## 三阶段 Steps
 
@@ -40,7 +40,7 @@ Finalize 出口：commit 已创建、Acceptance Criteria 全部通过，Tracker
 - 一个 seam 是公共可观察边界；一个 Behavior 是一个红-绿 cycle；一个 seam 可以包含多个 Behaviors。Seam/Behavior 的细节和 Todo 粒度只在进入 Step ② 时读取 [red-green.md](references/red-green.md)。
 - 每个 issue 只在 Verify 的最终 diff 稳定后调用一次 `code-review`；审查维度、reviewer 数量、提示词和输出格式全部由 `code-review` 自己定义，`tdd-implement` 不复制这些规则。`code-review` 未完成或存在 blocking finding 时 issue 不得收敛；A3 层收敛不再次调用 review。
 - 当前 issue 的范围、Acceptance Criteria、Out of Scope、测试/typecheck/build/真实运行证据和最终 commit 必须可追溯。Seam 或专项测试绿色不代表 issue 完成；三个阶段出口与 Finalize 全部满足后才可标记 `resolved`。
-- 多 issue 模式中，每个 issue 只提交一个独立 commit；issue 影响范围测试在 Step ③ 执行，全仓测试由 orchestration 的 A4 在全部 issue 完成后执行一次。
+- 多 issue 模式中，每个 issue 只提交一个独立 commit；issue 影响范围测试在 Step ③ 执行，A4 只做最终编排收敛，不额外扩大测试范围。
 
 ## 引用
 

package/.agents/skills/tdd-implement/references/orchestration.md

@@ -10,7 +10,7 @@
 - [A1：Kahn 拓扑分层](#a1kahn-拓扑分层)
 - [A2：分层串行调度](#a2分层串行调度)
 - [A3：层收敛](#a3层收敛)
-- [A4：全量收敛](#a4全量收敛)
+- [A4：最终收敛](#a4最终收敛)
 - [A5：回退与冲突处理](#a5回退与冲突处理)
 
 ---
@@ -80,7 +80,7 @@ for each layer Li in L1..Ln:
 全部层完成后进入 A4
 ```
 
-每个 issue 的 Verify 只运行当前 issue 影响范围内的完整测试；全仓测试不在每个 issue 中重复执行。当前 issue 的最终 diff 稳定后只调用一次 `code-review`；review 的内部方法完全由 `code-review` 定义。修复 blocking finding 后执行受影响验证和 finding delta recheck，不重复调用完整 `code-review`。
+每个 issue 的 Verify 只运行当前 issue 影响范围内的测试；编排层不额外扩大测试范围。当前 issue 的最终 diff 稳定后只调用一次 `code-review`；review 的内部方法完全由 `code-review` 定义。修复 blocking finding 后执行受影响验证和 finding delta recheck，不重复调用完整 `code-review`。
 
 主代理在层内和层间连续调度：一个 issue 的 Finalize 出口满足后，立即取下一个 issue，直到全部层完成或发生明确外部阻塞。进度输出并入执行序列，不在正常切换点等待用户“继续”。
 
@@ -129,11 +129,11 @@ A3 只做编排收敛，不再次调用 `code-review`；正式 review 已在每
 
 任一项失败，定位到该层失败 issue，按 A5 回退并重做该 issue 的受影响阶段或 Behavior，然后重新收敛本层。
 
-## A4：全量收敛
+## A4：最终收敛
 
 全部层完成且各层收敛通过后：
 
-1. 按 A0 的验证矩阵运行一次仓库全量测试；这是多 issue 流程唯一的全量回归点。只有修复全量失败后才允许必要重跑；
+1. 汇总并确认各 issue 的相关测试、typecheck/build、真实运行和 review 证据仍对应最终状态；若后续改动使证据失效，只重新验证受影响范围；
 2. 执行 `git merge-base --is-ancestor $BASE_HEAD HEAD`；失败时按 A5 恢复后重验；
 3. 执行 `git status`，确认无 `[DEBUG-...]`、一次性脚本或未跟踪临时文件；
 4. 汇总各 issue 回执卡片的 commit、Behaviors、Acceptance Criteria、测试、真实运行和文档对齐结果；汇总只在对话输出，不另写汇总文件。
@@ -141,7 +141,7 @@ A3 只做编排收敛，不再次调用 `code-review`；正式 review 已在每
 ### A4 出口
 
 - 全部 issue 已有独立 commit、实施总结和 `progress.md` 派生记录；
-- 全量测试通过；
+- 各 issue 的受影响验证证据仍对应最终状态；
 - 工作区卫生、历史校验和真实运行要求均满足；
 - `progress.md` 与 `issues/*.md` 一致，不一致时以 issue 真相源为准并修复派生视图。
 
@@ -156,7 +156,7 @@ A5 负责所有编排级失败，不把失败静默吞掉，也不把不相关
 | Red-Green 的有效 Red、实现、typecheck 或 targeted test 失败 | 回到该 issue 的 Red-Green，修复当前 Behavior 并重新验证 |
 | Verify 的测试、build、真实运行或 review blocking finding 失败 | 回到受影响 issue 的对应阶段；修复后只做受影响检查和 delta review |
 | Finalize 的必要 docs、commit 或 Tracker 失败 | 保持 issue 未 resolved，修复 Finalize 问题后重新验证 |
-| 全量测试失败 | 定位到引入失败的 issue，按上述路径修复；只在修复后重跑必要范围和全量测试 |
+| A4 收敛发现验证证据失效 | 定位到受影响 issue，按上述路径修复；只重新验证受影响范围 |
 | `Blocked by` 依赖未完成 | 后续 issue 保持 `blocked`，前置 issue resolved 后自动解阻 |
 | 多 issue 预期修改同一文件 | 记录冲突，按编号串行；无法安全归属时暂停并请求用户决定 |
 | Git 历史祖先校验失败 | 立即停止写入，使用 `git reflog` 找回 `BASE_HEAD` 之后的提交，校验通过后继续 |

package/.agents/skills/tdd-implement/references/stages.md

@@ -1,6 +1,6 @@
 # 三阶段详细定义 + Finalize
 
-单 `spec` / 单 `task` 与多 `task` 共用下列三个交付阶段；Verify 通过后执行 Finalize 收尾，Finalize 不计入阶段。多 issue 的依赖图、Kahn 分层、层收敛、全量收敛和回退/冲突处理见 [orchestration.md](orchestration.md)。TDD 语义以 [tdd 技能](.agents/skills/tdd/SKILL.md) 为唯一事实源，不在此重写。
+单 `spec` / 单 `task` 与多 `task` 共用下列三个交付阶段；Verify 通过后执行 Finalize 收尾，Finalize 不计入阶段。多 issue 的依赖图、Kahn 分层、层收敛、最终收敛和回退/冲突处理见 [orchestration.md](orchestration.md)。TDD 语义以 [tdd 技能](.agents/skills/tdd/SKILL.md) 为唯一事实源，不在此重写。
 
 ## 目录
 
@@ -61,7 +61,7 @@ Seam 或专项测试绿色不等于 issue 完成；只有三个阶段与 Finaliz
    - `code-review` 可用性；
    - 可用的 browser 或 Playwright 路径；
    - ticket 要求的真实运行验证方式。
-6. 建立一次验证矩阵，列出 targeted tests、typecheck、全量测试、必要 build、smoke/package check 和真实运行验证，并记录各项的触发条件，后续只复用这份矩阵。
+6. 建立一次验证矩阵，列出 targeted tests、typecheck、必要 build、smoke/package check 和真实运行验证，并记录各项的触发条件，后续只复用这份矩阵。
 7. 识别公共测试边界和 Behaviors。一个 Seam 是一个公共可观察边界；一个 Behavior 是一个红-绿 cycle；一个 Seam 可以包含多个 Behaviors。每个 Behavior 明确输入、可观察输出、对应 Acceptance Criterion 和验证层级。
 8. spec 已确认且未变化的 Seam 直接复用；只有出现需求歧义、验收缺口、范围变化、破坏性操作或互斥方案时才请求用户确认。
 
@@ -142,8 +142,7 @@ Seam 或专项测试绿色不等于 issue 完成；只有三个阶段与 Finaliz
 
 ### 测试与真实运行验证
 
-- 多 issue 模式只运行当前 issue 影响范围内的完整测试；不在每个 issue 重复运行全仓测试。全部 issues 完成后由 orchestration A4 运行一次全仓测试。
-- 单 issue 或单 spec 模式运行仓库完整测试。按照 Contract 的验证矩阵执行，不同时运行等价命令。
+- 单 issue / 单 spec 与多 issue 均只运行当前 issue 影响范围内的测试，按照 Contract 的验证矩阵执行，不同时运行等价命令；不因进入 Verify 自动扩大测试范围。
 - ticket 要求真实运行时，优先使用专用 browser 工具，其次使用项目已有 Playwright；HTTP/CLI 只能补充 API 验证，不能替代 WebUI 验证。
 - 真实进程验证使用隔离配置和临时端口，保存 PID，记录实际请求结果或页面可见结果，结束时清理进程和临时目录。
 
@@ -252,4 +251,4 @@ Progress: pending | in_progress | done | blocked
 | ③ Verify | 测试、build、真实运行或 review finding 失败 | → ② 修复 Behavior；需求偏差 → ① |
 | Finalize | 必要 docs 未同步、commit 失败或 Tracker 信息不完整 | → ①/③ 修复对应问题；仍在 Finalize 完成前解决 |
 
-多 issue 的层收敛、全量失败、依赖冲突和跨 issue 修改冲突按 [orchestration.md](orchestration.md) A5 回退，不跨 issue 无记录改动。
+多 issue 的层收敛、最终收敛、依赖冲突和跨 issue 修改冲突按 [orchestration.md](orchestration.md) A5 回退，不跨 issue 无记录改动。

package/.agents/skills/tdd-implement/references/verify.md

@@ -8,7 +8,7 @@
 
 ## 规则
 
-- 单 issue / 单 spec：按 Contract 验证矩阵运行完整相关测试；多 issue：只跑当前 issue 影响范围，全仓测试留给 orchestration A4。
+- 单 issue / 单 spec 与多 issue 均按 Contract 验证矩阵运行当前 issue 影响范围测试；不因进入 Verify 自动扩大测试范围。
 - ticket 要求真实运行时，优先专用 browser，其次项目已有 Playwright；HTTP/CLI 不能替代 WebUI 可见验证。
 - 临时进程必须使用隔离配置/端口，记录 PID 与实际结果，结束后清理。
 - 当前 issue 的最终 diff 稳定后，调用一次 [code-review](.agents/skills/code-review/SKILL.md)。`tdd-implement` 只规定调用时机；审查维度、reviewer 数量、提示词、上下文与输出格式以 `code-review` 为唯一事实源。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@heihei0299/matt-skills",
-  "version": "2.1.2",
+  "version": "2.1.5",
   "description": "Agent skills + 项目配置模板：一条命令初始化 opencode / pi-agent 项目（含 mattpocock/skills 上游技能）",
   "type": "module",
   "bin": {

package/template/.agents/skills/grill-to-spec/SKILL.md

@@ -15,29 +15,29 @@ disable-model-invocation: true
 调用 [`grill-with-docs`](.agents/skills/grill-with-docs/SKILL.md)，由 `grilling` 与 `domain-modeling` 完成采访、术语和设计决策。
 
 - glossary 按上游规则 inline 更新；
-- 只有确需 ADR 时才创建 ADR 草稿；
-- ADR 必须先展示完整草稿，用户明确确认后才写入，未确认不得落盘。
+- 只有确需 ADR 时才创建 ADR；
+- 决策共识形成后直接写入 ADR，不向用户展示 ADR 正文，不增加单独确认轮次。
 
-出口：用户确认共识已达成，且所有 ADR 草稿都已获得单独确认或明确不写入。
+出口：用户确认共识已达成，且已确定的 glossary/ADR 已写入。
 
 ### ② 发布 spec
 
 将已确认的共识交给 [`to-spec`](.agents/skills/to-spec/SKILL.md)，完成代码库理解、seam 提案和 spec 组装。
 
-- 将 seam 提案并入最终 spec 草稿，不单独制造一次重复确认；
-- 发布前展示完整 spec 草稿，用户一次明确确认后才写入 `.scratch/<feature-slug>/spec.md`；
+- 将 seam 提案作为共识的一部分确认，不展示由此生成的文档正文；
+- 共识（含 seam）达成后，直接写入/发布 spec 与 issue，不设置发布前确认；
 - 发布时使用 `ready-for-agent`，格式细则只读取 [`references/rules.md`](references/rules.md)。
 
-出口：spec 已发布，路径、状态和未纳入范围已报告。
+出口：spec/issue 已写入或发布，只报告路径或标识、状态和未纳入范围。
 
 ## 回合连续性
 
-本 skill 是 Long-Horizon Skill。阶段 ① 达到出口后立即进入阶段 ②；正常的阶段切换、进度汇报或“接下来生成 spec”不是回合终点。仅在必须获得用户确认的 ADR/spec 草稿、明确外部阻塞、用户主动停止或整个 skill 出口时暂停。确认完成后在同一任务链继续推进到下一可验证出口，不要求用户额外回复“继续”。
+本 skill 是 Long-Horizon Skill。阶段 ① 达到出口后立即进入阶段 ②；正常的阶段切换、进度汇报或“接下来生成 spec”不是回合终点。仅在必须获得用户确认的设计问题、明确外部阻塞、用户主动停止或整个 skill 出口时暂停。文档写入/发布不另起确认回合，不要求用户额外回复“继续”。
 
 ## 本 skill 独有门禁
 
-- ADR：草稿 → 用户确认 → 落盘，任何情况不例外；
-- spec：共识与 seam 合并为一个最终草稿，只设置一次发布前确认；
+- ADR：决策共识 → 直接落盘，不展示正文、不设置独立确认；
+- spec/issue：共识与 seam 达成后直接写入/发布，不展示正文、不设置发布前确认；
 - 全程不写代码、不修改测试、不执行实现。
 
 ## 异常

package/template/.agents/skills/grill-to-spec/references/rules.md

@@ -11,16 +11,21 @@
 ## ADR 增量规则
 
 - 只有同时满足“难逆转 / 无上下文费解 / 存在真实权衡”时才提议 ADR。
-- ADR 草稿必须完整展示并获得用户明确确认后才落盘；这是本 skill 的独有硬门禁。
+- 决策共识形成后直接落盘；不向用户展示 ADR 正文，不增加独立确认轮次。
 - 不把 ADR 当 glossary 一样静默 inline 更新。
 
 ## Spec 增量规则
 
 - Spec 的结构与字段全部委托 `to-spec`，本文件不维护第二份模板。
-- seam 提案并入最终 spec 草稿，不再制造独立的一次确认。
-- 发布前只做一次最终 spec 明确确认；确认后写入并标记 `ready-for-agent`。
+- seam 提案作为共识的一部分确认，不展示由此生成的 spec 正文。
+- 共识（含 seam）达成后直接写入并标记 `ready-for-agent`，不设置发布前确认。
 - 全文沿用已经确认的 glossary 词汇，并尊重所触区域既有 ADR。
 
+## Issue 增量规则
+
+- 按已配置的 issue tracker 直接发布 issue；issue 正文不在对话中展示。
+- 发布后只报告 issue 标识、状态和未纳入范围，不复制正文。
+
 ## 反模式
 
 - 不复制 `to-spec` 的章节清单、User Story 模板或 Implementation Decisions 细则。

package/template/.agents/skills/implement-review-loop/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: implement-review-loop
+description: "Implement changes with one executor model and one independent reviewer model, iterating on only the changed surface until no actionable issues remain."
+disable-model-invocation: true
+---
+
+Use two distinct roles:
+
+- **Executor**: implements the requested change, fixes findings, and runs the smallest relevant verification.
+- **Reviewer**: independently reviews the latest diff and relevant verification results. It does not perform the implementation.
+
+Workflow:
+
+```text
+Executor implements
+→ targeted verification
+→ Reviewer reviews latest diff
+→ if findings exist: Executor fixes only those findings
+→ targeted re-verification
+→ Reviewer re-reviews changed parts and unresolved findings
+→ repeat until Reviewer reports no actionable issues
+```
+
+Rules:
+
+- Keep implementation, testing, and review scoped to the current change and directly affected paths.
+- Prefer targeted tests: changed test files, affected modules, regression cases, or the original reproduction path.
+- Do not rerun equivalent checks after every small edit.
+- Reviewer should inspect the latest diff first, then only enough surrounding code to validate behavior and integration.
+- On subsequent rounds, review the new changes plus unresolved findings; do not restart a whole-project review.
+- Expand test or review scope only when the change crosses modules, modifies shared/public contracts or core infrastructure, targeted evidence is insufficient, final release/merge validation requires it, or the user explicitly requests it.
+- Findings must be concrete and actionable. Separate blockers from optional improvements.
+- Stop the loop when the Reviewer has no actionable findings and targeted verification is green.
+- Do not let the Reviewer silently become the Executor; preserve role independence throughout the loop.

package/template/.agents/skills/implement-review-loop/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Implement Review Loop"
+  short_description: "Implement with an independent review loop"
+policy:
+  allow_implicit_invocation: false

package/template/.agents/skills/tdd-implement/SKILL.md

@@ -16,7 +16,7 @@ disable-model-invocation: true
 - **多 issue**：`.scratch/<feature>/issues/` 下存在多个 `Type: task` 文件时，先读取 [orchestration.md](references/orchestration.md)，按 `Blocked by` 构建 DAG、Kahn 分层，再由主代理按层串行完成各 issue。
 - `Type: research`、`prototype`、`grilling` 分流到对应技能，不进入本技能。
 
-多 issue 的 A0-A5 是编排控制活动，不是额外的产品交付阶段：依赖图、分层、串行调度、层收敛、全量收敛和回退/冲突处理的详规只在 [orchestration.md](references/orchestration.md) 中维护。
+多 issue 的 A0-A5 是编排控制活动，不是额外的产品交付阶段：依赖图、分层、串行调度、层收敛、最终收敛和回退/冲突处理的详规只在 [orchestration.md](references/orchestration.md) 中维护。
 
 ## 三阶段 Steps
 
@@ -40,7 +40,7 @@ Finalize 出口：commit 已创建、Acceptance Criteria 全部通过，Tracker
 - 一个 seam 是公共可观察边界；一个 Behavior 是一个红-绿 cycle；一个 seam 可以包含多个 Behaviors。Seam/Behavior 的细节和 Todo 粒度只在进入 Step ② 时读取 [red-green.md](references/red-green.md)。
 - 每个 issue 只在 Verify 的最终 diff 稳定后调用一次 `code-review`；审查维度、reviewer 数量、提示词和输出格式全部由 `code-review` 自己定义，`tdd-implement` 不复制这些规则。`code-review` 未完成或存在 blocking finding 时 issue 不得收敛；A3 层收敛不再次调用 review。
 - 当前 issue 的范围、Acceptance Criteria、Out of Scope、测试/typecheck/build/真实运行证据和最终 commit 必须可追溯。Seam 或专项测试绿色不代表 issue 完成；三个阶段出口与 Finalize 全部满足后才可标记 `resolved`。
-- 多 issue 模式中，每个 issue 只提交一个独立 commit；issue 影响范围测试在 Step ③ 执行，全仓测试由 orchestration 的 A4 在全部 issue 完成后执行一次。
+- 多 issue 模式中，每个 issue 只提交一个独立 commit；issue 影响范围测试在 Step ③ 执行，A4 只做最终编排收敛，不额外扩大测试范围。
 
 ## 引用
 

package/template/.agents/skills/tdd-implement/references/orchestration.md

@@ -10,7 +10,7 @@
 - [A1：Kahn 拓扑分层](#a1kahn-拓扑分层)
 - [A2：分层串行调度](#a2分层串行调度)
 - [A3：层收敛](#a3层收敛)
-- [A4：全量收敛](#a4全量收敛)
+- [A4：最终收敛](#a4最终收敛)
 - [A5：回退与冲突处理](#a5回退与冲突处理)
 
 ---
@@ -80,7 +80,7 @@ for each layer Li in L1..Ln:
 全部层完成后进入 A4
 ```
 
-每个 issue 的 Verify 只运行当前 issue 影响范围内的完整测试；全仓测试不在每个 issue 中重复执行。当前 issue 的最终 diff 稳定后只调用一次 `code-review`；review 的内部方法完全由 `code-review` 定义。修复 blocking finding 后执行受影响验证和 finding delta recheck，不重复调用完整 `code-review`。
+每个 issue 的 Verify 只运行当前 issue 影响范围内的测试；编排层不额外扩大测试范围。当前 issue 的最终 diff 稳定后只调用一次 `code-review`；review 的内部方法完全由 `code-review` 定义。修复 blocking finding 后执行受影响验证和 finding delta recheck，不重复调用完整 `code-review`。
 
 主代理在层内和层间连续调度：一个 issue 的 Finalize 出口满足后，立即取下一个 issue，直到全部层完成或发生明确外部阻塞。进度输出并入执行序列，不在正常切换点等待用户“继续”。
 
@@ -129,11 +129,11 @@ A3 只做编排收敛，不再次调用 `code-review`；正式 review 已在每
 
 任一项失败，定位到该层失败 issue，按 A5 回退并重做该 issue 的受影响阶段或 Behavior，然后重新收敛本层。
 
-## A4：全量收敛
+## A4：最终收敛
 
 全部层完成且各层收敛通过后：
 
-1. 按 A0 的验证矩阵运行一次仓库全量测试；这是多 issue 流程唯一的全量回归点。只有修复全量失败后才允许必要重跑；
+1. 汇总并确认各 issue 的相关测试、typecheck/build、真实运行和 review 证据仍对应最终状态；若后续改动使证据失效，只重新验证受影响范围；
 2. 执行 `git merge-base --is-ancestor $BASE_HEAD HEAD`；失败时按 A5 恢复后重验；
 3. 执行 `git status`，确认无 `[DEBUG-...]`、一次性脚本或未跟踪临时文件；
 4. 汇总各 issue 回执卡片的 commit、Behaviors、Acceptance Criteria、测试、真实运行和文档对齐结果；汇总只在对话输出，不另写汇总文件。
@@ -141,7 +141,7 @@ A3 只做编排收敛，不再次调用 `code-review`；正式 review 已在每
 ### A4 出口
 
 - 全部 issue 已有独立 commit、实施总结和 `progress.md` 派生记录；
-- 全量测试通过；
+- 各 issue 的受影响验证证据仍对应最终状态；
 - 工作区卫生、历史校验和真实运行要求均满足；
 - `progress.md` 与 `issues/*.md` 一致，不一致时以 issue 真相源为准并修复派生视图。
 
@@ -156,7 +156,7 @@ A5 负责所有编排级失败，不把失败静默吞掉，也不把不相关
 | Red-Green 的有效 Red、实现、typecheck 或 targeted test 失败 | 回到该 issue 的 Red-Green，修复当前 Behavior 并重新验证 |
 | Verify 的测试、build、真实运行或 review blocking finding 失败 | 回到受影响 issue 的对应阶段；修复后只做受影响检查和 delta review |
 | Finalize 的必要 docs、commit 或 Tracker 失败 | 保持 issue 未 resolved，修复 Finalize 问题后重新验证 |
-| 全量测试失败 | 定位到引入失败的 issue，按上述路径修复；只在修复后重跑必要范围和全量测试 |
+| A4 收敛发现验证证据失效 | 定位到受影响 issue，按上述路径修复；只重新验证受影响范围 |
 | `Blocked by` 依赖未完成 | 后续 issue 保持 `blocked`，前置 issue resolved 后自动解阻 |
 | 多 issue 预期修改同一文件 | 记录冲突，按编号串行；无法安全归属时暂停并请求用户决定 |
 | Git 历史祖先校验失败 | 立即停止写入，使用 `git reflog` 找回 `BASE_HEAD` 之后的提交，校验通过后继续 |

package/template/.agents/skills/tdd-implement/references/stages.md

@@ -1,6 +1,6 @@
 # 三阶段详细定义 + Finalize
 
-单 `spec` / 单 `task` 与多 `task` 共用下列三个交付阶段；Verify 通过后执行 Finalize 收尾，Finalize 不计入阶段。多 issue 的依赖图、Kahn 分层、层收敛、全量收敛和回退/冲突处理见 [orchestration.md](orchestration.md)。TDD 语义以 [tdd 技能](.agents/skills/tdd/SKILL.md) 为唯一事实源，不在此重写。
+单 `spec` / 单 `task` 与多 `task` 共用下列三个交付阶段；Verify 通过后执行 Finalize 收尾，Finalize 不计入阶段。多 issue 的依赖图、Kahn 分层、层收敛、最终收敛和回退/冲突处理见 [orchestration.md](orchestration.md)。TDD 语义以 [tdd 技能](.agents/skills/tdd/SKILL.md) 为唯一事实源，不在此重写。
 
 ## 目录
 
@@ -61,7 +61,7 @@ Seam 或专项测试绿色不等于 issue 完成；只有三个阶段与 Finaliz
    - `code-review` 可用性；
    - 可用的 browser 或 Playwright 路径；
    - ticket 要求的真实运行验证方式。
-6. 建立一次验证矩阵，列出 targeted tests、typecheck、全量测试、必要 build、smoke/package check 和真实运行验证，并记录各项的触发条件，后续只复用这份矩阵。
+6. 建立一次验证矩阵，列出 targeted tests、typecheck、必要 build、smoke/package check 和真实运行验证，并记录各项的触发条件，后续只复用这份矩阵。
 7. 识别公共测试边界和 Behaviors。一个 Seam 是一个公共可观察边界；一个 Behavior 是一个红-绿 cycle；一个 Seam 可以包含多个 Behaviors。每个 Behavior 明确输入、可观察输出、对应 Acceptance Criterion 和验证层级。
 8. spec 已确认且未变化的 Seam 直接复用；只有出现需求歧义、验收缺口、范围变化、破坏性操作或互斥方案时才请求用户确认。
 
@@ -142,8 +142,7 @@ Seam 或专项测试绿色不等于 issue 完成；只有三个阶段与 Finaliz
 
 ### 测试与真实运行验证
 
-- 多 issue 模式只运行当前 issue 影响范围内的完整测试；不在每个 issue 重复运行全仓测试。全部 issues 完成后由 orchestration A4 运行一次全仓测试。
-- 单 issue 或单 spec 模式运行仓库完整测试。按照 Contract 的验证矩阵执行，不同时运行等价命令。
+- 单 issue / 单 spec 与多 issue 均只运行当前 issue 影响范围内的测试，按照 Contract 的验证矩阵执行，不同时运行等价命令；不因进入 Verify 自动扩大测试范围。
 - ticket 要求真实运行时，优先使用专用 browser 工具，其次使用项目已有 Playwright；HTTP/CLI 只能补充 API 验证，不能替代 WebUI 验证。
 - 真实进程验证使用隔离配置和临时端口，保存 PID，记录实际请求结果或页面可见结果，结束时清理进程和临时目录。
 
@@ -252,4 +251,4 @@ Progress: pending | in_progress | done | blocked
 | ③ Verify | 测试、build、真实运行或 review finding 失败 | → ② 修复 Behavior；需求偏差 → ① |
 | Finalize | 必要 docs 未同步、commit 失败或 Tracker 信息不完整 | → ①/③ 修复对应问题；仍在 Finalize 完成前解决 |
 
-多 issue 的层收敛、全量失败、依赖冲突和跨 issue 修改冲突按 [orchestration.md](orchestration.md) A5 回退，不跨 issue 无记录改动。
+多 issue 的层收敛、最终收敛、依赖冲突和跨 issue 修改冲突按 [orchestration.md](orchestration.md) A5 回退，不跨 issue 无记录改动。

package/template/.agents/skills/tdd-implement/references/verify.md

@@ -8,7 +8,7 @@
 
 ## 规则
 
-- 单 issue / 单 spec：按 Contract 验证矩阵运行完整相关测试；多 issue：只跑当前 issue 影响范围，全仓测试留给 orchestration A4。
+- 单 issue / 单 spec 与多 issue 均按 Contract 验证矩阵运行当前 issue 影响范围测试；不因进入 Verify 自动扩大测试范围。
 - ticket 要求真实运行时，优先专用 browser，其次项目已有 Playwright；HTTP/CLI 不能替代 WebUI 可见验证。
 - 临时进程必须使用隔离配置/端口，记录 PID 与实际结果，结束后清理。
 - 当前 issue 的最终 diff 稳定后，调用一次 [code-review](.agents/skills/code-review/SKILL.md)。`tdd-implement` 只规定调用时机；审查维度、reviewer 数量、提示词、上下文与输出格式以 `code-review` 为唯一事实源。

package/template/.opencode/commands/grill-to-spec.md

@@ -10,4 +10,4 @@ description: 编排 grill-with-docs → to-spec，把设计打磨成共识并发
 
 - 只编排与产出：设计打磨成共识 → 综合成 spec 发布，不写代码、不动源码
 - 产出物限：领域文档（glossary/ADR）与 spec
-- ADR 落盘必须经用户显式确认
+- 共识达成后直接写入/发布 ADR、spec 与 issue，不向用户展示正文；只报告路径或标识、状态和范围摘要

package/template/AGENTS.md

@@ -4,8 +4,8 @@
 * 外部调研 / 方案比较 → `research`
 * 原型 / PoC → `prototype`
 * 简单修改 → 直接实现
+* 实现 + 独立验收闭环 → `implement-review-loop`
 * TDD / 集成测试 → `tdd`
-* bug / 异常 / 性能 → `diagnose-fix`
 * 代码审查 → `code-review`
 * 设计质询 → `grilling`
 * 领域建模 → `domain-modeling`
@@ -21,7 +21,6 @@ codegraph explore "<问题>"
 codegraph init
 codegraph explore "<问题>"
 ```
-* 优先于 `Read`、`grep`、`rg`、`find` 和代码探索子代理。
 * 从最小必要上下文开始；返回完整源码即视为已读。
 * 信息不足时只针对缺口继续 `explore`；已锁定符号时使用 `codegraph node`。
 * CodeGraph 无法提供必要信息时，才降级到最小必要的读取 / 搜索。
@@ -38,9 +37,14 @@ codegraph explore "<问题>"
 * 仅在需要用户判断或授权时中断闭环。
 ## 验证
 服从全局授权规则。
-* 已授权时执行能证明本次改动正确的最小验证。
-* bug 验证原复现路径；性能问题使用可测量指标。
-* 根据验证反馈修正，不重复等价检查或自动增加 review / CI。
+* 默认只验证本次修改及直接受影响路径；优先相关单测、单文件测试、模块测试和原复现路径。
+* 修复什么就测试什么；根据反馈继续修正，不重复等价检查。
+* 不因每个小步骤自动扩大测试范围。
+* 仅当修改跨模块、触及公共接口/核心基础设施、局部验证不足以证明正确、进入发布/合并最终验收，或用户明确要求时，才考虑更大范围验证。
+## Review
+* 默认只 review 本轮 diff、修改文件及直接受影响调用链。
+* 修复后只复验新增修改和此前未通过项，不重复审查无关代码。
+* 仅在影响面明显扩大、局部 review 无法建立信心、进入发布/合并最终验收，或用户明确要求时扩大 review 范围。
 ## Harness
 同类问题反复出现时，优先将约束落实到测试、lint、类型、工具或代码结构，而不是继续扩充本文件。
 ## Git