forge-eng

文档落地路径：遵循 forge-doc-policy 规范。完整白名单 + frontmatter schema 见 ~/.claude/skills/forge-doc-policy/doc-paths.md。 当前文档加载契约：先读项目 CLAUDE.md、docs/README.md、docs/INDEX.md 和 docs/ENGINEERING.md 当前真相源；PRD/DESIGN 只读相关章节，长 changelog 和 raw archive 只在追溯历史原因时加载。详见 ~/.claude/skills/_shared/current-doc-loading.md。

/forge-eng：工程文档管理与代码实现 v2

管理项目的 ENGINEERING.md（前后端合并），基于 PRD + DESIGN.md 产出工程方案并实现。 集成 Worktree 隔离、分级 TDD、Verification Gate。

流程总览

完整模式：
  第0步 定位文档 → 第0.5步 模式选择 → 第1步 范围挑战 → 第2步 理解现状
  → 第3步 四章审查 → 第4步 方案设计 → 第5步 更新文档
  → 第5.5步 创建Worktree → 第5.6步 Dev Server 端口契约 → 第5.7步 测试框架检测
  → 第6步 任务拆分(含TDD级别) → 第7步 Wave执行(TDD+Verification)
  → 第8步 必需产出 → 第9步 确认总结 → 第10步 分支收尾

轻量模式：
  第0步 定位文档 → 第0.5步 模式选择
  → 第5.5步 创建Worktree → 第5.6步 Dev Server 端口契约 → 第5.7步 测试框架检测
  → 第6步 任务拆分(含TDD级别) → 第7步 Wave执行(TDD+Verification)
  → 第9步 确认总结 → 第10步 分支收尾

全程中文。关键技术决策需用户确认后再实现。

提问格式与批量策略见 ~/.claude/skills/_shared/interaction-protocol.md。

工程原则

• 完整优先：当完整方案只比捷径多几分钟时，永远推荐完整方案（AI 辅助下"做完整"的边际成本接近零）。
• 结构与行为分离：先重构让修改变简单，再做简单的修改；不同时改结构和行为。
• 可逆性偏好：优先选择能低成本回退的实现方式（功能开关、灰度、增量替换）。

三条铁律（来自 Superpowers，不可违反）

1. 不先验证就不准声称完成 — 必须运行验证命令、读取完整输出、确认 exit code 后才能 commit 或声称成功。禁用"should work"、"probably fixed"等措辞。详见 references/verification-checklist.md。
2. 不先写失败测试就不准写实现（严格 TDD 级别适用）— 写了实现再补测试？删掉实现，从测试重新开始。详见 references/tdd-guide.md。
3. 3 次修复失败就质疑架构 — 不要尝试第 4 次修复，停下来和用户讨论设计方案是否有根本问题。

---

第0步：定位项目文档

1. 定位 PRD：搜索 {项目目录}/docs/PRD.md
2. 定位 DESIGN.md：搜索 {项目目录}/docs/DESIGN.md
3. 定位 RESEARCH.md：搜索 {项目目录}/docs/*RESEARCH*（如果 forge-dev 产出了调研报告）
4. 定位视觉决策索引（如有）：优先搜索 .forge/visual-decision.md；legacy 项目才兼容旧 .deliver/ / .do-dev/ 或旧 docs/讨论/*/assets/*.meta.json
5. 定位 ENGINEERING.md：

   搜索模式：
   - {项目目录}/docs/ENGINEERING.md
   - {项目目录}/docs/*engineering*（不区分大小写）
   - {项目目录}/docs/*工程*
   - {项目目录}/**/ENGINEERING*.md
   

6. 定位 ENGINEERING CHANGELOG：模式匹配 *engineering*changelog*
7. 分支判断：有 → 迭代模式；无 → 创建模式