通用头脑风暴:4 种模式(产品/内容/构建/探索)× 6 阶段,强制前提挑战和 2-3 方案,产出可跨会话续聊的思考文档;支持 Mermaid/图辅助判断。 触发方式:用户说"头脑风暴"、"brainstorm"、"讨论一下"、"我有个想法"、"帮我想想"、"画图梳理想法"。
日本語の概要は準備中です。原文の説明を表示しています。
Forge 工作流总入口。只读检测项目状态,推荐下一步该用哪个 skill,自己不干活。触发方式:用户说"forge"、"下一步"、"接下来做什么"。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
不知道下一步该干什么?打 /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 本身不生成图片まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
通用头脑风暴:4 种模式(产品/内容/构建/探索)× 6 阶段,强制前提挑战和 2-3 方案,产出可跨会话续聊的思考文档;支持 Mermaid/图辅助判断。 触发方式:用户说"头脑风暴"、"brainstorm"、"讨论一下"、"我有个想法"、"帮我想想"、"画图梳理想法"。
日本語の概要は準備中です。原文の説明を表示しています。
系统性 Bug 修复流水线(P0-P8):一次修一个,强制根因分析、独立 worktree、TDD、双层验收报告、forge-qa 回归;多会话经 .forge/active.md 防撞车。 铁律:不做根因分析不写代码;新发现禁止顺手修;没有用户最终结论不合并。 触发方式:用户说"bugfix"、"反馈个问题"、"修这个 bug"、"这里有问题"、"为什么不对"、"排查一下"、"investigate"、"forge-bugfix",或报告错误、异常行为、功能失效时。
日本語の概要は準備中です。原文の説明を表示しています。
端到端交付纯编排层:调用 forge-* 子 skill 从需求一路编排到发布和文档,.deliver/state.json 检查点,支持 --auto / --resume。 触发方式:用户说"forge-deliver"、"端到端交付"、"全自动交付"。
日本語の概要は準備中です。原文の説明を表示しています。
全栈设计规划:分级门控管理 DESIGN.md 与 DESIGN-CHANGELOG,内置可检索设计规则库(UX 规则/配色/字体),三层 Token、forge-design-lab 工作台门禁(布局/比例/密度在真 token 骨架上定,Image 2 退为气质稿)、反 AI 模板检测。 触发方式:用户说"设计"、"forge-design"、"先看效果图",或 forge-dev 调度、需要创建/更新设计文档时。
日本語の概要は準備中です。原文の説明を表示しています。
设计实现:把 DESIGN.md 转成代码,只改样式不改逻辑;CSS 优先、Token 驱动、反 AI 模板、原子提交,以真实截图和 CSS 断言验证。 触发方式:用户说"实现设计"、"forge-design-impl"、设计文档确认后需要写代码时。
日本語の概要は準備中です。原文の説明を表示しています。
在真实 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)、设计概念问答(直接答)。
日本語の概要は準備中です。原文の説明を表示しています。