メニュー
把当前对话、方案或 PRD 沉淀成产品需求文档（PRD）。承接对齐结果到执行的中间规格化层——把方案落成需求规格（要解决什么问题、给谁、怎么验证）。不拆 issue 工单（归 507-issue）、不做架构体检（归 507-inspect）。Use when user mentions 写 PRD, 拆 PRD, 做个 PRD, 沉淀 PRD, 形成需求文档, 把刚才整理成需求, 需求规格, 落成 PRD, to-prd, product requirements.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | 507-prd |
| description | 把当前对话、方案或 PRD 沉淀成产品需求文档（PRD）。承接对齐结果到执行的中间规格化层——把方案落成需求规格（要解决什么问题、给谁、怎么验证）。不拆 issue 工单（归 507-issue）、不做架构体检（归 507-inspect）。Use when user mentions 写 PRD, 拆 PRD, 做个 PRD, 沉淀 PRD, 形成需求文档, 把刚才整理成需求, 需求规格, 落成 PRD, to-prd, product requirements. |
把讨论过的上下文沉淀成 PRD（产品需求文档）——回答要解决什么问题、给谁、怎么验证。
解决的核心问题是 misalignment（对齐失败）的后置兜底——方案问透后，如果不落成一份需求规格，直接进执行，agent 容易按自己的理解跑偏。507-prd 是对齐到执行之间的可选规格化层：轻任务可直接执行；重任务或需要留档的需求，先写 PRD 再执行。
507-prd 做的是：对话/方案 → PRD 需求规格。
507-grill（507-prd 是对齐的下游：先问清要做什么，再写 PRD）507-issue（issue 是可领取的执行单元，PRD 是需求规格，两件事）507-frame507-inspect507-prd 产需求规格，不编排执行）doc/术语表.md 和相关 doc/决策档案/；PRD 标题和正文使用项目术语。适用：用户说"写 PRD / 把刚才整理成需求 / 形成需求文档"。
流程：
507-grill 让用户决定。## Problem Statement
从用户视角描述问题。
## Solution
从用户视角描述解决方案。
## User Stories
1. As a <actor>, I want <feature>, so that <benefit>.
2. ...
## Implementation Decisions
- 需要构建/修改哪些 module（模块）或 interface（接口）
- 技术澄清、架构选择、schema/API/交互约定
- 不写易过期的具体文件路径，除非是决策级原型片段
## Testing Decisions
- 好测试验证外部行为，不测实现细节
- 计划在哪些公开接缝测试
- 代码库里已有的相似测试先例
## Out of Scope
明确不做什么。
## Further Notes
补充说明、风险或开放问题。
写完 PRD 后，从后续执行者和验收者的视角完整重读一次；发现问题直接修正文档，不把检查清单原样附进 PRD：
TODO、TBD、空章节或未替换占位符；关键事实缺口没有伪装成确定需求。若仍有会改变需求、范围或验收的关键问题，停止下游路由并回到 507-grill 对齐；不要把阻塞性未知项藏进 Further Notes 后继续执行。
| skill | 分工 |
|---|---|
| prd | 对话/方案 → PRD 需求规格（本 skill，想清楚要做什么） |
| issue | 任务 → GitHub issue（507-prd 的可选下游；PRD 想清楚后，拆成可领取 issue） |
| grill | 把方案/改动问透（507-prd 的上游） |
| 执行入口 | 编排执行（507-prd 产需求规格，不编排执行） |
时序：对齐 → 写 PRD（可选）→ 拆 GitHub issue（可选）→ 执行。
507-prd 和 507-issue 的区别：PRD 是“想清楚要做什么”（需求规格），issue 是“把要做的事写成可领取的任务”（执行单元）。它们是两件事——PRD 给项目自己看，issue 给 GitHub 上的 AI/协作者领取。重任务两者都走（先 PRD 再拆 issue），轻任务都可以跳过直接执行。
当用户说"写 PRD""把刚才整理成需求""形成需求文档"时：
doc/术语表.md，用项目语言。507-issue；直接执行 → 交执行入口。507-issue；存在低成本可验证的关键假设时进入 507-prototype 并回写结论；已授权且任务足够清楚时直接实施；仍缺用户取舍时返回 507-grill。507-prd 写具体产品应做什么；面向人的活动、培训、合作或项目提案归 507-frame。507-issue）。507-issue 的边界上抢“创建 issue”的工作。Git 提交：在用户明确要求提交时，轻量安全复核变更、精确暂存、运行相关验证并创建真实 Conventional Commit；只做本地提交，推送与对外发布由 507-release 承接。Use when user says commit, 提交, 提交一下, 提交这些改动, 提交代码, Git 提交, commit 一下, 生成并执行提交, 准备提交, 存个档。
对外发布：在用户明确要求发布、推送或发版时，定版本号、打 tag、推送远端，并按项目实际探测的发布渠道（npm、GitHub Release）发布。每个不可逆对外动作执行前都向用户显式确认。Use when user says release, publish, push, 发版, 发布, 推送, 发包, 打 tag, 升版本, 升级版本号, 发新版本, 上线, 发到 npm, 发 GitHub Release。默认只做用户明确点名的对外动作，不自动扩到全部渠道。
根因修复：已明确存在 bug、报错、崩溃、异常、回归或合并冲突时，先建立可重复反馈环，再以最小改动修复根因并验证。Use when user says fix, 修一下, 修 bug, 报错了, 崩了, 跑挂了, 有 bug, 修复报错, 合并冲突, 修复冲突, 修不通, debugging, error, crash, regression.
维护项目地图：以当前代码为证据，建立或校准 README、doc 组织、目录职责、入口与上下游，只修改地图文档。Use when user says map, project map, 梳理项目结构, 项目结构, 更新 README, 补 README, 校准 README, 整理 doc, 整理结构, 文档地图, 目录职责, 分层 README.
交付审查：围绕明确的 commit、branch、diff 或路径检查 Standards、Spec 与 Code Quality，只报告问题、证据和路由。Use when user says review this change, code review, review 一下, 检查, 审查, 审查改动, 审查这次改动, 检查提交, 检查分支, 过一遍代码, 把关, 需求符合度, 交付审查. 不用于主动寻找全库架构机会。
在保持公开契约与可观察行为不变的前提下，对指定代码范围或 507-inspect 报告逐项建立证据、修改并验证。可深入内部模块、抽象与接缝；若需要行为变化则停止并路由到需求实施。Use when user mentions simplify, simplify code, 简化, 简化代码, 行为不变重构, 内部简化, 按报告修改, 处理 inspect 报告, 局部重构, 降低复杂度, 收敛架构摩擦。