fix: skills/ 9文件 P0+P1 收口 - Gate编号/HR定义/纯文档路径/通知链路

P0:
- agent-bootstrap: Gate3/4/5 改为 Implementation/QA Validation/Release；HR#1/HR#2 明确为 Human review 节点
- engineer: 删除"等待文档PR合并通知""收到Human通知后开始实现"强制链路；改为"文档PR合并=设计确认"
- architect: 删除"签字(HR#1)""签字(HR#2)"表述；HR是Human review不是Agent签字
- workflows/qa-validation: Gate4前签字改为 PM+Architect+Engineer（与002一致）
- workflows/human-review: 拆清开发交付路径与纯文档交付路径；HR#1/HR#2明确为Human review

P1:
- team-lead: "Human合并后通知Engineer"改为"文档PR合并后Engineer可进入Implementation"
- product-manager: 删除"通知Team Lead执行文档PR合并"；删除"通知Team Lead执行后续操作"
- qa-engineer: "等待Human合并"改为状态确认表述；Gate3开始改为"Engineer完成实现并通知QA后开始验证"

与 prompts/002_develop_pipeline.md 当前口径一致。

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: alpha-86

skills/agent-bootstrap/SKILL.md

@@ -91,9 +91,12 @@
 
 - Gate 1: 自举骨架和团队就绪
 - Gate 2: 本轮功能实现完成
-- Gate 3: 文档 PR 合并（Human Review #1）
-- Gate 4: 代码 PR 合并（Human Review #2）
-- Gate 5: Issue Comment Gate + 发布
+- Gate 3: Implementation（实现阶段）
+- Gate 4: QA Validation（验证阶段）
+- Gate 5: Release（发布阶段）
+
+> 文档 PR 合并（Human Review #1）是 Gate 2 与 Gate 3 之间的 Human review / merge 节点，不是 Gate 编号。  
+> 代码 PR 合并（Human Review #2）是 Gate 4 与 Gate 5 之间的 Human review / merge 节点，不是 Gate 编号。
 
 ## AgentDevFlow 自举完成判定
 

skills/architect/SKILL.md

@@ -51,9 +51,9 @@ Architect 主持评审但不签自己的 Tech Spec。
 | Gate 1 | 评审技术可行性、识别技术风险 | 代替 PM 起草 PRD | 确认后通知 Engineer 待命 |
 | Gate 2 | 主持 Tech Spec 评审（不签自己的）、识别风险和依赖 | 签自己的 Tech Spec | 确认 QA + Engineer 已签字 |
 | QA Case Design | 确认测试设计完整性、签字 | 代替 QA 起草 Case | 确认 PM + Engineer 已签字 |
-| 文档 PR 合并 | 评审设计文档、出具独立评审意见、签字（HR#1）| 代替 Human 做合并决策 | 确认 HR#1 评审意见已落地 |
+| 文档 PR 合并 | 评审设计文档、出具独立评审意见 | 代替 Human 做合并决策 | 确认 HR#1 评审意见已落地 |
 | Gate 3 | 确认实现与 Tech Spec 一致性 | 代替 Engineer 实现 | 记录一致性检查结果 |
-| 代码 PR 合并 | 评审代码与 Tech 一致性、签字（HR#2）| 代替 Human 做合并决策 | 确认 HR#2 评审意见已落地 |
+| 代码 PR 合并 | 评审代码与 Tech 一致性 | 代替 Human 做合并决策 | 确认 HR#2 评审意见已落地 |
 | Gate 5 | 技术放行签字 | 代替 Human 做发布决策 | 确认技术风险已关闭 |
 
 ## 能力增强层（可选）

skills/engineer/SKILL.md

@@ -55,17 +55,17 @@ Engineer 完成后通知 QA 开始验证，不得自行宣布完成闭环。
 
 | Gate | Engineer 能做什么 | Engineer 不能做什么 | Engineer 完成后下一动作 |
 |------|-----------------|-------------------|----------------------|
-| Gate 0 | 待命、准备接收设计输入 | 提前开始实现 | 等待文档 PR 合并通知 |
+| Gate 0 | 待命、准备接收设计输入 | 提前开始实现 | 等待文档阶段完成 |
 | Gate 2 | 评审 Tech Spec 可实现性（必签）| 代替 Architect 写 Tech | 反馈可实现性意见 |
 | QA Case Design | 评审测试 Case 可实现性（必签）| 代替 QA 起草 Case | 反馈可实现性意见 |
-| 文档 PR 合并 | — | 参与合并 | 收到 Human 通知后开始实现（Gate 3）|
+| 文档 PR 合并 | — | 参与合并 | 文档 PR 合并 = 设计确认，可进入 Gate 3 |
 | Gate 3 | 基于已确认设计实现（PRD + Tech）、编写单测 | 脱离 Tech Spec 自行实现 | 通知 QA 开始验证 |
 | Gate 4 | 修复 QA 缺陷、响应反馈 | 在缺陷未修复时宣称完成 | 修复完成后通知 QA 重验 |
 | 代码 PR 合并 | — | 参与合并 | — |
 | Gate 5 | — | 参与 Gate 5 决策 | — |
 
 Engineer 的工作流关键路径：
-1. 收到 Human 的实现通知（文档 PR 已合并）
+1. 确认文档 PR 已合并（设计确认）
 2. 基于 PRD + Tech Spec 实现
 3. 编写/更新单元测试
 4. 形成 QA 交接证据

skills/product-manager/SKILL.md

@@ -39,7 +39,7 @@
 
 PM 的**完成标准**是：**文档阶段交付完整（PRD + Tech + QA Case Design + Human Review #1 通过）**。
 
-**Issue 关闭不是 PM 的职责**，也不是 PM 完成的标准。PM 发布 HR#1 通过评论后，应通知 Team Lead 执行后续操作。
+**Issue 关闭不是 PM 的职责**，也不是 PM 完成的标准。PM 完成文档阶段交付后，后续由 Team Lead 协调推进。
 
 ### PR 合并权限
 
@@ -54,7 +54,7 @@ PM 的**完成标准**是：**文档阶段交付完整（PRD + Tech + QA Case De
 | Gate 1 | 起草/主持评审/签字 | 代替 Architect/QA 评审 | 通知 Architect 开始 Tech |
 | Gate 2 | 确认 Tech 覆盖 PRD/签字 | 代替 Architect 写 Tech | 等待 QA Case Design 完成 |
 | QA Case Design | 确认测试覆盖范围/签字 | 代替 QA 起草 Case | 创建 doc-{issue} 分支 |
-| 文档 PR 合并 | 创建文档 PR、发起/整理 HR#1 结论/签字 | 代替 Human 做合并决策 | **通知 Team Lead 执行文档 PR 合并** |
+| 文档 PR 合并 | 创建文档 PR、发起/整理 HR#1 结论 | 代替 Human 做合并决策 | 确认 HR#1 评审完成，Human 执行 PR 合并 |
 | Gate 3 | 跟踪进度/确认口径 | 执行实现 | 跟踪 QA 验证 |
 | Gate 4 | 确认验收口径/签字 | 执行验证 | 确认代码 PR 条件 |
 | 代码 PR 合并 | — | 参与合并 | 等待 Human 执行 |
@@ -72,7 +72,7 @@ PM 在文档阶段的工作流终点（关键路径）：
 2. 完成 PRD/Tech/QA Case Design 文档
 3. 创建 `doc-{issue}` 分支、提交文档 PR
 4. HR#1 通过后，在 Issue 下发布结构化结论
-5. **通知 Team Lead 执行文档 PR 合并**（PR 合并是 Human 专属）
+5. **确认 HR#1 评审完成**，由 Human 执行 PR 合并（PR 合并是 Human 专属）
 
 PM 不得以任何理由替代 Human 执行合并操作或关闭 Issue。
 

skills/qa-engineer/SKILL.md

@@ -59,10 +59,10 @@ QA 不得在阻塞缺陷未关闭时发布 Approved 结论。
 | Gate 1 | 评审验收标准完整性、签字 | 代替 PM 起草 PRD | 指出验收标准缺失项 |
 | Gate 2 | 评审 Tech 可行性、签字 | 代替 Architect 写 Tech | 反馈 Tech 评审意见 |
 | QA Case Design | 起草测试 Case、签字 | — | 提交 PM + Architect + Engineer 三方签字 |
-| 文档 PR 合并 | — | 参与合并 | 等待 Human 合并文档 PR |
-| Gate 3 | 跟踪进度、准备 QA 验证 | 代替 Engineer 实现 | 等待 Human 合并文档 PR 后开始 |
+| 文档 PR 合并 | — | 参与合并 | 确认文档 PR 已合并（设计确认）|
+| Gate 3 | 跟踪进度、准备 QA 验证 | 代替 Engineer 实现 | Engineer 完成实现并通知 QA 后开始验证 |
 | Gate 4 | 执行测试、记录结果、报告缺陷、出具质量结论 | 在缺陷未修复时发布 Approved | 修复后重新验证 |
-| 代码 PR 合并 | — | 参与合并 | 等待 Human 合并代码 PR |
+| 代码 PR 合并 | — | 参与合并 | 确认代码 PR 已合并（实现确认）|
 | Gate 5 | 确认测试覆盖已执行 | 自行关闭 Issue | 出具测试覆盖报告 |
 
 QA 的工作流关键路径：

skills/team-lead/SKILL.md

@@ -62,11 +62,11 @@ Team Lead 负责推动以下 Human 专属操作，不代替 Human 执行：
 | Gate 1 | 主持评审、确认流转、判断是否需要重审 | 代替 Architect/QA 做签字 | 确认 PM 通知 Architect 开始 Tech |
 | Gate 2 | 主持 Tech Review 评审、确认流转 | 代替 Architect 写 Tech | 确认 Engineer + QA 已签字 |
 | QA Case Design | 跟踪 QA Case Design 三方签字进度 | 代替 QA/PM/Architect 签字 | 确认三签完成后推动文档 PR |
-| 文档 PR 合并 | 确认 HR#1 评审完成、推动 Human 合并 | 代替 Human 做合并决策 | Human 合并后通知 Engineer 开始实现 |
+| 文档 PR 合并 | 确认 HR#1 评审完成、推动 Human 合并 | 代替 Human 做合并决策 | 文档 PR 合并后 Engineer 可进入 Implementation |
 | Gate 3 | 协调并行进度、确保文档 PR 不被跳过 | 代替 Engineer 实现 | 确认 QA 开始验证 |
 | Gate 4 | 协调 QA 验证进度、确认质量结论 | 代替 QA 做质量结论 | 确认代码 PR 发起 |
 | 代码 PR 合并 | 确认 HR#2 评审完成、推动 Human 合并 | 代替 Human 做合并决策 | Human 合并后确认 Release |
-| Gate 5 | 主持 Release 评审、推动 Human 发布 | 代替 Human 做发布决策 | Human 发布后关闭 Issue |
+| Gate 5 | 主持 Release 评审、推动 Human 发布 | 代替 Human 做发布决策 | Human 执行发布决策与 Issue 关闭 |
 
 Team Lead 的工作流关键路径：
 1. 主持 Gate 0 启动，确认角色分配

skills/workflows/human-review.md

@@ -85,5 +85,9 @@
 - **不存在任何可以跳过 Human Review #1 的情况**
 - Human Review #1 对应文档 PR（`doc-{issue}` 分支）合并 = 设计确认
 - Human Review #2 对应代码 PR（`feature-{issue}` 分支）合并 = 实现确认
-- **强制流程顺序**（不得颠倒或跳过）：
+- **开发交付路径**（不得颠倒或跳过）：
   - Gate 1 → Gate 2 → QA Case Design → 文档 PR（HR#1）→ Gate 3 → Gate 4 → 代码 PR（HR#2）→ Gate 5
+- **纯文档交付路径**（同等重要，不经过 Gate 3/Gate 4/HR#2）：
+  - Gate 1 → Gate 2 → QA Case Design → 文档 PR（HR#1）→ Release → Issue Close
+
+> HR#1 / HR#2 是 Human review / merge decision，不是 Agent 签字节点。

skills/workflows/qa-validation.md

@@ -61,7 +61,7 @@
 - Architect：技术放行确认（Gate 4 必需）
 - Engineer：实现确认
 
-三方（PM + Architect + QA）签字完成，方可进入 Human Review #2。
+QA 产出测试报告后，由 PM + Architect + Engineer 三方评审测试报告并签字，然后进入代码 PR / Human Review #2。
 
 ## 人工评审规则