507 prd

Workflow-oriented Agent Skills for writing, coding, research, and decision alignment.

Install

npx -y skills add ssdiwu/507-skills --skill 507-prd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

24 days oldThe repository was created 24 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

把当前对话、方案或 PRD 沉淀成产品需求文档（PRD）。承接对齐结果到执行的中间规格化层——把方案落成需求规格（要解决什么问题、给谁、怎么验证）。不拆 issue 工单（归 507-issue）、不做架构体检（归 507-inspect）。Use when user mentions 写 PRD, 拆 PRD, 做个 PRD, 沉淀 PRD, 形成需求文档, 把刚才整理成需求, 需求规格, 落成 PRD, to-prd, product requirements.

SKILL.md

6.9 KB, as published. Nobody here has run it

产品需求文档（prd）

把讨论过的上下文沉淀成 PRD（产品需求文档）——回答要解决什么问题、给谁、怎么验证。

解决的核心问题是 misalignment（对齐失败）的后置兜底——方案问透后，如果不落成一份需求规格，直接进执行，agent 容易按自己的理解跑偏。507-prd 是对齐到执行之间的可选规格化层：轻任务可直接执行；重任务或需要留档的需求，先写 PRD 再执行。

507-prd 做的是：对话/方案 → PRD 需求规格。

覆盖什么

从当前对话/方案合成 PRD（不重新访谈，只综合已有信息）
把 grill 的对齐结论落成可留档的需求文档
为执行提供需求规格基准

不覆盖什么

执行前把方案问透 → 用 507-grill（507-prd 是对齐的下游：先问清要做什么，再写 PRD）
把方案拆成可领取的 GitHub issue → 用 507-issue（issue 是可领取的执行单元，PRD 是需求规格，两件事）
写面向人的活动、培训、合作或项目方案 → 用 507-frame
架构审查找重构机会 → 用 507-inspect
执行编排 → 不在本 skill 范围（507-prd 产需求规格，不编排执行）

核心纪律（不可违反）

不空访谈：综合已经说过的内容，不重复询问用户。缺关键事实时，一次只问一个问题，并附推荐答案。
用项目语言：先读 doc/术语表.md 和相关 doc/决策档案/；PRD 标题和正文使用项目术语。
测试接缝先想清楚：写 PRD 时先想"这个功能会在哪个公开接缝验证"；优先已有接缝，必要时才提新接缝。
只写稳定信息：PRD 默认不塞具体文件路径和代码片段，因为很快过期。例外：原型产出的状态机、schema、reducer、类型形状等能比文字更精确地表达决策时，可截取关键片段并注明来源。
落点是"要做什么/为什么"，不是"怎么改"：PRD 描述需求和行为，不规定实现步骤。

PRD 模板

适用：用户说"写 PRD / 把刚才整理成需求 / 形成需求文档"。

流程：

读已有上下文和项目文档，理解当前代码状态。
agent 自行设计测试接缝：优先项目已有公开接口、用户路径和测试先例；只有测试接缝会改变产品行为、权限、成本或风险取舍时，才回到 507-grill 让用户决定。
写 PRD。
做局部自检并直接修正文档，再交给下游。

## 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、空章节或未替换占位符；关键事实缺口没有伪装成确定需求。
内部一致性：Problem、Solution、User Stories、Implementation Decisions、Testing Decisions 与 Out of Scope 互不矛盾，项目术语前后一致。
范围：内容足以形成一个可执行目标；多个相互独立的目标已拆开，不把未来可能性塞进本次规格。
无歧义：每项需求只有一种合理解释；角色、触发条件、成功结果、失败结果和边界明确。
可验证：每项用户可见行为都能落到公开接缝或用户路径；验收不依赖内部实现细节。

若仍有会改变需求、范围或验收的关键问题，停止下游路由并回到 507-grill 对齐；不要把阻塞性未知项藏进 Further Notes 后继续执行。

和其他 skill 的边界

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，用项目语言。
自行设计并写明测试接缝；把选择和依据告知用户，不要求用户替 agent 完成工程设计。
按 PRD 模板写需求规格。
完成局部自检并直接修正占位符、矛盾、范围、歧义和不可验证表述。
提示下一步：需要拆成可领取工单 → 507-issue；直接执行 → 交执行入口。

完成与接力

完成信号：需求、范围、用户行为、失败边界和测试接缝前后一致，没有需要用户决定的阻塞项。
产物：项目既有规格目录中的 PRD，或用户明确要求的一次性 PRD 文档。
候选出口：需要调查或跟踪执行时进入 507-issue；存在低成本可验证的关键假设时进入 507-prototype 并回写结论；已授权且任务足够清楚时直接实施；仍缺用户取舍时返回 507-grill。
边界提醒：507-prd 写具体产品应做什么；面向人的活动、培训、合作或项目提案归 507-frame。

红线

不拆 issue 工单（归 507-issue）。
不写实现步骤（写需求和行为，实现走执行入口）。
不空访谈（综合已有上下文）。
不塞易过期的文件路径/行号（耐久优先）。
不在和 507-issue 的边界上抢“创建 issue”的工作。