Menü
工程实现主力：管理 ENGINEERING.md，完整/轻量两模式；worktree 会话隔离、分级 TDD、验证门（证据先于断言）、任务原子化 Wave 并行、独立 commit。 触发方式：用户说"工程"、"实现"、"forge-eng"，或 forge-dev 调度、需要实现代码变更时。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Forge 工作流总入口。只读检测项目状态，推荐下一步该用哪个 skill，自己不干活。触发方式：用户说"forge"、"下一步"、"接下来做什么"。
复盘 v3（Workbench 门禁型）：启动本地 Workbench，用户在独立会话页确认想学的知识点和深度，按选择调研产出复盘文档； 同时落 2-3 条账本条目（记录/复盘/learnings.jsonl）供 bugfix/eng 开工回放与复发检测。 触发方式：用户说"总结知识"、"学习总结"、"复盘"、"可视化复盘"、"/forge-fupan"。
通用头脑风暴：4 种模式（产品/内容/构建/探索）× 6 阶段，强制前提挑战和 2-3 方案，产出可跨会话续聊的思考文档；支持 Mermaid/图辅助判断。 触发方式：用户说"头脑风暴"、"brainstorm"、"讨论一下"、"我有个想法"、"帮我想想"、"画图梳理想法"。
设计实现：把 DESIGN.md 转成代码，只改样式不改逻辑；CSS 优先、Token 驱动、反 AI 模板、原子提交，以真实截图和 CSS 断言验证。 触发方式：用户说"实现设计"、"forge-design-impl"、设计文档确认后需要写代码时。
全栈设计规划：分级门控管理 DESIGN.md 与 DESIGN-CHANGELOG，内置可检索设计规则库（UX 规则/配色/字体），三层 Token、Image 2 视觉稿门禁、反 AI 模板检测。 触发方式：用户说"设计"、"forge-design"、"先看效果图"，或 forge-dev 调度、需要创建/更新设计文档时。
文档落地治理规范。统一管理 docs/ 目录下文档的写时约束、读时索引、生命周期标记。提供当前真相源白名单（doc-paths.md）+ frontmatter schema + 新项目一键脚手架（init-project.sh，已就绪）。所有 forge-* skill 的文档落地路径以本 skill 的 doc-paths.md 为准。触发方式：用户说"文档治理"、"文档放哪"、"docs 目录乱了"、"forge-doc-policy"、AI 准备创建任意 .md 或新目录前的自查。
| name | forge-eng |
| description | 工程实现主力：管理 ENGINEERING.md，完整/轻量两模式；worktree 会话隔离、分级 TDD、验证门（证据先于断言）、任务原子化 Wave 并行、独立 commit。 触发方式：用户说"工程"、"实现"、"forge-eng"，或 forge-dev 调度、需要实现代码变更时。 |
文档落地路径：遵循 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。
管理项目的 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。
{项目目录}/docs/PRD.md{项目目录}/docs/DESIGN.md{项目目录}/docs/*RESEARCH*（如果 forge-dev 产出了调研报告）.forge/visual-decision.md；legacy 项目才兼容旧 .deliver/ / .do-dev/ 或旧 docs/讨论/*/assets/*.meta.json搜索模式：
- {项目目录}/docs/ENGINEERING.md
- {项目目录}/docs/*engineering*（不区分大小写）
- {项目目录}/docs/*工程*
- {项目目录}/**/ENGINEERING*.md
*engineering*changelog*根据项目状态自动判断，或通过 AskUserQuestion 确认：
检查是否有 PRD + ENGINEERING.md
├── 有 → 默认完整模式
└── 无 → 提议选择：
A) 完整模式 — 创建工程文档，走完整流程（适合正式项目）
B) 轻量模式 — 跳过文档管理，只做：
Worktree 隔离 → 任务拆分 → TDD/验证驱动 → 原子提交 → 收尾
（适合小 demo、POC、快速实验）
轻量模式保留的能力：Worktree 隔离、任务拆分、TDD/验证驱动、原子 commit、分支收尾。 轻量模式跳过的内容：ENGINEERING.md 管理、四章审查、CHANGELOG、.features/ 状态管理。
如果选择轻量模式：跳转到第 5.5 步（创建 Worktree）。
在设计任何方案之前，先回答这些问题：
TODOS.md（如果存在）。有没有推迟项在阻塞此方案？有没有推迟项可以顺带做了？完整度检查：方案是在做完整版还是捷径版？用 AI 辅助，"完整"比人工便宜 100 倍。如果方案选择了捷径而只省了几分钟，推荐做完整版。
如果复杂度检查触发（8+ 文件或 2+ 新类/服务）：通过 AskUserQuestion 主动建议缩减范围。
docs/README.md、docs/INDEX.md 和 docs/ENGINEERING.md 当前真相源。docs/PRD.md、docs/DESIGN.md 的相关章节，提取产品和设计约束。docs/modules/*.md 或 docs/ops/*.md。docs/CHANGELOG.md 顶部索引和 ENGINEERING-CHANGELOG.md 相关段落，不默认扫全文。grep 本项目名或 global ~/claudecode_workspace/记录/复盘/learnings.jsonl，挑 status=active、置信度 ≥7、与本次任务相关的条目（≤5 条）向用户一行复述；无账本则跳过深度阅读项目代码（Explore 扫描结构、核心源码、schema、git log），然后与用户分 5 轮确认： 架构概览 → 技术栈 → 模块划分 → 数据流 → 已知技术债。逐节确认后产出 ENGINEERING.md 初稿并新建 ENGINEERING CHANGELOG。 逐轮确认细则与文档模板见 references/engineering-template.md「从零创建流程」节。
章节顺序：架构 → 代码质量 → 测试 → 性能。每章结束停止，发现的问题按 interaction-protocol 的批量策略（≤3 个逐个问，>3 个同类批量一次问）通过 AskUserQuestion 确认后，才进入下一章：
/forge-qa 使用逐章评估细则见 references/engineering-template.md「四章工程审查细则」节。
对每个变更点，通过 AskUserQuestion 确认：
追加本次变更记录：时间、背景、技术方案、关键决策。
核心原则：不在主工作目录写代码，创建隔离副本。每个 forge-eng 会话一个 worktree（.worktrees/{feature-slug} + 分支 eng/{feature-slug}-{日期}），多会话互不冲突。
流程摘要：检查/创建 .worktrees → .gitignore 安全检查 → git worktree add 建分支 → 自动检测项目类型安装依赖 → 基线测试（失败须报告数量并询问是否继续；无测试框架则跳过）→ 按模板报告就绪（含 APP_URL，来自 dev:status，不得猜端口）。
完整命令、基线测试处理表、报告模板见 references/worktree-guide.md「创建流程」节。
后续所有 Wave 执行都在 worktree 目录中进行。
worktree 建好后：① 若项目需要运行应用 → 遵守项目统一 dev entrypoint 和端口契约， 禁止自起野端口；② 若测试框架缺失 → 检测并引导初始化。 执行前必读 references/dev-environment.md。
方案确认后进入实现。执行前必读 references/wave-execution.md，其中：
骨架红线：三条铁律见文首（TDD 分级：严格/轻量/验证驱动，按任务风险选）；另加一条——每个原子任务一个独立 commit，不打包不相关变更。
每项审查中考虑但明确推迟的工作，附一句话原因。
已有的代码/流程，以及方案是复用了它们还是重复建设。
对每个新代码路径，列出一种现实中可能的失败方式，并说明：
无测试 + 无错误处理 + 静默失败 = 严重缺口，需要标红。
潜在 TODO 按 interaction-protocol 的批量策略提问：≤3 个逐个确认，>3 个同类整理后一次批量确认。
按「交付总结模板」输出 ASCII 汇总框，须覆盖：项目/版本/模式/Worktree、范围挑战与四章审查结果（完整模式）、 任务拆分与 TDD 级别分布、各 Wave 执行结果、原子提交数、Verification Gate 通过/重试次数、代码变更规模、 ENGINEERING.md 与 CHANGELOG 更新状态。模板见 references/wave-execution.md「交付总结模板」节。
如果用户未回答某个 AskUserQuestion，列出"未解决的决策——可能在后续咬你一口"。
所有任务完成且验证通过后，处理 worktree 和分支。
通过 AskUserQuestion 展示选项：
实现完成。如何处理分支？
1. 合并回主分支 — merge 到 main，跑测试验证合并结果，通过后删除分支和 worktree
2. 推送并创建 PR — push + gh pr create，清理 worktree（分支保留在远端）
3. 保留分支 — 不做任何清理，报告路径和分支名
4. 丢弃 — 删除分支和 worktree，必须二次确认（展示将删除的提交列表）
具体命令见 references/worktree-guide.md 的「分支收尾」节。
状态标记与通用操作规则见 ~/.claude/skills/_shared/feature-status-protocol.md。
eng 特有动作：
[✅ 已完成] 后才启动下一 Wave