القائمة
产品诊断与 PRD 迭代：诊断根因（设计缺陷/实现偏离/PRD 遗漏），必要时反驳需求，更新 PRD 并生成带异常态门禁的 Feature Spec。 触发方式：用户说"更新PRD"、"调整需求"、"迭代PRD"、"forge-prd"、描述产品问题、需要修改产品需求时。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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。