@boyingliu01/xp-gate 0.7.1 → 0.8.1

package/skills/improve-codebase-architecture/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: improve-codebase-architecture
+description: Find deepening opportunities in a codebase, informed by domain language in CONTEXT.md and decisions in ADRs. Use when user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more AI-navigable. Run periodically (weekly or after surges of development).
+---
+
+# Improve Codebase Architecture
+
+周期性架构健康检查：发现 **shallow module → deep module** 的深度化机会。目标是提升可测试性、AI 可导航性、模块边界清晰度。
+
+与 XP-Gate 质量门禁的分工：
+| 机制 | 时机 | 作用 |
+|------|------|------|
+| **6 道门禁** | 每次 commit | 被动拦截明显问题（函数过长、重复代码等） |
+| **improve-codebase-architecture** | 每周/开发潮后 | 主动深度化改进（seam 识别、模块合并、接口提炼） |
+
+---
+
+## 术语（与 XP-Gate Principles 一致）
+
+| 术语 | 定义 |
+|------|------|
+| **Module** | 任何有接口和实现的东西（函数、类、包、slice） |
+| **Interface** | 调用者使用前必须知道的一切：类型、不变量、错误模式、顺序、配置 |
+| **Implementation** | 接口背后的代码 |
+| **Depth** | 接口的杠杆率：大量行为隐藏在简单接口后。**Deep = 高杠杆**。**Shallow = 接口几乎与实现一样复杂** |
+| **Seam** | 接口所在位置；可以在不修改实现的情况下改变行为的地方 |
+| **Adapter** | 在 seam 处满足接口的具体实现 |
+| **Locality** | 深度带来的可维护性收益：变更、bug、知识集中在一处 |
+
+---
+
+## 核心判断工具
+
+### Deletion Test
+想象删除某个模块：
+- 如果复杂性消失 → 它是 pass-through，不值得保留
+- 如果复杂性在 N 个调用方中重新出现 → **它真正提供了价值**
+- **"Yes, concentrates" = 你想发现的信号**
+
+### The Interface Is the Test Surface
+接口就是测试的边界。如果测试需要深入实现细节，说明接口太浅。
+
+### One Adapter = Hypothetical Seam. Two Adapters = Real Seam.
+只有一个实现满足接口 → 可能过度抽象。两个以上 → 真正的可替换边界。
+
+---
+
+## 流程
+
+### 1. 探索
+
+先读项目的 `CONTEXT.md`（领域语言）和 `docs/adr/`（架构决策）。
+
+然后有机地走查代码库（不要遵循死板启发式），注意你在哪里感受到摩擦：
+
+- 理解一个概念是否需要在多个小文件间跳来跳去？
+- 模块是否 **shallow** — 接口几乎与实现一样复杂？
+- 纯函数是否仅仅为了可测试性而被提取，但真正的 bug 隐藏在调用方式中？（缺乏 **locality**）
+- 紧密耦合的模块是否在其 seams 之处泄漏？
+- 哪些部分难以通过当前接口进行测试？
+
+对任何怀疑 shallow 的模块执行 **Deletion Test**：删除它会让复杂性集中还是分散？"是的，会集中"就是你要的信号。
+
+### 2. 呈现候选项
+
+以编号列表呈现深度化机会。每项包含：
+
+- **Files** — 涉及哪些文件/模块
+- **Problem** — 当前架构为何造成摩擦（使用 CONTEXT.md 中的领域术语）
+- **Solution** — 自然语言描述会怎样改变
+- **Benefits** — 用 locality 和 leverage 解释收益，以及测试会怎样改善
+
+**使用 CONTEXT.md 领域术语。如果与 ADR 冲突**，仅在摩擦值得重新讨论 ADR 时才标注：
+> *"Contradicts ADR-0007 — 但值得重新打开，因为…"*
+
+不要列出 ADR 禁止的每个理论重构。
+
+**此时不要提出接口设计**。先问用户："你想探索哪个候选项？"
+
+### 3. 用户选择候选项
+
+仅当用户明确选择某个候选项时，才进入步骤 4。
+
+### 4. Grilling 循环（设计树遍历）
+
+用户选中某个候选项后，进入 grilling 对话：
+- 遍历约束、依赖、深度化模块的形状
+- seam 背后放什么、什么不放在 seam 背后
+- 哪些测试能在深度化后存活/新增
+
+**对话中的副作用**（决策固化时立即执行）：
+- 命名不在 CONTEXT.md 中的新概念 → **新增到 CONTEXT.md**
+- 模糊术语在对话中变清晰 → **更新 CONTEXT.md**
+- 用户拒绝候选项且有有理由 → **提议记录为 ADR**（避免未来重复建议）
+- 需要探索替代接口 → **按接口设计原则引导**
+
+### 5. 输出（可选）
+
+如果用户在 grilling 后决定执行重构：
+- 生成重构计划（含文件列表、步骤顺序、风险点）
+- 调用 test-driven-development skill 执行重构（保持行为不变）
+
+---
+
+## 与 XP-Gate 集成
+
+### 触发时机
+```
+Phase 5 (FEEDBACK) 后推荐调用：
+  → learn + retro + **improve-codebase-architecture**
+  → 发现架构摩擦 → 记录到 retro → 下一 Sprint 纳入 backlog
+
+或作为独立周期性任务：
+  → /improve-codebase-architecture  → 每周/开发潮后
+```
+
+### 与 ralph-loop 的关系
+架构改进本身可以作为一个独立的 REQ 通过 ralph-loop 执行：
+- REQ: "深度化 Order 模块（从 N 个散文件合并为 deep module）"
+- 通过 test-driven-development 保证行为不变
+
+### 与质量门禁的关系
+架构改进后，质量门禁的 violation 数量应减少：
+- God class → 拆分为 deep modules → SOLID-001 (SRP) 告警消失
+- Deep nesting → 封装为简单接口 → CC-002 告警消失
+- Code duplication → 提取公共 deep module → Gate 2 (Dup Code) 改善
+
+---
+
+## Anti-Patterns
+
+| ❌ 错误 | ✅ 正确 |
+|---------|---------|
+| 仅在文件层面重构（拆分大文件） | 在概念边界处重构（deep module 封装行为） |
+| 为了测试而提取纯函数 | 为了 locality 和组织行为边界而重构 |
+| 过度设计接口（只有一个 adapter） | 发现真实 seam（≥2 adapters 或需要可测试性）后再抽象 |
+| 忽视现有 ADR 提出重构 | 尊重 ADR，仅在摩擦值得重新讨论时标注冲突 |
+| 一次性重构整个模块 | 逐个候选项执行，使用 TDD 保证行为不变 |
+| 与 ADR 冲突但不记录决策 | 记录为 ADR，避免未来重复建议 |
+
+---
+
+## 使用示例
+
+```
+/improve-codebase-architecture
+
+→ Explore: 读取 CONTEXT.md, 走查代码库
+→ 发现 3 个浅模块候选项
+→ 呈现: #1 Order 模块过浅 / #2 Auth 适配器泄漏 / #3 支付领域缺乏 locality
+→ 用户选中 #1
+→ Grilling: 讨论 Order 的 seam 应该在哪
+→ 更新 CONTEXT.md: 新增 "Order Intake" 术语
+→ 提议 ADR: "Order 状态机封装" → 用户同意 → 创建 docs/adr/000X.md
+→ 输出: 重构计划 → TDD 执行
+```

package/skills/sprint-flow/SKILL.md

@@ -178,7 +178,7 @@ Phase 6: SHIP → finishing-a-development-branch (4 选项) → ship (PR 路径)
             → PR 创建完成
 Phase 7: ⚠️ LAND → land-and-deploy → merge PR + wait CI + canary health check
             → deploy verification + auto-rollback on failure
-Phase 8: CLEANUP → git worktree remove + sprint-state.json update → status: merged
+Phase 8: CLEANUP → git worktree remove + branch delete + sprint-state.json update → status: merged
             → Sprint Summary → IF emergent issues → Sprint 2
 ```
 
@@ -512,6 +512,9 @@ Phase 2 第一步必须执行 DELPHI-GATE 检查。没有 delphi-review APPROVED
 **执行时机**: Phase 7 LAND 成功后（或 Phase 6 Option 1 本地 Merge 后）
 
 **动作**:
+0. **保存分支信息**（必须在 worktree remove 之前执行）:
+   - `sprint_branch=$(git branch --show-current)`
+   - 如果 sprint_branch 为空或与 `isolation.branch` 不匹配: 使用 `isolation.branch`
 1. **检测 worktree 是否存在**: `[ -d <worktree_path> ]`
 2. **安全清理**: 
    - **⚠️ 禁止使用通配符或递归 shell 删除命令** — 必须先列出 `isolation.worktree_path` 并确认只清理本 sprint worktree
@@ -519,14 +522,29 @@ Phase 2 第一步必须执行 DELPHI-GATE 检查。没有 delphi-review APPROVED
    - 如果仍失败：输出 `[WARN] Worktree cleanup failed; list the target path and ask the user to clean it manually`
    - ** NEVER delete arbitrary directories** — 只删除本 sprint 创建的 `isolation.worktree_path`
 3. **残留检测**: `[ -d <worktree_path> ]` → 如果仍有残留，输出警告 `[WARN] 检测到残留目录，请手动检查：<worktree_path>`
-4. **更新 `.sprint-state/sprint-state.json`**:
+4. **删除本地和远程分支**（⚠️ 必须在步骤 2 worktree remove 成功后执行）:
+   - 切回主分支: `cd <repo_root> && git checkout main && git pull origin main`
+   - 删除本地分支: `git branch -D <sprint_branch>`
+     - 使用 `-D` 因为 squash merge 后 git 不认为已合并
+     - 如果分支不存在（已被其他流程删除）: 静默跳过
+   - 删除远程分支: `git push origin --delete <sprint_branch>`
+   - 如果远程分支删除失败: 输出 `[WARN] Remote branch cleanup failed, please manually run: git push origin --delete <sprint_branch>`
+5. **关闭遗留 OPEN PR**:
+   - `gh pr list --head <sprint_branch> --state open`
+   - 如果存在 OPEN PR: 关闭并评论说明该 sprint 已通过其他 PR 完成
+6. **更新 `.sprint-state/sprint-state.json`**:
    - `phase: 8`
    - `status: "merged"` 或 `"completed"`
-5. **输出 Cleanup Report + Sprint Summary**
+7. **输出 Cleanup Report + Sprint Summary**
 
-**条件跳过**: `--no-isolate` 路径（无 worktree 可清理）
+**执行顺序依赖**:
+```
+步骤 0 (保存分支名) → 步骤 2 (worktree remove 解除分支文件占用) → 步骤 4 (branch -D 删分支引用 → push --delete 删远程)
+```
+
+**条件跳过**: `--no-isolate` 路径（无 worktree/分支可清理）
 
-**输出**: `[CLEANUP] Worktree removed:` + 残留检测（✅ clean / ⚠️ residual）
+**输出**: `[CLEANUP] Worktree removed + Branch deleted:` + 残留检测（✅ clean / ⚠️ residual）
 
 **IF emergent issues → Sprint 2**
 
@@ -855,7 +873,7 @@ Sprint state is persisted as JSON in `.sprint-state/sprint-state.json`:
 | Phase 5 (FEEDBACK) | `learn` + `retro` | (同) | (同) | (同) |
 | Phase 6 (SHIP) | `finishing-a-development-branch` + `ship` | (同) | + platform deploy (可选) | (同) |
 | Phase 7 (LAND) | `land-and-deploy` + canary | (同) | (同) | (同) |
-| Phase 8 (CLEANUP) | worktree remove + state update | (同) | (同) | (同) |
+| Phase 8 (CLEANUP) | worktree remove + branch delete + state update | (同) | (同) | (同) |
 | Browse | `localhost:3000` | 部署 URL + 表单/交互 | Flutter Web / RN Web 测试 | (专用负载测试) |
 
 **Mobile 专属工具链**:
@@ -1124,7 +1142,7 @@ When ending or pausing, output:
 | 验证失败仍 commit | 验证不通过的代码不 commit |
 | 跳过 Phase 5 FEEDBACK 直接 SHIP | Phase 5 是 HARD-GATE，不可跳过 |
 | --force 在生产分支上运行不确认 | --force 必须等待用户显式确认风险 |
-| Phase 6 SHIP 后不清理 worktree | Phase 8 CLEANUP 必须执行 git worktree remove |
+| Phase 6 SHIP 后不清理 worktree/分支 | Phase 8 CLEANUP 必须执行 worktree remove + branch delete |
 
 ---
 
@@ -1182,7 +1200,7 @@ Sprint-flow orchestrator MUST output phase transition status as valid JSON:
 | 验证失败仍 commit | 验证不通过的代码不 commit |
 | 跳过 Phase 5 FEEDBACK 直接 SHIP | Phase 5 是 HARD-GATE，不可跳过 |
 | --force 在生产分支上运行不确认 | --force 必须等待用户显式确认风险 |
-| Phase 6 SHIP 后不清理 worktree | Phase 8 CLEANUP 必须执行 git worktree remove |
+| Phase 6 SHIP 后不清理 worktree/分支 | Phase 8 CLEANUP 必须执行 worktree remove + branch delete |
 
 ---
 

package/skills/test-driven-development/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: test-driven-development
+description: >
+  Test-Driven Development enforcement: RED → GREEN → REFACTOR cycle.
+  Write failing test first, then minimum code to pass, then refactor.
+  Includes Mock Usage Guidelines for integration-first testing.
+
+maturity: stable
+---
+
+# Test-Driven Development
+
+## Core Principles
+
+| Principle | Description |
+|-----------|-------------|
+| **RED First** | Write a failing test before ANY implementation code |
+| **GREEN Minimum** | Write minimum code to pass the test — no extra features |
+| **REFACTOR** | Clean up code while keeping tests green |
+| **Delete & Restart** | If you write code before test — delete it and start over |
+
+## Workflow
+
+```
+1. RED: Write failing test (describe/it + expect)
+2. GREEN: Write minimum implementation to pass
+3. REFACTOR: Clean up, extract, simplify — tests stay green
+4. Repeat for next behavior
+```
+
+## Mock Usage Guidelines (MANDATORY)
+
+### When to use mocks (ONLY these cases):
+1. External API/HTTP calls — use testcontainers or nock
+2. Database I/O — use in-memory DB (sqlite, testcontainers)
+3. File system I/O — use tmpdir / memfs
+4. Time-dependent code — inject clock dependency
+5. Non-deterministic behavior (random, UUID) — inject dependency
+
+### When NOT to use mocks:
+- Pure business logic → test with real values
+- In-memory data transformations → test with real data
+- Validation logic → test with real input/output
+- State machines → test with real state transitions
+
+### Mock Density Rule:
+If > 30% of test lines contain mock/spy/fn references,
+you are likely over-mocking. Add `// @mock-justified: <reason>` comment
+explaining why integration test is not feasible.
+
+### Annotation Format:
+```typescript
+// @mock-justified: external API wrapper, no sandbox environment available
+```
+Reason text must be at least 10 characters. Bare `@mock-justified` without colon+reason is invalid.
+
+## Test Annotations
+
+```typescript
+/**
+ * @test REQ-XXX Feature name
+ * @intent Verify specific behavior
+ * @covers AC-XXX-01, AC-XXX-02
+ */
+```
+
+## Coverage Requirements
+
+- Minimum 80% line coverage
+- All acceptance criteria must have corresponding tests
+- Tests must survive mutation testing (Gate M pre-push)

package/skills/to-issues/SKILL.md

@@ -0,0 +1,277 @@
+---
+name: to-issues
+description: Break a plan, spec, or PRD into independently-grabbable issues using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into vertical slices. Integrates with XP-Gate sprint-flow Phase 1.
+---
+
+# To Issues — Vertical Slice Breakdown
+
+将 PRD / specification.yaml / 设计文档拆解为 **独立的垂直切片 Issue**，每个切片是贯穿所有层的 **tracer bullet**，而非水平分层切片。
+
+核心理念：每个 Issue 交付一条**狭窄但完整**的端到端路径（schema → API → UI → tests），完成后即可独立演示并通过质量门禁。
+
+---
+
+## 术语（强制一致使用）
+
+| 术语 | 定义 |
+|------|------|
+| **Vertical Slice** | 贯穿所有层（数据、API、UI、测试）的薄路径，交付端到端行为 |
+| **Tracer Bullet** | 第一条完整的垂直切片，优先拆解以快速暴露 unknown unknowns |
+| **HITL** | Human-In-The-Loop — 需要人工决策（架构选择、设计评审）才能继续 |
+| **AFK** | Away-From-Keyboard — 可完全由 agent 自主实现并合并 |
+| **Blocking** | 依赖关系：此切片必须在哪些切片完成后才能开始 |
+| **Deep Module** | 封装大量功能于简单接口背后的模块（XP-Gate Principles 概念） |
+
+---
+
+## 输入
+
+- PRD 文件路径，或
+- `specification.yaml`，或
+- 最近对话中的设计文档（项目配置的 spec 路径，默认 `docs/superpowers/specs/*.md`）
+
+## 输出（Machine-Readable）
+
+### 1. 文本输出
+
+- 一组垂直切片 Issue（GitHub Issue / 本地 `.issues/*.md` / 用户指定的 issue tracker 格式）
+- 依赖关系图（拓扑排序后的执行顺序）
+
+### 2. JSON Output Contract（供 ralph-loop / sprint-flow 下游消费）
+
+写入 `.sprint-state/slices-manifest.json`：
+
+```json
+{
+  "version": 1,
+  "source": "specification.yaml 或 spec 文件路径",
+  "slices": [
+    {
+      "id": "slice-N",
+      "title": "一句话描述端到端行为",
+      "type": "HITL | AFK",
+      "blocked_by": ["slice-M"] | [],
+      "parent_story": "User Story 编号",
+      "what_it_delivers": "端到端行为描述",
+      "acceptance_criteria": ["标准1", "标准2", "标准3"],
+      "effort": "S | M | L",
+      "loc_budget": 200,
+      "file_budget": 20,
+      "status": "pending"
+    }
+  ],
+  "execution_order": ["slice-1", "slice-2", "slice-3"],
+  "dependency_graph": {
+    "slice-1": [],
+    "slice-2": ["slice-1"],
+    "slice-3": ["slice-1"]
+  }
+}
+```
+
+---
+
+## 流程
+
+### 1. 收集上下文
+
+从当前对话或输入的 PRD/spec 中提取：
+- 需求列表 / User Stories
+- 系统模块 / 架构设计
+- 技术约束（语言、框架、数据库）
+
+如果输入中包含 CONTEXT.md 或 ADRs，读取并尊重其中的领域术语和架构决策。
+
+**PRD 完整性检查（降级规则）**：
+```
+IF PRD 缺少关键内容：
+  - 缺少数据模型 / schema 定义 → 标注所有数据相关切片为 HITL
+  - 缺少 API 契约 → 标注所有 API 相关切片为 HITL
+  - 缺少 UI 设计 / 交互说明 → 标注所有 UI 相关切片为 HITL
+  - 缺少验收标准 → 标注整体验证切片为 HITL
+```
+
+### 2. 探索代码库
+
+**Brownfield 项目（已存在代码）— 必须执行**：
+- 读取 AGENTS.md CODE MAP + 目录结构
+- 检查已有模块边界、路由定义、DB 模式
+- 确认测试覆盖现状
+
+**Greenfield 项目（新项目）— 可选**：
+- 若为全新项目，跳过此步骤
+- 建议采用 schema-first 切片顺序（先 DB schema → 再 API → 再 UI）
+
+### 3. 起草垂直切片
+
+将需求拆解为 **tracer bullet** 切片。规则：
+
+- 每个切片交付**一条狭窄但完整**的端到端路径
+- **优先 unknown unknowns**：优先拆解能快速暴露不确定因素的切片
+- **切片必须可独立演示并完整通过 6 道质量门禁**（Code Quality + Dup Code + Complexity + Principles + Tests + Architecture）
+- **标注依赖**：明确哪些切片阻塞哪些切片
+- **识别 Deep Module 机会**：拆解时主动提出可封装为 deep module 的模块边界
+
+**范围控制（硬上限）**：
+| 约束 | 阈值 | 超限处理 |
+|------|------|---------|
+| 切片总数 | ≤15 / 功能模块 | 超过 → 按 epic 分组，组内拓扑排序 |
+| 单切片变更量 | ≤200 LOC 或 ≤20 文件 | 超过 → 拆分为子切片 |
+| 单切片工作量 | ≤4h 开发时间 | 超过 → 拆分为子切片 |
+
+### 4. HITL / AFK 分类
+
+**判定规则**（满足任一条件即为对应类型）：
+
+```
+HITL 条件：
+  - 涉及架构决策（数据库选型、API 风格、auth 方案）
+  - 涉及 UI/UX 设计选择（布局、交互、品牌色）
+  - 涉及第三方服务集成选型（支付、短信、OAuth provider）
+  - PRD 降级规则触发（见步骤 1）
+
+AFK 条件（必须同时满足全部）：
+  - 纯实现、遵循项目中已有模式（如已有 adapter 的 CRUD）
+  - 接口契约已在 spec/PRD 中明确定义
+  - 无新增外部依赖（第三方 API、新库引入）
+  - 测试策略可复用已有测试适配器
+
+否则 → HITL（保守默认）
+```
+
+**HITL → AFK 状态机**：
+```
+HITL (创建) → 人工确认 (ADRs / 设计决策产出) → 标记为 AFK-ready → AFK (agent 执行)
+                                                                   ↓
+                                         AFK 执行遇到未预见依赖 → 回退 HITL → BLOCKED
+```
+
+### 5. 依赖验证
+
+在发布前执行以下检查：
+
+```
+1. 构建依赖图 (DAG)
+2. 检测循环依赖 (A→B→C→A) → 报错并要求重新拆分
+3. 拓扑排序 → 生成 execution_order
+4. 检查每个切片的 blocked_by 引用是否存在
+5. 验证第一个切片（tracer bullet）无阻塞
+```
+
+**跨切面关注点处理**：
+Auth、logging、error handling、i18n 等贯穿所有切层的关注点：
+- **首选**：在第一条 tracer bullet（通常是 slice-1）中内置这些横切关注点的基础设施
+- **次选**：作为独立的前置 AFK 切片（如 "slice-0: 基础设施骨架"）
+- 不要将这些关注点分散到每个切片中 — 会导致重复实现和不一致
+
+### 6. 向用户确认
+
+以编号列表呈现拆解结果。每个切片包含：
+
+```
+### Slice N: [简短标题]
+- **Type**: HITL / AFK
+- **Effort**: S(~1h) / M(~2h) / L(~4h)
+- **Blocked by**: Slice M / None
+- **Parent Story**: User Story 编号
+- **LOC Budget**: ~N 行
+- **What it delivers**: 一句话描述端到端行为
+- **Acceptance Criteria**: 1-3 条可验证行为
+```
+
+询问用户：
+1. 粒度是否合适？（太粗 / 太细 / 正好）
+2. 依赖关系是否正确？
+3. 是否有切片应该合并或拆分？
+4. HITL/AFK 标注是否准确？
+
+**最多 2 轮迭代**。超过 2 轮未决则强制收敛：
+- 第一轮：完整列表展示
+- 后续轮次：仅展示变更部分（Diff 视图：新增 / 合并 / 拆分项对比）
+
+### 7. 发布切片
+
+用户批准后，生成切片 Issue 并写入 `slices-manifest.json`。
+
+**GitHub Issue 格式**:
+```markdown
+## Parent
+[父 issue 编号或 PRD 链接]
+
+## Slice ID
+slice-N
+
+## What to build
+[端到端行为描述，非逐层实现描述]
+
+## Acceptance criteria
+- [ ] 标准 1（端到端行为可验证）
+- [ ] 标准 2
+- [ ] 标准 3
+
+## Technical Notes
+[可选：接口设计、schema 变更、架构决策]
+
+## Blocked by
+[#N - 阻塞 issue 编号 / None — 可以立即开始]
+
+## Type / Effort
+[HITL | AFK] / [S | M | L]
+
+## Gate-Compliant DoD ⚠️
+此切片完成后必须通过全部 6 道质量门禁：
+- [ ] Gate 1: Code Quality (lint 无错误)
+- [ ] Gate 2: Dup Code (≤5% 相似度)
+- [ ] Gate 3: Complexity (≤5 警告)
+- [ ] Gate 4: Principles (Clean Code + SOLID 零错误)
+- [ ] Gate 5: Tests (全部通过 + ≥80% 覆盖率)
+- [ ] Gate 6: Architecture (无新增警告 + 童子军规则)
+```
+
+**按拓扑排序顺序发布**：先发布无阻塞的切片，再发布被阻塞的切片。
+
+---
+
+## 与 XP-Gate Sprint Flow 集成
+
+完整 7 阶段流程中 to-issues 的位置及切片在各阶段的生命周期：
+
+```
+Phase 0: THINK    → brainstorming → 设计文档 → APPROVED
+Phase 1: PLAN     → autoplan → delphi-review → specification.yaml
+                  → **/to-issues** → slices-manifest.json + Issue 列表
+Phase 2: BUILD    → 按 execution_order 逐个切片执行
+                  → 每个切片 = 一个 REQ（ralph-loop 模式）
+                  → 或通过 dispatching-parallel-agents 并行（无依赖的 AFK 切片）
+Phase 3: REVIEW   → **整体 review**（全部切片完成后统一 code-walkthrough）
+                  → browse / QA 验证端到端行为
+Phase 4: USER ACC → 人工验收（全部切片集成后的完整功能）
+Phase 5: FEEDBACK → learn + retro（按切片统计通过率/返工率）
+Phase 6: SHIP     → 全部切片合并后一次性 merge（或按 epic 分批 merge）
+```
+
+**切片与 REQ 的映射**（ralph-loop 模式）：
+```
+每个切片 → 生成一个 REQ 实例：
+  REQ-N:
+    - source_slice: slice-N
+    - input: slices-manifest.json 中对应切片的 acceptance_criteria
+    - constraints: LOC_budget, file_budget, type (HITL/AFK)
+    - output: 通过 6 gates 的增量 diff
+    - verification: test-specification-alignment + gate verification
+```
+
+---
+
+## Anti-Patterns
+
+| ❌ 错误 | ✅ 正确 |
+|---------|---------|
+| 按技术层拆分（"先做 DB"、"再做 API"、"最后做 UI"） | 按端到端行为拆分（"用户可以通过邮箱注册"） |
+| 伪装成垂直切片的水平拆分（标题是用户故事，执行时仍分层） | 每个切片的 acceptance criteria 必须包含全层验证 |
+| 切片完成后无法独立演示 | 每个切片必须可验证 + 通过 6 道质量门禁 |
+| 一个切片包含过多用户故事（>2 个） | 一个切片聚焦 1-2 个用户故事 |
+| 忽略或随意标注依赖关系 | 拓扑排序验证 + 循环检测 |
+| HITL 切片被当作 AFK 执行 | 人工输出 ADR/决策后 → 标记 AFK-ready → 执行 |
+| 切片标题模糊（"实现功能X"） | 切片标题描述行为（"用户可通过邮箱注册账号"） |
+| 切片超出 200 LOC / 20 文件 / 4h 预算 | 拆分为子切片 |

package/skills/delphi-review/evals/evals.json

@@ -1,82 +0,0 @@
-{
-  "skill_name": "delphi-review",
-  "skill_path": "skills/delphi-review/SKILL.md",
-  "evals": [
-    {
-      "id": 1,
-      "name": "design-mode-full-review",
-      "category": "normal",
-      "prompt": "我需要评审一份设计文档：我们要给XP-Gate项目添加一个自动生成CHANGELOG的功能。功能包括：1) 从git log提取commit信息 2) 按照conventional commits分类 3) 生成markdown格式的changelog 4) 支持自定义模板。请用delphi-review评审这个设计。",
-      "expected_output": "执行完整的Delphi评审流程：Phase 0验证→Round 1匿名独立评审(至少2位Expert)→Round 2交换意见→共识检查(>=95%)→Terminal State Checklist→如果APPROVED则生成specification.yaml。绝不能只做Round 1就停止。",
-      "files": [],
-      "assertions": [
-        {"name": "round-1-executed", "type": "contains", "value": "Round 1"},
-        {"name": "round-2-executed", "type": "contains", "value": "Round 2"},
-        {"name": "consensus-check", "type": "contains", "value": "95%"},
-        {"name": "terminal-state-checklist", "type": "contains", "value": "Terminal State"},
-        {"name": "expert-a-present", "type": "contains", "value": "Expert A"},
-        {"name": "expert-b-present", "type": "contains", "value": "Expert B"},
-        {"name": "anonymity-mentioned", "type": "contains", "value": "匿名"},
-        {"name": "verdict-present", "type": "regex", "value": "(APPROVED|REQUEST_CHANGES|REJECTED)"}
-      ]
-    },
-    {
-      "id": 2,
-      "name": "design-mode-flawed-document",
-      "category": "boundary",
-      "prompt": "请评审以下架构决策：我们打算用单个SQLite文件存储所有用户数据、日志、审计记录和缓存。这样部署简单，只需要一个文件。请用delphi-review评审。",
-      "expected_output": "Expert应该识别出这个设计的严重问题（单文件SQLite不适合多用途、缺乏扩展性、并发问题等），给出REQUEST_CHANGES而非盲目APPROVED。仍需执行完整多轮流程。",
-      "files": [],
-      "assertions": [
-        {"name": "round-1-executed", "type": "contains", "value": "Round 1"},
-        {"name": "critical-issues-found", "type": "contains", "value": "Critical"},
-        {"name": "verdict-not-blind-approved", "type": "contains", "value": "REQUEST_CHANGES"}
-      ]
-    },
-    {
-      "id": 3,
-      "name": "code-walkthrough-mode",
-      "category": "normal",
-      "prompt": "我修改了几个文件准备push，需要做代码走查。变更包括：1) 新增了boy-scout.ts的calculateDelta函数 2) 修改了baseline.ts的loadBaseline函数 3) 添加了3个新的clean-code规则。请用code-walkthrough模式评审。",
-      "expected_output": "执行code-walkthrough模式：运行Principles Checker→Expert A架构评审(含principles_findings)→Expert B实现评审(含principles_findings)→共识检查→写入.code-walkthrough-result.json文件。",
-      "files": [],
-      "assertions": [
-        {"name": "code-walkthrough-mode", "type": "contains", "value": "code-walkthrough"},
-        {"name": "principles-findings", "type": "contains", "value": "Principles Findings"},
-        {"name": "expert-a-review", "type": "contains", "value": "Expert A"},
-        {"name": "expert-b-review", "type": "contains", "value": "Expert B"},
-        {"name": "result-file-generated", "type": "contains", "value": ".code-walkthrough-result.json"},
-        {"name": "consensus-check", "type": "contains", "value": "共识"}
-      ]
-    },
-    {
-      "id": 4,
-      "name": "zero-tolerance-enforcement",
-      "category": "boundary",
-      "prompt": "评审时发现了一个Critical Issue，但我觉得这个问题不大，可以忽略。评审还需要继续吗？",
-      "expected_output": "必须坚持零容忍原则：Critical Issues不可忽略，必须修复后重新评审。不能因为用户认为问题不大就跳过。应明确告知零容忍原则并拒绝跳过。",
-      "files": [],
-      "assertions": [
-        {"name": "zero-tolerance-enforced", "type": "contains", "value": "零容忍"},
-        {"name": "critical-not-skippable", "type": "not_contains", "value": "可以忽略"},
-        {"name": "requires-fix", "type": "contains", "value": "修复"}
-      ]
-    }
-  ],
-  "trigger_evals": {
-    "should_trigger": [
-      "我需要多个专家来评审这个架构设计",
-      "评审这份需求文档，确保没有遗漏",
-      "设计评审：我们的微服务拆分方案",
-      "代码走查，准备push了",
-      "delphi review this design doc"
-    ],
-    "should_not_trigger": [
-      "帮我写一个单元测试",
-      "这段代码有bug，帮我修一下",
-      "创建一个新的React组件",
-      "部署到生产环境",
-      "解释一下这个函数的作用"
-    ]
-  }
-}