Menu
上线前 PR 审查。分析当前分支与基础分支的 diff，检查 SQL 安全、竞态条件、 LLM 信任边界、枚举完整性等测试捕获不到的结构性问题。发现问题直接修复。 触发方式：用户说"review"、"审查代码"、"上线前检查"、"forge-review"，或 forge-dev --full 调度。 与内置 code-review/verify 的分工：forge 工作流内的上线前结构性审查用本 skill；用户点名 /code-review 或 /verify 时用对应内置 skill。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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-review |
| description | 上线前 PR 审查。分析当前分支与基础分支的 diff，检查 SQL 安全、竞态条件、 LLM 信任边界、枚举完整性等测试捕获不到的结构性问题。发现问题直接修复。 触发方式：用户说"review"、"审查代码"、"上线前检查"、"forge-review"，或 forge-dev --full 调度。 与内置 code-review/verify 的分工：forge 工作流内的上线前结构性审查用本 skill；用户点名 /code-review 或 /verify 时用对应内置 skill。 |
| allowed-tools | ["Bash","Read","Edit","Write","Grep","Glob","AskUserQuestion"] |
文档落地路径：遵循 forge-doc-policy 规范。完整白名单 + frontmatter schema 见
~/.claude/skills/forge-doc-policy/doc-paths.md。 当前文档加载顺序：需要判断需求/设计/工程口径时，先读项目CLAUDE.md、docs/README.md、docs/INDEX.md和相关根级当前真相源；历史 archive 只作追溯证据。 详细规则见~/.claude/skills/_shared/current-doc-loading.md。
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "当前分支: $_BRANCH"
提问格式与批量策略见
~/.claude/skills/_shared/interaction-protocol.md。
按顺序判断此 PR 合并到哪个分支：
# 1. 检查是否已有 PR
gh pr view --json baseRefName -q .baseRefName 2>/dev/null
# 2. 没有 PR 则获取仓库默认分支
gh repo view --json defaultBranchRef -q .defaultBranchRef.name 2>/dev/null
# 3. 都失败则回退到 main
打印出基础分支名称，后续所有 git diff、git fetch、git merge 等命令中用实际分支名替换"基础分支"。
git branch --show-current
git fetch origin <基础分支> --quiet && git diff origin/<基础分支> --stat
如果在基础分支上，或没有 diff，输出："没有可审查的内容——你在基础分支上或没有变更。" 并停止。
git fetch origin <基础分支> --quiet
git diff origin/<基础分支>
在评论之前先读完完整 diff。 不要标记 diff 中已经修复的问题。
逐项检查以下类别，对每个 diff 文件详细分析：
检查：
WHERE 条件？（全表操作风险）报告格式：[严重] 文件:行号 — 问题描述 → 修复建议
检查：
特别注意：状态转换（如 draft → published）必须用数据库级约束，不能只依赖应用层检查。
检查：
检查：
重要：枚举完整性必须读取 diff 以外的代码。当 diff 新增了枚举值，用 Grep 找出所有引用了同级值的文件，Read 这些文件检查新值是否被处理。
检查：
if 语句的所有分支中都正确处理？检查：
100、1000）是否有注释说明含义？检查：
检查：
检查：
dangerouslySetInnerHTML 或 v-html 使用了未清洗的数据？每个发现都要有行动——不只是报告。
输出摘要头：上线前审查：N 个问题（X 严重，Y 信息性）
机械性、无争议的修复直接应用。每个输出：
[已自动修复] 文件:行号 — 问题 → 修复内容
适合自动修复的典型问题：
outline: none / !important需要判断或有真实权衡的问题，批量放入一次 AskUserQuestion（≤3个时可单独提问）：
我已自动修复了 5 个问题。2 个需要你的判断：
1. [严重] app/models/order.rb:42 — 状态转换竞态条件
修复：在 UPDATE 中添加 WHERE status = 'pending'
→ A) 按建议修复 B) 跳过
2. [信息性] app/services/ai_writer.rb:88 — AI 输出未经类型验证就写入数据库
修复：添加 JSON Schema 验证
→ A) 按建议修复 B) 跳过
推荐：两个都修——#1是真实竞态，#2防止静默数据损坏。
读取仓库根目录的 TODO.md 或 TODOS.md（如果存在）：
对比 diff 与根目录下的文档文件（README.md、ARCHITECTURE.md、CLAUDE.md 等）：
/forge-ship 后更新文档。"/forge-ship 的工作。