Menú
产品诊断与 PRD 迭代：诊断根因（设计缺陷/实现偏离/PRD 遗漏），必要时反驳需求，更新 PRD 并生成带异常态门禁的 Feature Spec。 触发方式：用户说"更新PRD"、"调整需求"、"迭代PRD"、"forge-prd"、描述产品问题、需要修改产品需求时。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
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-prd |
| description | 产品诊断与 PRD 迭代：诊断根因（设计缺陷/实现偏离/PRD 遗漏），必要时反驳需求，更新 PRD 并生成带异常态门禁的 Feature Spec。 触发方式：用户说"更新PRD"、"调整需求"、"迭代PRD"、"forge-prd"、描述产品问题、需要修改产品需求时。 |
文档落地路径：遵循 forge-doc-policy 规范。完整白名单 + frontmatter schema 见
~/.claude/skills/forge-doc-policy/doc-paths.md。 当前文档加载契约：先读项目CLAUDE.md、docs/README.md、docs/INDEX.md和根级当前真相源；长 changelog 和 raw archive 只在追溯历史原因时加载。详见~/.claude/skills/_shared/current-doc-loading.md。
全程中文。每个步骤结束后暂停等待用户反馈。
用户描述问题/需求
│
▼
┌─ 第0步：定位 ──────────────────────────┐
│ Glob 搜索 PRD / CHANGELOG │
│ ├─ 找到 PRD → 迭代模式 │
│ ├─ 没找到 → [询问用户] 是否创建模式 │
│ └─ 没找到 CHANGELOG → 标记第4步新建 │
└──────────────────────────────────────────┘
│
▼
┌─ 第1步：理解现状 ─────────────────────────┐
│ 读 PRD + CHANGELOG + Agent(Explore)源码 │
│ 热点分析（模块修改频次） │
│ → [询问用户] 总结现状，确认理解是否正确 │
│ → [询问用户] 本次迭代需求是什么？ │
└─────────────────────────────────────────────┘
│
▼
┌─ 第2步：诊断与审查 ──────────────────────────┐
│ 自动判定层级：轻量 / 标准 / 深度 │
│ ┌─ 所有层级 ─────────────────────────┐ │
│ │ ① 问题归因（设计缺陷/偏离/遗漏） │ │
│ │ ② 10星挑战（当前几星→10星差距） │ │
│ └─────────────────────────────────────┘ │
│ ┌─ 标准+深度 ─────────────────────────┐ │
│ │ ③ 模块健康度检查 │ │
│ └─────────────────────────────────────┘ │
│ ┌─ 仅深度 ───────────────────────────┐ │
│ │ ④ 假设审查 ⑤ 反驳机制 │ │
│ └─────────────────────────────────────┘ │
│ → [询问用户] 展示诊断结果，确认方向 │
└───────────────────────────────────────────────┘
│
▼
┌─ 第3步：方案确认 ─────────────────────────────┐
│ 逐项讨论变更点（当前→目标→推荐→可选） │
│ → [多轮询问用户] 每个变更点确认 │
│ → [询问用户] 汇总变更清单，最终确认 │
│ ⚠️ 门禁：确认前不写任何文件 │
└────────────────────────────────────────────────┘
│ 用户确认 ✓
▼
┌─ 第4步：写入文档 ─────────────────────────────┐
│ A. 更新/新建 Feature Spec（.features） │
│ B. 将最终有效结论回写 PRD 当前事实 │
│ C. 更新 CHANGELOG 历史账本 │
│ → 输出最终总结 │
└────────────────────────────────────────────────┘
需要图示辅助判断时（架构图/流程对比/状态机），先读 references/prd-details.md 的可视化规范节。
提问格式与批量策略见
~/.claude/skills/_shared/interaction-protocol.md。
根据用户提供的目录线索，用 Glob 搜索 PRD 文件：
搜索模式（按优先级）：
- {项目目录}/docs/PRD.md
- {项目目录}/docs/prd.md
- {项目目录}/docs/*PRD*
- {项目目录}/docs/*需求*
- {项目目录}/PRD.md
- {项目目录}/**/PRD*.md
搜索 CHANGELOG 文件（不写死文件名，模式匹配）：
搜索模式：
- {项目目录}/docs/*changelog*（不区分大小写）
- {项目目录}/docs/*CHANGELOG*
- {项目目录}/docs/*变更*
- {项目目录}/**/CHANGELOG*
- {项目目录}/**/changelog*
分支判断：
docs/README.md、docs/INDEX.md 和 docs/PRD.md 当前真相源。docs/modules/*、当前代码和相关接口/表。docs/CHANGELOG.md 顶部索引；只有本次问题需要历史原因时，才读取 PRD-CHANGELOG.md 的相关段落，不默认扫全文。项目没有 PRD 时走此分支：深度读代码 + 多轮交互确认后生成完整 PRD。 细则必读 references/prd-details.md；模板用 references/prd-template.md。
| 层级 | 触发条件 | 做什么 |
|---|---|---|
| 轻量审查 | 单个小改动（改阈值、调文案、修参数） | 归因 → 10星挑战 → 确认方案 |
| 标准审查 | 功能调整、多个小改动集中在同一区域 | 归因 + 模块健康度 + 10星挑战 + 方案对比 |
| 深度审查 | 新模块、架构调整、或 CHANGELOG 显示某模块反复修改 | 假设审查 + 10星挑战 + 反驳机制 |
自动升级规则：
问题归因：
10星挑战（所有层级必做）：
模块健康度检查（标准/深度层级）：
假设审查：
反驳机制：
向用户展示：
可视化判断：根据诊断复杂度决定是否用 widget：
等待用户确认方向后进入第3步。
通过 AskUserQuestion 逐项讨论每个变更点：
可视化判断：
讨论完成后，汇总变更清单：
通过 AskUserQuestion 请用户最终确认。
⚠️ 关键门禁：在用户明确确认变更清单之前，不得写入任何文件（CHANGELOG、PRD）。 第3步的产出仅在对话中展示，不写入磁盘。
门禁不变：Feature Spec 需用户确认后才可进开发；每个功能点至少 3 种异常态 （空态/错误态/降级态，涉本地存储加陈旧态），异常态的 Then 必须写明确 UI 行为。
交给用户前先跑四点自审（Superpowers v5 Spec Self-Review，约 30 秒抓 4-5 个问题）：
首次运行时（项目根目录不存在 CLAUDE.md）：
{项目根目录}/CLAUDE.md已有 CLAUDE.md 时：
## Forge 工作流 章节前提：用户已在第3步确认变更清单，且在第3.5步确认 Feature Spec。 确认后一次性产出并写入以下内容：
在 CHANGELOG 文件中追加本次变更记录（如果 CHANGELOG 不存在，新建并基于 git history 回溯生成历史记录）。
参考格式见 references/prd-template.md 的 CHANGELOG 格式部分。
每条变更记录包含：
.features/{feature-id}/feature-spec.md。.features/{feature-id}/status.md 和 .features/_registry.md。docs/PRD.md。docs/PRD.md。在 PRD 的「本次迭代摘要」中包含面向下游 Agent 的交付说明：
此部分内容在对话中与用户确认核心方向后，由 skill 补充 Agent 所需的技术细节，一并写入 PRD。
写入完成后，输出最终总结：
核心三条：① 每个 feature 一个 .features/{id}/status.md，prd 行本 skill 负责更新；
② 全局注册表 _registry.md 同步 heartbeat；③ 状态值只用 ⏳/🔄/✅/❌。
字段与操作细则见 references/prd-details.md。