Forge 工作流总入口。只读检测项目状态，推荐下一步该用哪个 skill，自己不干活。触发方式：用户说"forge"、"下一步"、"接下来做什么"。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
不知道下一步该干什么？打 /forge。
全程中文。
_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
echo "项目根目录: $_ROOT"
# 检测文档状态
echo "--- 文档状态 ---"
[ -f "$_ROOT/docs/README.md" ] && echo "[DOCS] 发现 docs/README.md"
[ -f "$_ROOT/docs/INDEX.md" ] && echo "[DOCS] 发现 docs/INDEX.md"
[ -f "$_ROOT/docs/CHANGELOG.md" ] && echo "[DOCS] 发现历史总账"
[ -f "$_ROOT/docs/modules/doc-system.md" ] && echo "[DOCS] 发现项目文档系统说明"
[ -f "$_ROOT/.features/_registry.md" ] && echo "[FEATURES] 发现 Feature 注册表" && sed -n '1,80p' "$_ROOT/.features/_registry.md"
ls "$_ROOT"/brainstorm-*.md 2>/dev/null && echo "[BRAINSTORM] 发现思考文档（根目录）"
ls "$_ROOT"/docs/brainstorm-*.md 2>/dev/null && echo "[BRAINSTORM] 发现思考文档（docs/）"
[ -f "$_ROOT/docs/PRD.md" ] && echo "[PRD] 发现产品当前真相源"
[ -f "$_ROOT/docs/DESIGN.md" ] && echo "[DESIGN] 发现 DESIGN.md"
[ -f "$_ROOT/docs/ENGINEERING.md" ] && echo "[ENGINEERING] 发现 ENGINEERING.md"
[ -f "$_ROOT/docs/QA.md" ] && echo "[QA] 发现 QA.md"
# 检测代码状态
echo "--- 代码状态 ---"
git status --short 2>/dev/null | head -10
git log --oneline -3 2>/dev/null
# 检测 Worktree
echo "--- Worktree ---"
git worktree list 2>/dev/null
# 只读检测 Dev Server（如项目提供统一入口）
echo "--- Dev Server ---"
if [ -f "$_ROOT/package.json" ] && (cd "$_ROOT" && npm run 2>/dev/null | grep -q "dev:status"); then
(cd "$_ROOT" && npm run dev:status 2>/dev/null) || true
elif [ -x "$_ROOT/scripts/dev-stack.sh" ]; then
(cd "$_ROOT" && bash scripts/dev-stack.sh status 2>/dev/null) || true
else
echo "未发现统一 dev server 状态入口"
fi
# 检测分支
echo "--- 分支 ---"
git branch --show-current 2>/dev/null
根据检测结果，按以下决策树判断。轻量车道优先于其他规则：
⚡ 轻量车道：用户描述的是小改动（预估 < 半小时，且不碰类型定义/API 格式/枚举/数据结构）
→ "小改动建议走轻量车道，跳过 PRD/设计仪式：
A) /forge-eng 轻量模式 — 直接实现（自验 + 提交前检查仍然要做）
B) /forge-bugfix — 如果本质是修问题
C) 走完整流程 — 如果实际影响面比看起来大（拿不准就选这个）"
完全空项目（无 docs/、无 .features/）
→ "建议先跑一次脚手架铺好状态文件：
~/.claude/skills/forge-doc-policy/scripts/init-project.sh
然后 /forge-brainstorm 或 /forge-prd 开始。"
无任何文档 + 用户没有明确任务
→ "看起来是一个新开始。建议先跑 /forge-brainstorm 理清思路。"
有思考文档，无 PRD 或无 .features Feature Spec
→ "发现思考文档 [{文件名}]。建议下一步：
A) /forge-prd — 将思考转化为 PRD 当前事实 + .features Feature Spec
B) /forge-dev — 跳过 PRD，直接进轻量开发模式
C) /forge-brainstorm — 继续讨论，还没想清楚"
有 PRD + Feature Spec，无 DESIGN.md（且项目含前端）
→ "产品当前事实和 Feature Spec 就绪，但还没有设计文档。建议：
A) /forge-dev — 启动开发调度（会自动触发设计）
B) /forge-design — 单独做设计规划"
有 PRD + DESIGN.md，无 ENGINEERING.md
→ "设计已就绪。建议：
A) /forge-dev — 启动开发调度
B) /forge-eng — 单独做工程实现"
有 ENGINEERING.md，代码有改动未测试
→ "代码已改动。建议：
A) /forge-qa — 验收测试
B) /forge-eng — 继续工程实现"
代码改动已测试，在 feature 分支上
→ "看起来可以收尾了。建议：
A) /forge-review — PR 审查
B) /forge-ship — 发布
C) /forge-fupan — 先复盘再发布"
在 Worktree 中
→ "当前在 Worktree [{分支名}] 中。建议：
A) 继续当前工作（列出未完成任务）
B) /forge-eng — 继续工程实现
C) 收尾 Worktree — merge/PR/keep/discard"
主分支，一切就绪
→ "项目状态良好。你想做什么？
A) /forge-brainstorm — 讨论新想法
B) /forge-prd — 迭代现有需求
C) /forge-bugfix — 修个 bug
D) /forge-fupan — 复盘最近的工作"
基于判断，通过 AskUserQuestion 展示推荐：
当前项目状态：
{项目名} | {分支} | {文档状态摘要}
推荐下一步：【{推荐的 skill}】— {理由}
选项：
A) {推荐选项}（推荐）
B) {备选1}
C) {备选2}
D) 其他 — 告诉我你想做什么
用户选择后：
供参考，当用户问"有哪些工具"时展示：
| Skill | 用途 | 何时使用 |
|---|---|---|
/forge-brainstorm | 头脑风暴 | 有想法要讨论时 |
/forge-prd | PRD 管理 | 需要正式需求文档时 |
/forge-dev | 开发调度 | 从需求到交付；--full 一路到发布（原 forge-deliver 已并入） |
/forge-design | 设计规划 | 需要 UI/UX 设计时 |
/forge-design-impl | 设计实现 | 将设计文档转为代码 |
/forge-feature-doc | 需求设计文档 | 每个功能一份给人看的设计文档：新建、各阶段同步、出图、上线前检查 |
/forge-eng | 工程实现 | 写代码（含 TDD + Worktree） |
/forge-qa | QA 验收 | 测试+报告（不修代码） |
/forge-bugfix | Bug 修复 | 系统性调试和修复 |
/forge-review | PR 审查 | 上线前代码审查 |
/forge-ship | 发布 | 合并+推送+创建 PR |
/forge-fupan | 复盘 | 教训进账本 + 一页纸 + 复发检测（Workbench 是阅览器） |
/forge-doc-release | 发布后文档同步 | ship 之后让文档对齐现实 |
/forge-status | 并行会话巡检 | 扫 .forge/active.md，按硬信号清理僵尸 |
/forge-doc-policy | 文档治理规范 | 文档放哪的规则源头 + 新项目脚手架 |
~/.claude/skills/_shared/visual-decision-layer.md，但 /forge 本身不生成图片No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
通用头脑风暴：4 种模式（产品/内容/构建/探索）× 6 阶段，强制前提挑战和 2-3 方案，产出可跨会话续聊的思考文档；支持 Mermaid/图辅助判断。 触发方式：用户说"头脑风暴"、"brainstorm"、"讨论一下"、"我有个想法"、"帮我想想"、"画图梳理想法"。
The English summary is being prepared. Showing the original description.
系统性 Bug 修复流水线（P0-P8）：一次修一个，强制根因分析、独立 worktree、TDD、双层验收报告、forge-qa 回归；多会话经 .forge/active.md 防撞车。 铁律：不做根因分析不写代码；新发现禁止顺手修；没有用户最终结论不合并。 触发方式：用户说"bugfix"、"反馈个问题"、"修这个 bug"、"这里有问题"、"为什么不对"、"排查一下"、"investigate"、"forge-bugfix"，或报告错误、异常行为、功能失效时。
The English summary is being prepared. Showing the original description.
端到端交付纯编排层：调用 forge-* 子 skill 从需求一路编排到发布和文档，.deliver/state.json 检查点，支持 --auto / --resume。 触发方式：用户说"forge-deliver"、"端到端交付"、"全自动交付"。
The English summary is being prepared. Showing the original description.
全栈设计规划：分级门控管理 DESIGN.md 与 DESIGN-CHANGELOG，内置可检索设计规则库（UX 规则/配色/字体），三层 Token、forge-design-lab 工作台门禁（布局/比例/密度在真 token 骨架上定，Image 2 退为气质稿）、反 AI 模板检测。 触发方式：用户说"设计"、"forge-design"、"先看效果图"，或 forge-dev 调度、需要创建/更新设计文档时。
The English summary is being prepared. Showing the original description.
设计实现：把 DESIGN.md 转成代码，只改样式不改逻辑；CSS 优先、Token 驱动、反 AI 模板、原子提交，以真实截图和 CSS 断言验证。 触发方式：用户说"实现设计"、"forge-design-impl"、设计文档确认后需要写代码时。
The English summary is being prepared. Showing the original description.
在真实 token、真实像素的 HTML 骨架上做页面与组件的设计决策：生成可点、可改、可存的设计工作台，按七层逐节点审查，保存即导出 token 与 CSS 并回写 DESIGN.md 的 token 表。用户说「开工作台」「看骨架」「讨论 XX 的设计稿」「改 token」「我保存好了，按调整后的来」时用；只要在争论比例、密度、一屏几张、行长、栏宽、留白这类要看见才能判断的问题，哪怕没提工作台也用；forge-design 第三步遇到页面、组件、布局决策时必调。也负责全站唯一的设计零件库（一套模板 + 逐条确认的定制 + 守门检查）：说「零件库」「设计模板」「全站设计 token 总表」「这个算不算定制」「查一下有没有用模板外的值」时用。不处理：DESIGN.md 散文与评分（forge-design）、产品代码（forge-eng、forge-design-impl）、效果图气质预判（Image 2）、实现后截图验收（forge-qa）、设计概念问答（直接答）。
The English summary is being prepared. Showing the original description.