@xulthekl/team-flow 0.22.4

package/skills/workflow-feedback/references/review-mode.md

@@ -0,0 +1,92 @@
+# 回顾模式：从会话中自动识别问题信号
+
+> 本文件定义 workflow-feedback 回顾模式的问题识别规则。
+> 回顾模式在无 argument 或由 release-archivist 联动时触发。
+
+## 触发条件
+
+- 用户调用 `/workflow-feedback` 但未传入 argument
+- release-archivist 收尾时建议触发
+- 用户说"回顾一下这次工作流"、"有什么问题吗"
+
+## 问题信号识别
+
+扫描当前会话，识别以下信号：
+
+### 信号 1：skill 被纠正
+
+**特征**：skill 被调用后，用户手动纠正了方向。
+
+**识别模式**：
+- 用户说"不是这个"、"我要的是 XX 不是 YY"
+- skill 产出被用户大幅修改
+- 用户取消了 skill 的执行
+
+**映射分类**：`skill-trigger` 或 `ux-interaction`
+
+### 信号 2：用户不满表达
+
+**特征**：用户表达了对工作流的不满。
+
+**识别模式**：
+- "不对"、"不是这样"、"重来"
+- "怎么又问这个"、"之前不是说过了吗"
+- "太麻烦了"、"能不能简单点"
+
+**映射分类**：根据不满对象判定（skill/流程/交互）
+
+### 信号 3：状态回退
+
+**特征**：发生了 mandatory rewind 或阶段回退。
+
+**识别模式**：
+- 状态从 executing 回到 specifying/bridging
+- orchestrator 阶段从 S3 回到 S2
+- replan_log 有新增条目
+
+**映射分类**：`sop-flow`（回退本身可能是正常的，但频繁回退说明流程有问题）
+
+### 信号 4：重复确认
+
+**特征**：同一事项被确认多次。
+
+**识别模式**：
+- 用户回答了相同/相似的问题 2 次以上
+- 模型在不同阶段问了同一个决策
+
+**映射分类**：`ux-interaction`
+
+### 信号 5：工作流中断/跳过
+
+**特征**：工作流的某个步骤被跳过或中断。
+
+**识别模式**：
+- 用户说"跳过这步"、"先不管这个"
+- 某个阶段被标记为 skipped
+- 用户直接做了下一步该做的事
+
+**映射分类**：`sop-flow`（跳过可能说明该步骤不必要或位置不对）
+
+## 回顾输出格式
+
+回顾完成后，按以下格式汇总：
+
+```
+本次会话工作流回顾：
+- 检测到 N 个问题信号
+- 按分类汇总：
+  - skill-trigger: X 个
+  - sop-flow: Y 个
+  - ...
+- 建议记录的问题（按 severity 排序）：
+  1. [P?] <问题标题> — <分类>
+  2. ...
+- 是否要为这些问题生成 feedback 记录？
+```
+
+## 注意事项
+
+1. **回顾不等于记录**：回顾模式先汇总信号，询问用户后再逐条生成记录
+2. **误报容忍**：宁可多识别再让用户筛选，不要漏掉真正的问题
+3. **不记录业务问题**：只关注工作流本身的问题，业务代码 bug 不算
+4. **上下文限制**：只能分析当前会话的内容，无法跨会话分析

package/skills/workflow-orchestrator/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: workflow-orchestrator
+description: >-
+  产品级工作流编排器，产品级新需求的首选入口。从模糊需求到可执行 change
+  的全流程编排：需求澄清、PRD 产出（含原型验证）、实施计划、change 拆分
+  与分发。作为产品级唯一入口，内部路由到各阶段 skill。
+  不适用于：已有 change 内的操作（用 workflow-start）、独立工具操作
+  （ce-ideate/ce-strategy/prototype 等）、纯架构设计（用 architecture-design）。
+---
+
+# Workflow Orchestrator（产品级工作流编排器）
+
+从模糊需求到可执行 change 的产品级全流程编排：路径路由 → PRD+原型循环 → 计划 → 拆分验证 → 分发 → 监控。
+
+## 定位
+
+| 层级 | 编排器 | 管辖范围 |
+|------|--------|---------|
+| 产品级 | **workflow-orchestrator**（本 skill） | 路径路由 → PRD+原型循环 → 计划 → 拆分验证 → 分发 → 监控 |
+| 变更级 | workflow-start（不变） | exploring → ... → closing（8 态状态机） |
+
+**分层原则**：本 skill 管「做什么、什么顺序」（产品级策略），workflow-start 管「怎么做」（变更级执行）。二者通过 change 目录 + `.team-flow.yaml` 衔接。
+
+**设计哲学（v0.7）**：编排层**只编排**（状态判断、路由、阶段转换、用户确认），执行委托 subagent/会话 skill；从「固定管道」升级为「默认路径 + 任意时刻可重规划」；PRD vN = 一次迭代版本，迭代内变更不升版。
+
+## Use This Skill When
+
+- 用户提出新的产品级需求：「我有个想法」「做一个 XX 功能」「从头开始」、模糊需求
+- 需要编排多个阶段（brainstorm → plan → 拆 change）或管理 PRD 版本与 change 拆分策略
+- 续版需求（已有 PRD vN 要加功能）、重新计划、继续执行已拆分的 changes
+
+Do NOT invoke for:
+- 已在 team-flow change 内的流转控制（用 `/workflow-start`）
+- 单一 change 的实施（用 `/build-executor`）
+- 独立工具操作（`/ce-ideate`、`/ce-strategy`、`/prototype`、`/architecture-design` 等）
+
+## Execution Flow（S1-S5）
+
+### S1: 路径路由器
+**先做需求选择**（v0.15.0 多需求）：读 `.team-flow/registry.yaml`，确定 `active_requirement`（多需求则询问操作哪个/新建）。再判断 7 种入口路径之一；检查 baseline.md / CONCEPTS.md 并注入；复利注入（INDEX.md top-5）。**路由结果必须向用户显式确认**（路由是建议非决定）。详见 `references/s1-path-router.md`。
+
+### S2: PRD + 原型阶段
+调用 `/ce-brainstorm`（mode: orchestrated）产出 PRD 草稿；**冻结前派 `prd-completeness-reviewer` 子代理做 PRD 完整性评审**（v0.15.0，管"说得全不全"）；原型循环由编排层直接编排（prototype skill 内部编排产出 → prototype-reviewer 自动评审 → 人工评审 → 冻结）；冻结语义为 `frozen_downstream`（迭代内变更不升版）。反馈环路检查点：scope 是否合理。详见 `references/s2-prd-prototype-loop.md`。
+
+### S3: 计划阶段
+**入口一次性问定计划模式**（业务/一人公司），调用 `/ce-plan`（`pipeline_mode: orchestrator` + `plan_mode: business|solo`，跳过仪式开销、保留 repo research + change splitting + 依赖 DAG + 技术方向）产出 `prd/vN/plan.md`。plan 只到产品级策略 + 高阶技术设计，**不含接口清单**（属各 change 的 spec-writer）。反馈环路检查点：plan 是否暴露 PRD scope 问题（是→回退 S2）。详见 `references/s3-plan-pipeline.md`。
+
+### S4: 拆分验证与分发
+change-split-auditor 审计拆分质量（**必选门禁**，粒度/DAG 无环/并行策略/AC 预分配，PASS 后方可创建 change；FAIL → 回退 S3 调整后重新审计）；创建 change 目录（项目根 `changes/<name>/`）+ `.team-flow.yaml`；写入 change_dag；按依赖顺序分发。反馈环路检查点：依赖图是否可执行（否→回退 S3）。详见 `references/s4-split-validate.md`。
+
+### S5: 全局监控（change ≥ 2 必选）
+跟踪各 change 进度；cross-change-consistency-checker 检测跨 change 冲突；change closing 时复利晋升；必要时触发动态重规划。详见 `references/s5-monitoring.md`。
+
+## 反馈环路（保守策略：只允许相邻回退）
+
+- **S3 → S2**：plan 暴露 PRD scope 问题 → PRD vN 内修订（非升版）+ 变更履历，plan.md 归档为 .revN
+- **S4 → S3**：依赖图不可执行/粒度不合理 → 调整拆分策略，已建 change 目录保留增量调整
+- **S5 → S4**：跨 change 冲突需重新拆分 → 按在途 change 红/绿/灰区处置
+
+振荡上限：S2↔S3 回退 ≤2 次，超过升级人工介入。详见 `references/feedback-loops.md`。
+
+## 增量入口（S1 路由的 7 种路径）
+
+| 入口 | 条件 | 跳转 |
+|------|------|------|
+| 全新需求 | 无 PRD，需求模糊 | → S2 |
+| 续版需求 | 有 PRD vN，要加功能 | → S2（vN+1） |
+| 重新计划 | PRD 已冻结，plan 需调整 | → S3 |
+| 继续执行 | changes 已拆分，继续下一个 | → S4/S5（先输出状态恢复简报） |
+| 单 change 快速通道 | 需求极清晰、无 UI、无跨模块依赖的极小变更 | → 直接建 change → workflow-start |
+| 紧急修复（Hotfix） | bug/生产问题，最小范围修复 | → 建 change（type: hotfix）→ workflow-start |
+| **原型补跑/重跑**（v0.20.0） | PRD 已冻结（`frozen_downstream`）∧ `prototype/` 缺失/为空，或用户显式要求重做原型 | → 部分重入 S2 原型循环（S2 步骤 2→3→4）；PRD 不动，保留有效 S3/S4，闭环后恢复原 phase |
+
+## 状态模型
+
+**多需求并行（v0.15.0）**：`.team-flow/registry.yaml`（需求注册表 + `active_requirement` 活跃指针）+ 每需求一份 `.team-flow/requirements/<req-id>/orchestrator.yaml`（持久化记忆 / checkpointer）。各需求状态天然隔离，支持并行。单需求 orchestrator.yaml 含 requirement_id / workflow_phase / phases / replan_log / change_dag / prd_version。双层冻结（frozen_downstream / frozen_absolute），frozen 以 PRD frontmatter 为单一真相源。迁移兼容：检测旧 `<root>/.workflow-orchestrator.yaml` 自动迁入。动态重规划（三级意图分类器 + 红/绿/灰区 + DP-R 确认）见 `references/state-model.md`。
+
+## Guardrails
+
+- **不替代 workflow-start**：本 skill 不管理 8 态状态机流转
+- **不直接实施代码**：只编排，实施由 build-executor 执行
+- **后台子代理等待范式（v0.20.0）**：派发后台子代理（prototype-builder / reviewer / architecture-design 等长任务）后**依赖完成通知（`<task-notification>`）再行动**，**禁止反复 `TaskOutput(block=true)` 阻塞轮询**——其对长任务超时返回会倾泻完整子代理 transcript，撑爆主上下文、抵消"只编排"的轻上下文优势。长任务派发后可先处理可并行工作或结束本轮等待通知，**不空转死等**；确需中途观察用 `block=false` 轻量查询（仍返转录，尽量不用）。（设计 §22.2）
+- **不跳过 PRD 冻结**：PRD 必须经原型循环（或显式跳过）后才能进 ce-plan
+- **不跳过拆分审计**：change-split-auditor 审计 verdict = PASS 是创建 change 脚手架的前置条件（S4 必选门禁）
+- **路由是建议非决定**：S1 路由判断必须用户确认；重规划必须 DP-R 阻塞确认
+- **回退必写 replan_log**：active → pending 回退必须记录；受影响制品归档为 .revN，重入不读旧制品
+- **不阻断流程**：所有复利操作为 advisory 级，INDEX.md 读取失败时静默跳过
+
+## Output Standard
+
+每次交互结束时说明：
+1. 当前所处阶段（S1-S5）与 `.team-flow/requirements/<req-id>/orchestrator.yaml` 状态
+2. 已产出的制品（PRD/原型/plan/changes）
+3. 下一步建议（调用哪个 skill / 进入哪个 change）

package/skills/workflow-orchestrator/references/feedback-loops.md

@@ -0,0 +1,56 @@
+# 反馈环路详细规则（v0.7 新增）
+
+> 核心原则：PRD vN = 一次迭代版本。迭代内的调整通过 vN 内修订 + 变更履历管理，**不升版**。只有新的用户故事/迭代才触发 vN+1。设计依据：设计增强方案 v0.7 §17.3。
+
+## 回退规则（保守策略：只允许相邻回退）
+
+| 回退路径 | 触发条件 | 操作 | 制品处置 |
+|---------|---------|------|---------|
+| **S3 → S2** | plan 暴露 PRD scope 问题 | PRD vN 内修订 + 记录变更履历（临时解除 frozen_downstream） | plan.md → plan.md.revN（归档），S3 重入时从零产出 |
+| **S4 → S3** | 依赖图不可执行/粒度不合理 | 调整拆分策略 | 已创建的 change 目录保留，重新拆分后增量调整 |
+| **S5 → S4** | 跨 change 冲突需要重新拆分 | 重新评估拆分方案 | 见下方「在途 change 处置」 |
+
+## 在途 change 处置（S5 → S4，A3）
+
+S5→S4 回退时，按在途 change 状态分区处置（前置条件）：
+
+| 区域 | 条件 | 处置 |
+|------|------|------|
+| **绿区** | 所有 change 未 executing | 可直接重新拆分 |
+| **灰区** | 有 change executing | 逐个确认：暂停 / 废弃 / 保持 |
+| **红区** | 已 closing/closed | 只能新 change 修正（hotfix 路径） |
+
+在途 change 的处置决策记入 `replan_log`。已 closing/closed 的 change 其 delta 已合并，只能通过新 change 修正（hotfix 路径）。
+
+## 振荡上限（A11）
+
+- **S2↔S3 回退 ≤ 2 次**。超过后升级为人工介入，用户三选一：
+  1. 继续修订
+  2. 强制 vN+1 升版
+  3. 放弃
+
+## 制品处置规则（A10）
+
+- 回退时受影响制品重命名为 `.revN`（保留审计轨迹）
+- 重新进入阶段**不读取上一轮制品**，只读取修订后的上游制品，避免旧内容锚定
+
+## 变更履历格式
+
+记录在 PRD 文档的「决策与变更履历」章节：
+
+```markdown
+### 决策与变更履历
+| 时间 | 触发阶段 | 变更内容 | 原因 | 影响范围 |
+|------|---------|---------|------|---------|
+| 2026-07-24 | S3→S2 | 砍掉功能X | plan 分析发现技术不可行 | §7 功能清单、§8 处理说明 |
+```
+
+## 与双层冻结的关系
+
+- S3→S2 回退 = **临时解除 frozen_downstream**，S2 重新完成后恢复
+- 若 PRD 处于 `frozen_absolute`（用户显式确认或 vN+1 已启动），任何修改必须升版 vN+1，**不允许 vN 内修订**
+- frozen 状态以 `prd/vN/prd.md` frontmatter 为单一真相源。详见 state-model.md「双层冻结」
+
+## 复利集成
+
+每次阶段回退触发工作流模式复利捕获（`type: workflow_pattern`，`pattern_kind` 视情况为 reorder / change-split-adjust 等）。详见 state-model.md「工作流模式复利 L2」。

package/skills/workflow-orchestrator/references/s1-path-router.md

@@ -0,0 +1,81 @@
+# S1 路径路由器（v0.7 重写）
+
+> 原 v0.5「需求接收」。S1 是 orchestrator 的唯一入口，负责把任意时刻的用户输入路由到正确的阶段。设计依据：设计增强方案 v0.7 §17.2 / §17.4 / §17.9.1。
+
+## 职责边界
+
+S1 只做编排动作（需求选择、存在性检查、路径判断、阻塞式用户确认），上下文简报组装委托 `kickoff-context-assembler`（种子提示，建议做）。S1 不产出任何业务制品。
+
+## 需求选择（v0.15.0 新增，多需求并行第一步）
+
+读 `.team-flow/registry.yaml`：
+- **无注册表 / 无需求** → 新建需求：询问需求短码（`<req-id>`）与标题，创建 `.team-flow/requirements/<req-id>/orchestrator.yaml` + 登记 registry，设为 `active_requirement`。
+- **单个需求** → 直接采用为活跃需求。
+- **多个需求** → 用阻塞问题工具询问 LT 操作哪个（列出各需求 title/phase/prd_version），或选择「新建需求」；选中者设为 `active_requirement`。
+
+后续阶段读写的 `orchestrator.yaml` 一律指 `active_requirement` 对应的那份。迁移兼容：检测到旧 `<root>/.workflow-orchestrator.yaml` → 自动迁入 `.team-flow/requirements/<req-id>/orchestrator.yaml` 并登记 registry（一次性，提示用户）。
+
+## 7 种入口路径
+
+| 入口 | 判断条件 | 跳转 | 说明 |
+|------|---------|------|------|
+| **全新需求** | 无现有 PRD，需求模糊 | → S2 | 完整流程 |
+| **续版需求** | 有 PRD vN，用户要加功能 | → S2（PRD vN+1） | 新版本迭代 |
+| **重新计划** | PRD 已冻结，plan 需调整 | → S3 | 跳过 brainstorm |
+| **继续执行** | changes 已拆分，继续下一个 | → S4/S5 | 先输出状态恢复简报，用户确认后继续 |
+| **单 change 快速通道** | 需求极清晰，无需 PRD（仅限单一功能点、无 UI、无跨模块依赖的极小变更） | → 直接创建 change → workflow-start | 最轻量路径，无 PRD 锚点，**不可触发 S3→S2 回退** |
+| **紧急修复（Hotfix）** | bug/生产问题，需最小范围修复 | → 直接创建 change（type: hotfix，注入 bug 描述替代 PRD）→ workflow-start | closing 时强制补录复利 |
+| **原型补跑/重跑**（v0.20.0） | PRD 已冻结（`frozen_downstream`）∧ `prototype/` 缺失/为空，或用户显式要求重做/重跑原型 | → 部分重入 S2 原型循环（S2 步骤 2→3→4） | PRD 不动，保留有效 S3 plan / S4 changes，闭环后恢复原 phase；`replan_log` 记往返 |
+
+**判断顺序**：先查活跃需求的 `orchestrator.yaml`（`.team-flow/requirements/<req-id>/orchestrator.yaml`，如存在 → 多半是「继续执行」或「重新计划」），再查 `prd/` 目录（有 PRD → 「续版」候选），最后落到「全新需求」。Hotfix 由用户语义（bug/生产/紧急修复）显式触发。
+
+**原型补跑/重跑判据（v0.20.0，与「重新计划」「续版」区分）**：当 PRD 已冻结时，按用户意图三分：
+- 用户要**重做/补做原型**（「重新跑一遍原型」「prototype 没有了」「原型重做」）∧ `prototype/` 缺失/为空或用户明确不满现有原型 → **原型补跑/重跑**（部分重入 S2 原型循环，**PRD/plan/changes 不动**）。
+- 用户要**调整 plan**（拆分/依赖/技术方向）→ **重新计划**（→ S3）。
+- 用户要**加功能/扩 scope** → **续版需求**（→ S2，PRD vN+1 升版）。
+- 判别关键：原型补跑**不升 PRD 版、不重做 plan**，仅原型循环重入；若原型循环暴露 scope 问题，再升级为 S3→S2 回退修订（脱离本路径）。
+
+## 项目基线与词汇检查
+
+- 检查 `docs/architecture/baseline.md`：
+  - 存在 → 注入为架构上下文（技术栈/模块/数据模型），替代「从零侦察」
+  - 不存在 → advisory 提示「建议先运行 `/workflow-bootstrap` 建立项目基线」（**不阻断**）
+- 检查 `CONCEPTS.md`：存在 → 注入领域词汇表
+
+## 复利注入（advisory 级）
+
+读取 `docs/solutions/INDEX.md`（如存在），过滤 `phase = prd OR cross-phase` 且 domain 匹配的经验，取 top-5（按 severity 降序）摘要注入为上下文约束。读取失败时静默跳过，不阻断。
+
+工作流模式复利（L2）：S1 路由时额外注入历史 `workflow_pattern` top-3（confidence ≥ 0.5）。详见 state-model.md「工作流模式复利 L2」。
+
+## 路由结果显式呈现（强制，B3）
+
+路由判断后**必须**向用户确认，路由是建议而非决定：
+
+```
+我判断你当前处于【续版需求】路径（已有 PRD v1，将创建 v2），确认？[Y / 选择其他路径]
+```
+
+使用平台阻塞问题工具等待用户确认。用户可改判任意路径。
+
+## 「继续执行」状态恢复简报
+
+读取活跃需求的 `orchestrator.yaml` 的 `change_dag`，汇总各 change 状态（从各 change 的 `.team-flow.yaml` 同步；计划 v1.0.0 改名为 `.team-flow.yaml`），输出简报后由用户选择下一步（**支持跳过被阻塞的 change**）：
+
+```
+状态恢复简报：
+- change-1 [closed]    已完成
+- change-2 [executing] 进行中（state: building）
+- change-3 [pending]   依赖 change-2，未开始
+建议下一步：继续 change-2（/workflow-start）。确认？
+```
+
+**幂等恢复**：通过 yaml + 制品实际存在性双重校验重建状态。yaml 与实际不一致时，以制品实际存在性为准并修正 yaml。详见 state-model.md。
+
+## 完成条件
+
+- 活跃需求已确定（`active_requirement` 已设置，registry 已登记）
+- 入口路径已确认（用户确认）
+- baseline/CONCEPTS 已注入（或 advisory 提示）
+- 复利经验已注入（或静默跳过）
+- 活跃需求的 `orchestrator.yaml`（`.team-flow/requirements/<req-id>/orchestrator.yaml`）已初始化/更新 `workflow_phase` 与 S1 阶段状态

package/skills/workflow-orchestrator/references/s2-prd-prototype-loop.md

@@ -0,0 +1,96 @@
+# S2 PRD + 原型阶段（v0.7 重写，原型循环上提）
+
+> v0.7 关键变更：原型循环由 orchestrator **直接编排**（思路 B），不再藏在 ce-brainstorm 内部。设计依据：设计增强方案 v0.7 §17.2 / §17.8 / §17.10。
+
+## 编排层 vs 执行层
+
+| 编排层（orchestrator 自己做） | 执行层（委托） |
+|------------------------------|---------------|
+| 调用 ce-brainstorm（传路径） | PRD/原型产出（会话级 skill） |
+| 原型触发判断 | 原型自动评审（`prototype-reviewer` agent） |
+| 循环控制（verdict 路由、≤3 轮） | 复利时刻检测（`compound-moment-detector`，可选） |
+| frozen 确认 | — |
+| 人工评审阻塞确认 | — |
+
+## 步骤
+
+### 1. 产出 PRD 草稿
+
+调用 `/ce-brainstorm`，**显式传入** `mode: orchestrated`（B6 跨 skill 集成规约：用显式入参，禁止语义推断）。被 orchestrator 调用时 ce-brainstorm 跳过其内部 Phase 3.5 原型循环（循环归编排层），直接调用时（standalone）保留。
+
+> **阶段后压缩协议（A4）**：ce-brainstorm 冻结 PRD 后，编排层主动触发 compact，只保留 `prd/vN/prd.md` 路径与 frozen 状态，丢弃过程对话。会话级 skill 的过程对话会进入编排层上下文窗口，必须压缩。
+
+### 2. 判断是否需要原型
+
+- 需要（涉及 UI/交互/页面）→ 进入原型循环
+- 不需要（纯后端/无 UI）→ PRD 直接冻结，跳到步骤 5
+
+### 3. 原型循环（编排层控制）
+
+```
+调用 prototype skill 产出原型
+  → 自动评审（prototype-reviewer agent，独立上下文）
+    → 输出一致性报告（编排层落盘到 prd/vN/prototype-auto-review.md）
+    → FAIL（Critical > 0）→ 修正 → 重新自动评审（≤3 轮）
+    → PASS_WITH_WARNINGS → 警告项交人工裁定
+    → PASS → 进入人工评审
+  → 人工评审（阻塞确认，聚焦：美观/体验/品牌/信息密度）
+    → 通过 → 冻结
+    → 不通过 → 修正 → 回自动评审
+```
+
+**自动评审 6 维度**（详见「原型自动评审」小节）：D1 页面完整性 / D2 功能覆盖 / D3 字段一致性 / D4 导航一致性 / D5 术语一致性 / D6 状态覆盖。
+
+**收敛检测**：连续两轮不一致项集合无缩小（修正无效/误报死循环）→ 立即转人工，不等满 3 轮。
+
+**人工介入 = 编排层阻塞确认**（非 subagent，因 subagent 不能 AskUserQuestion），呈现争议项 + 选项（接受现状 / 指定修正方向 / 升版 / 放弃原型）。
+
+### 4. 冻结
+
+设置 `frozen_downstream`（见 state-model.md「双层冻结」）。冻结后，**迭代内变更不升版**，在 vN 内修订 + 记录决策/变更履历。
+
+### 5. 复利捕获
+
+检测可复利时刻（需求矛盾、原型返工、自动评审发现不一致并修正等）。每次自动评审发现不一致并修正后触发：
+
+```bash
+npx --yes --package @xulthekl/team-flow@0.22.4 tf solutions capture --phase prd --domain <domain> --type pitfall --severity <sev> --summary "<summary>"
+```
+
+### 6. 反馈环路检查点
+
+- PRD scope 是否合理？是否有明显遗漏？
+- 如果 S3 发现 scope 问题，可回退到 S2 修订（**vN 内修订，非升版**）。详见 feedback-loops.md。
+
+## 原型自动评审（§17.10）
+
+**实现形式**：独立 `prototype-reviewer` agent（只读审查员，对齐 code-reviewer 模式）。
+- tools: Read, Bash, Grep, Glob（**无 Write**，报告写在 final response，编排层落盘）
+- 独立上下文运行，未参与 PRD/原型产出（规避锚定效应）
+- 两阶段检查：Pre-check（Bash 结构化预检，D1/D4 机械化）+ Deep-check（LLM 六维度语义对比，D2/D3/D5/D6 标注为「建议级，误报可被人工推翻」）
+
+**6 维度检查**：
+
+| 维度 | PRD 基准源 | 检查内容 | 严重级别 |
+|------|-----------|---------|---------|
+| D1 页面完整性 | §4 画面原型 | 每个页面是否有对应 HTML + 导航链接 | Critical |
+| D2 功能覆盖 | §7 系统功能清单 | 每个 UI 功能是否有对应交互元素 | Critical |
+| D3 字段一致性 | §8.4 功能模块 | 字段是否在表单中体现 | Important |
+| D4 导航一致性 | §8.2.2 画面交互 | 页面跳转是否与 flow.md 一致 | Important |
+| D5 术语一致性 | §6 业务术语 + CONCEPTS.md | 标签/术语是否一致 | Minor |
+| D6 状态覆盖 | §8.2.3 异常状态 | 空/错误/加载状态是否体现 | Important（**可标 N/A**） |
+
+> **D6 N/A 机制**：自包含 HTML 原型结构性无法体现的状态（如动态加载），允许标 N/A，不阻断。
+
+**判定标准**（柔性化，B7）：
+- **PASS**：Critical=0 且 Important=0
+- **PASS_WITH_WARNINGS**：Critical=0 且 Important>0（警告项交人工裁定，不阻断）
+- **FAIL**：**仅当 Critical>0**（Important 误报不触发 FAIL，避免 D6 等维度误报卡死循环）
+
+**自动评审不能检查的维度**（只能人工评审）：美观度、交互体验、品牌一致性、响应式适配、动效合理性、信息密度、无障碍访问。
+
+## 完成条件
+
+- `prd/vN/prd.md` frontmatter `frozen: true`（frozen_downstream 已设置）
+- 如需原型：`prd/vN/prototype-auto-review.md` 已落盘且 verdict 为 PASS / PASS_WITH_WARNINGS（人工已裁定）
+- `.team-flow/requirements/<req-id>/orchestrator.yaml` 中 S2 状态 = completed，`prd_version` 已记录

package/skills/workflow-orchestrator/references/s3-plan-pipeline.md

@@ -0,0 +1,50 @@
+# S3 计划阶段（v0.7 修订，pipeline 快速路径）
+
+> 调用 ce-plan 产出 `prd/vN/plan.md`，使用 `pipeline_mode: orchestrator` 减少仪式开销。设计依据：设计增强方案 v0.7 §17.2 / §17.5。
+
+## 调用方式
+
+调用 `/ce-plan`，传递：
+- PRD 路径：`prd/vN/prd.md`
+- 原型路径：`prototype/`（如存在）
+- 显式参数：`pipeline_mode: orchestrator`
+
+## 保留 / 跳过清单
+
+ce-plan 在 orchestrator pipeline 上下文中减少仪式开销，但**保留核心价值**：
+
+| 保留（核心价值） | 跳过（仪式开销） |
+|-----------------|-----------------|
+| Phase 1 repo research（代码库侦察） | output format 解析（强制 md） |
+| Phase 3 change splitting + 依赖 DAG | handoff 菜单（Proof/Issue/Browser） |
+| 技术方向决策（一人公司模式） | confidence check 降级为 Lightweight |
+| 风险与约束分析 | ce-doc-review 降级为 headless |
+| 里程碑计划 | 独立调用时的 scoping synthesis 确认 |
+
+## plan.md 聚焦内容
+
+- **Change 拆分方案**：每 change 的 scope + 依赖 + 优先级（C-ID 稳定编号）
+- **Change 间依赖图（DAG）**
+- **整体技术方向**（一人公司模式，避免各 change 各自为政）
+
+## S3 不可取消的理由（调研确认）
+
+1. **Change 拆分无替代源**：PRD 不包含 change 概念，S4 的输入只能来自 ce-plan
+2. **技术方向需全局视角**：避免各 change 的 spec-writer 各自为政
+3. **Repo Research 不可重复**：代码库侦察做一次，不能每个 change 重复 N 次
+
+## 复利
+
+- **注入**：读取 `docs/solutions/INDEX.md`，过滤 `phase = plan OR cross-phase`，取 top-5 摘要
+- **捕获**：检测可复利时刻（技术方向决策、拆分权衡等）
+
+## 反馈环路检查点
+
+- plan 是否暴露了 PRD 的范围问题？
+  - **是** → 回退 S2，触发 PRD vN 内修订（记录变更原因）。详见 feedback-loops.md「S3 → S2」
+  - **否** → 进 S4
+
+## 完成条件
+
+- `prd/vN/plan.md` 已产出，含 change 拆分 + 依赖 DAG + 技术方向
+- `.team-flow/requirements/<req-id>/orchestrator.yaml` 中 S3 状态 = completed

package/skills/workflow-orchestrator/references/s4-split-validate.md

@@ -0,0 +1,108 @@
+# S4 拆分验证与分发（v0.7 重写，v0.17.0 审计必选）
+
+> 原 v0.5「拆分与分发」。v0.7 新增拆分质量审计与并行策略。设计依据：设计增强方案 v0.7 §17.2 / §17.8。
+> v0.17.0 变更：change-split-auditor 审计由隐含步骤升级为「必选门禁」，PASS 前不可创建 change 脚手架。change_dag 字段 `spec_dir` 更名为 `change_dir`，路径修正为 `changes/<change-name>/`。
+
+## 编排层 vs 执行层
+
+| 编排层（orchestrator 自己做） | 执行层（委托） |
+|------------------------------|---------------|
+| 读 plan change 列表 | 拆分质量审计（`change-split-auditor` agent） |
+| verdict 路由 | change 脚手架（`tf change scaffold`，建议新增 CLI） |
+| 告知用户 | — |
+
+## 步骤
+
+### 1. 拆分质量审计（必选门禁，不可跳过）
+
+调用 `change-split-auditor` agent 对 `plan.md` 做拆分质量审计，输出审计报告（覆盖矩阵 / DAG 无环 / 粒度均衡 / 字段完整 / **拆分维度合规**）。质量自检清单：
+
+**必选约束**：审计 verdict = PASS 是 Step 3（创建脚手架）的前置条件。
+verdict = FAIL → 必须回退 S3 调整拆分后重新审计，不可绕过直接创建 change。
+
+- **所有权粒度合规**（v0.9 根因判据，D5 硬门禁）：每个 change 是否对应一个所有权自包含的架构设计单元；是否存在 ≥2 change 瓜分同一聚合/上下文/读模型/契约所有权（切碎 = FAIL）；是否细到无设计单元可识别（FAIL）；是否横跨多个无关节所有权单元（FAIL）
+- **粒度合理性**：太大 → 实施困难；太小 → 管理开销（advisory，不单独 FAIL）
+- **依赖 DAG**：是否有环、关键路径是否过长
+- **并行策略建议**：哪些 change 可并行（同 parallel_group）、哪些必须串行
+- **验收标准预分配**：从 PRD 功能清单映射到每个 change 的 AC（覆盖矩阵）——此映射将在 Step 3.5 落盘到 change-brief.md
+
+### 2. 反馈环路检查点
+
+- 依赖图是否可执行？粒度是否合理？
+  - **否** → 回退 S3 调整拆分策略。详见 feedback-loops.md「S4 → S3」
+  - **是** → 分发
+
+### 3. 创建 change 脚手架
+
+按 plan 中的 change 拆分方案，为每个 change 创建目录并初始化状态文件：
+
+```bash
+mkdir -p changes/<change-name>
+npx --yes --package @xulthekl/team-flow@0.22.4 tf state init changes/<change-name>
+```
+
+> ⚠️ **路径约束**：change 脚手架目录固定为项目根 `changes/<change-name>/`。
+> 不要与 `specs/<cap>/`（change 内部行为规格目录）或 `architecture/`（change 内部架构设计目录）混淆。
+> 不要放入 `.team-flow/`（仅存产品级编排状态）。
+
+> 建议新增 `tf change scaffold` CLI 一次性完成目录创建 + state init + change_dag 写入（确定性脚本，无需 LLM 判断）。（规划中，尚未实现——v0.17.0 时仍用上方手动步骤）
+
+### 3.5 落盘 change-brief.md（v0.9 新增，产品级→变更级交接物）
+
+> **设计意图**：S3/S4 已把每个 change 的 scope、AC、依赖、技术方向定稿，但这些信息此前只活在产品级 `prd/vN/plan.md`，变更层（workflow-start / need-explorer / spec-writer）读不到，导致变更层在 DP-0 重新询问意图、在 need-explorer 重新决策拆分——两层产物断链。本步骤把产品级决策投影到 change 目录内的 `change-brief.md`，作为**上游输入交接物**，让变更层可继承而非重做。
+
+**职责边界（写死）**：auditor 是只读 agent，**只在审计报告里输出 Dim1 覆盖矩阵**；**落盘动作归 orchestrator 自己**（与 Step 4 写 change_dag 同属编排层自做，见上文「编排层 vs 执行层」表）。即：读取 auditor 报告 Dim1 矩阵 → orchestrator 写入 brief 的 AC 段。
+
+为每个已创建脚手架的 change 写 `changes/<change-name>/change-brief.md`（已存在则**覆盖更新**——防 S4→S3 回退调整后 brief 陈旧，呼应 SKILL.md「已建 change 目录保留增量调整」）：
+
+```markdown
+---
+upstream_source: orchestrator          # orchestrator | manual | null
+upstream_req_id: <req-id>              # 对应 .team-flow/requirements/<req-id>/
+upstream_plan_ref: prd/vN/plan.md      # hotfix/快速通道为 null
+upstream_change_id: C2                 # 对应 change_dag.id
+plan_hash: sha256:<plan.md 内容摘要>    # 检测产品层改动后变更层未同步
+---
+# Change Brief: <change-name>
+
+## Scope
+<用户故事/功能模块级 scope 描述，与 plan.md 该 change 的 Scope 一致>
+
+## 约束
+<来自 plan.md 的全局约束 / 该 change 的已知约束>
+
+## AC 列表
+<取自 auditor 报告 Dim1 覆盖矩阵中映射到本 change 的 AC，逐条列出>
+
+## 全局技术方向
+<取自 plan.md 高阶技术设计段的要点指针：模块边界/技术选型/数据流方向，供 spec-writer 作 design.md 约束>
+
+## PRD & plan 引用
+- PRD: prd/vN/prd.md §<相关章节>
+- Plan: prd/vN/plan.md ### <C-ID>
+```
+
+**hash 豁免（重要）**：change-brief.md 放在 change 根目录，**不**属于 team-flow 五产物（proposal/specs/design/tasks/execution-contract），因此天然**不进入 `artifacts_hash`**（`hash.mjs` 只统计前四类）。空 change 的 `artifacts_hash` 仍为 null，状态机的"无产物"判定不受污染——**绝不**让 brief 入 hash。
+
+**双源权威规则**：scope/技术方向以 `prd/vN/plan.md` 为准、AC 以 PRD 功能清单为准；**brief 只是 S4 时刻的投影快照**，不是第二真相源。若变更层发现 brief 与 plan.md 冲突，以 plan.md 为准并触发 Brief drift 提示（见 workflow-start「Staleness Detection」）。
+
+### 4. 写入 change_dag
+
+把每个 change 的 id / change_dir / state_file / depends_on / priority / parallel_group / status 写入 `.team-flow/requirements/<req-id>/orchestrator.yaml` 的 `change_dag`。详见 state-model.md「change_dag 结构」。
+
+### 5. 分发
+
+按依赖顺序建议执行顺序，告知用户各 change 已就绪：
+
+```
+Change C1 已就绪，运行 /workflow-start 进入变更级流程。
+执行顺序建议：C1 → (C2 ∥ C3) → C4（C2/C3 可并行）
+```
+
+## 完成条件
+
+- change-split-auditor 审计 verdict = PASS（必选门禁已通过，含 v0.9 D5 拆分维度合规）
+- 所有 change 目录已创建在项目根 `changes/` 下（非 `specs/` 或 `.team-flow/`），`.team-flow.yaml` 已初始化
+- 每个 change 目录已落盘 `change-brief.md`（v0.9 交接物，含 scope/AC/技术方向/frontmatter）
+- `.team-flow/requirements/<req-id>/orchestrator.yaml` 的 `change_dag` 已填充
+- S4 状态 = completed，已告知用户执行顺序

package/skills/workflow-orchestrator/references/s5-monitoring.md

@@ -0,0 +1,61 @@
+# S5 全局监控（v0.7 修订，多 change 时必选）
+
+> v0.7 变更：change 数量 ≥ 2 时 S5 由「可选」升级为「必选」。设计依据：设计增强方案 v0.7 §17.2 / §17.3 / §17.8 / §17.9。
+
+## 必选条件
+
+- change 数量 = 1 → S5 自然跳过
+- change 数量 ≥ 2 → **S5 必选**
+
+## 编排层 vs 执行层
+
+| 编排层（orchestrator 自己做） | 执行层（委托） |
+|------------------------------|---------------|
+| 读状态文件 | 跨 change 一致性检查（`cross-change-consistency-checker` agent） |
+| 触发时机判断 | 单 change 合并门禁（复用 `code-reviewer` agent） |
+| 冲突处置路由 | 重规划评估（`replan-analyst`，种子提示，只评估不决策） |
+| 用户确认 | — |
+
+## 监控职责
+
+### 1. 进度跟踪
+
+通过各 change 的 `.team-flow.yaml` 状态同步到 `.team-flow/requirements/<req-id>/orchestrator.yaml` 的 `change_dag[].status`。
+
+### 2. 跨 change 一致性检测
+
+调用 `cross-change-consistency-checker` agent（插件 agent，跨 skill 复用价值）检测：
+- 共享聚合/实体的变更是否冲突
+- API 变更是否影响其他 change
+- 原型漂移（change 实现与全局 prototype/ 是否一致）
+
+### 3. 复利晋升
+
+change closing 时检查经验晋升（change 内经验 → 产品级经验）：
+
+```bash
+npx --yes --package @xulthekl/team-flow@0.22.4 tf solutions promote <change-dir>
+```
+
+### 4. 动态重规划触发
+
+S5 是动态重规划的主要触发点。当检测到需要重新拆分（跨 change 冲突）时，触发 S5 → S4 回退。重规划评估流程与红/绿/灰区边界详见 state-model.md「动态重规划」。
+
+## S5 → S4 回退的在途 change 处置（A3）
+
+回退前必须评估在途 change 状态（前置条件分区）：
+
+| 区域 | 条件 | 处置 |
+|------|------|------|
+| **绿区** | 所有 change 未 executing | 可直接回退重新拆分 |
+| **灰区** | 有 change executing | 逐个确认：暂停 / 废弃 / 保持 |
+| **红区** | 已 closing/closed | 只能新 change 修正（hotfix 路径），delta 已合并不可回退 |
+
+在途 change 的处置决策记入 `replan_log`。已 closing/closed 的 change 其 delta 已合并，只能通过新 change 修正。详见 feedback-loops.md「S5 → S4」。
+
+## 完成条件
+
+- 所有 change closed
+- 复利晋升已完成
+- 跨 change 一致性已确认（无未解决冲突）
+- S5 状态 = completed