write-a-prd

write-a-prd 技能概览

write-a-prd 是一个非常聚焦的技能，专门用来把模糊的功能想法整理成结构化 PRD。它补上了很多通用提示词常常缺失的三件事：先看 repo、持续追问澄清，以及从模块层面思考设计。对于工程师、技术负责人，以及借助 AI 推进需求的构建者来说，如果你需要的是扎根于真实代码库的 Requirements Planning 工作流，而不是一份看起来完整却和实现脱节的规格文档，那么 write-a-prd 会更合适。

write-a-prd 实际会做什么

write-a-prd 技能会引导 agent：

• 收集详细的问题描述，
• 检查仓库以验证前提假设，
• 通过持续访谈用户，把关键决策问清楚，
• 提出主要模块设计，重点放在可测试、足够“深”的抽象上，
• 最终整理成适合发布为 GitHub issue 的 PRD。

最适合哪些用户和任务

当你的需求不只是“帮我写个 PRD”时，就该用 write-a-prd。它尤其适合这样的团队：

• 需要基于现有代码库为新功能做范围界定，
• 想在开发开始前先挖出隐藏决策，
• 希望把产品意图转成可落地的实现需求，
• 需要一份便于评审的 GitHub 原生规划产物。

为什么这个 write-a-prd 技能更突出

它真正的差异点不在格式，而在工作流纪律上：

• 先验证 repo，而不是直接相信最初描述，
• 持续追问，直到歧义被压缩到最小，
• 先勾勒模块，再写最终文档，
• 明确强调可测试的深层模块设计。

因此，相比“一次性生成 PRD”的普通提示词，它在 Requirements Planning 上更有价值。

安装或采用前要知道什么

这个技能本身很轻量：从仓库证据看，只有一个 SKILL.md 文件，没有辅助脚本、模板目录或配套资源。好处是上手快，但也意味着输出质量会高度依赖用户输入，以及 agent 是否愿意认真检查 repo。如果你需要强约束模板、自动化流程或自动发 issue 的脚本，这个技能本身并不提供。

如何使用 write-a-prd 技能

write-a-prd 的安装上下文

上游 skill 本体其实就是 write-a-prd/SKILL.md 这个说明文件。文件内部没有记录任何该技能专属的安装器。如果你使用的是兼容 Skills 的环境，就按你的 agent 平台要求安装或启用其所在仓库，然后确认 write-a-prd 这个 slug 可用即可。

如果你是在安装前做评估，最值得先看的关键文件是：

• SKILL.md

这个技能没有额外的 README.md、metadata.json、rules/ 或 resources/ 文件。

先看这个文件

第一次使用前，先把 SKILL.md 从头到尾读一遍。因为这个技能在 repo 里只有这一个文件，所以所有关键行为都写在里面，包括：

• 什么时候应触发该技能，
• 必须遵循的访谈流程，
• repo 探查步骤，
• 模块设计的要求，
• 最终 PRD 模板。

write-a-prd 需要什么输入

当你提供以下信息时，write-a-prd 的表现通常最好：

• 要解决的问题是什么，
• 谁会遇到这个问题，
• 当前的替代做法或痛点是什么，
• 截止时间、兼容性、合规等约束，
• 你已有的早期方案想法，
• 需要检查的仓库或代码区域，
• 你希望 PRD 写到什么实现细节层级。

弱输入示例：“Add notifications.”

强输入示例：“We need in-app notifications for failed background jobs because users currently miss email alerts. The app is multi-tenant, jobs already emit failure events, and we need an MVP this sprint without mobile push support.”

如何把粗糙想法变成一个好的 write-a-prd 提示词

一个高质量的 write-a-prd 使用提示，通常会把业务背景、代码库范围和决策约束放在同一条消息里。建议包含：

1. 预期结果，
2. 受影响的用户，
3. 相关 repo 路径，
4. 已知约束，
5. 希望技能帮助厘清的开放问题。

示例结构：

• “Help me use write-a-prd for Requirements Planning.”
• “The problem is…”
• “Please inspect these areas of the repo…”
• “Assume these constraints…”
• “Challenge weak assumptions and produce a GitHub-issue-ready PRD.”

实际推荐的工作流

一个实用的 write-a-prd 工作流通常是这样的：

1. 先给出完整的问题描述。
2. 让 agent 在起草前先检查代码库。
3. 对追问尽量完整回答，不要急着套模板。
4. 审查它提出的模块划分和测试边界。
5. 然后再要求生成最终 PRD。
6. 最后把结果发布成 GitHub issue，或按需要再做改写。

这个顺序很重要。如果跳过 repo 审查或访谈阶段，结果就会非常接近普通的 PRD 生成提示词。

访谈阶段为什么会显著影响输出质量

write-a-prd 最强的一点，是它明确要求 agent “relentlessly” 地访谈用户。落到实际使用中，这意味着 agent 应该持续给这些内容施压验证：

• 边界情况，
• 用户角色，
• 运行和运营约束，
• 迁移相关顾虑，
• 成功标准，
• 各个设计决策之间的依赖关系。

如果你的 agent 没有提出足够多的追问，说明这个技能还没被真正用起来。

为什么 repo 探查对 Requirements Planning 很关键

对于 Requirements Planning 来说，write-a-prd 的 repo 探查步骤，正是把“猜测”变成“有依据规划”的关键。你应该让 agent 去验证：

• 是否已经存在类似功能，
• 哪些模块最可能受影响，
• 现有命名和架构约定是什么，
• 新功能方案是否会与当前抽象冲突。

这样可以显著减少 PRD 常见的问题：文档看起来很完整，但完全没贴住代码现实。

如何把模块草图这一步用好

write-a-prd 会明确要求提出主要模块，并鼓励设计易于测试、难以误用的深层模块。这意味着你最好要求 agent 识别：

• 哪些内容应该被封装，
• 每个模块暴露什么接口，
• 哪些位置最可能发生变化，
• 哪些部分值得做隔离测试。

如果你的 PRD 不是只拿来对齐干系人，而是要真正指导实现，这一步尤其有价值。

最终 PRD 应该包含什么

根据上游模板，最终 PRD 至少应覆盖：

• ## Problem Statement
• ## Solution

SKILL.md 里的完整模板显然不止仓库证据里截出的这部分，因此在内部标准化格式之前，最好先直接查看该文件。如果你的团队要求包含 rollout、analytics 或 non-goals 之类的章节，需要明确要求 agent 扩展模板。

一个高质量的 write-a-prd 使用提示示例

下面是一个比较实用的提示结构，你可以直接改：

“Use the write-a-prd skill to help me plan a feature for this repository. The problem is that admins cannot bulk reassign tickets during org restructures, so teams are doing manual updates. Please inspect the ticketing, permissions, and audit-log code paths first. Constraints: preserve existing RBAC behavior, record all bulk changes, and avoid long-running synchronous requests. Interview me until the scope is clear, propose the main modules, identify which modules should have tests, then draft a GitHub-issue-ready PRD.”

write-a-prd 技能常见问题

write-a-prd 比普通 PRD 提示词更好吗？

通常是的，前提是你的项目已经有代码库，并且存在实现约束。普通提示词当然也能排出一份像样的文档，但如果你需要 PRD 真实反映 repo 现状、未决取舍和模块边界，write-a-prd 会更强。

write-a-prd 适合初学者吗？

适合，但有一个前提：初学者必须愿意耐心回答追问。这个技能可以帮助你把思路理顺，但它不能替代产品判断。如果你本身不熟悉代码库，一定要明确说明，这样 agent 才会把更多精力放在 repo 探查和需求澄清上。

什么情况下 write-a-prd 不合适？

以下场景建议跳过 write-a-prd：

• 你只需要一段一两段的概念说明，
• 没有 repo 可供检查，
• 任务只是一个很小的 bug 修复，
• 决策早已做完，你只需要润色文案，
• 你的团队需要固定的企业级 PRD schema，而这个技能并不提供。

write-a-prd 也会生成实现计划吗？

会有一定帮助，但不是它的核心目标。它主要用于生成 PRD，不过模块设计这一步会在 PRD 和实现之间搭起一座轻量的架构桥梁。如果你还需要任务拆解、milestone 或 ticket decomposition，通常还要在 PRD 之后再做一轮规划。

它会自动提交 GitHub issue 吗？

这个技能确实提到 PRD 应该以 GitHub issue 的形式提交，但从仓库证据看，并没有自动化脚本或 issue-posting helper。更准确的理解是：它产出的内容是 issue-ready 的，而不是自带 issue 自动化。

我应该给 agent 多大范围的 repo 访问权限？

至少要让它能检查相关功能区域及相邻模块。访问太少，会直接削弱这个技能最核心的优势。如果访问受限，至少补充文件路径、架构说明和有代表性的代码片段，这样 write-a-prd 仍然可以基于具体材料进行推理。

如何改进 write-a-prd 技能的使用效果

提供更精准的问题陈述，而不是解决方案口号

最常见的失败模式，是一上来就给一个方案标签，而不是描述用户问题。更好的输入应该说明：

• 谁被卡住了，
• 他们想完成什么，
• 当前失败点在哪里，
• 为什么这件事现在重要。

和“add X feature”相比，这样的输入能为 write-a-prd 提供更扎实的 Requirements Planning 基础。

尽早把约束说清楚

好的 PRD 往往是在起草前就把约束讲明白的。建议提前告诉技能：

• 性能上限，
• 向后兼容要求，
• 安全规则，
• 上线时间要求，
• analytics 需求，
• 测试预期。

否则，它很可能产出一份看上去合理、实际却不可落地的方案。

让 agent 明确展示哪些决策仍未解决

如果第一版看起来“确定性”太强，可以要求 write-a-prd 把以下内容拆开写：

• 已确认的决策，
• 假设项，
• 未解决的问题，
• 延后处理的选择。

这是让输出更适合团队评审的最快方法之一。

提升 repo 探查这一步的质量

不要轻易接受一句“我已经看过代码库了”。你应该进一步要求它给出：

• 实际检查了哪些文件或模块，
• 发现了哪些当前行为，
• 从现有架构中推导出了哪些约束，
• 你的最初需求与 repo 现实之间是否存在偏差。

这样才能让 write-a-prd 的指导更可信。

强化模块设计输出

模块这一步很容易写得过于空泛。建议要求每个提议模块都写清楚：

• 职责，
• 接口形态，
• 依赖关系，
• 为什么它应该设计成 deep 而不是 shallow，
• 是否应该做隔离测试。

这样可以把 PRD 从“产品文案”推进到真正和实现相关的层面。

在第一版 PRD 之后继续迭代

第一版通常不应该直接当最终稿。一个更有效的优化循环是：

1. 检查是否遗漏约束，
2. 标出表述模糊的部分，
3. 质疑是否存在过度设计，
4. 要求补充 non-goals 和 success criteria，
5. 只重写薄弱章节。

相较于“整份 PRD 全部重写”，这种定向改写通常效果更好。

明确加入你们团队要求的章节

因为这个技能很轻量，不要默认它天然符合你们团队的 house style。如果你们团队要求这些章节：

• non-goals，
• rollout plan，
• metrics，
• risks，
• migration，
• support impact，

请直接在提示里写明。write-a-prd 很灵活，但如果你不提，它不会自动补齐所有治理类章节。

留意这些常见失败模式

write-a-prd 常见的输出问题包括：

• 还没澄清问题就直接跳到实现，
• repo 依据不足，
• 模块边界过浅，
• 缺少测试预期，
• PRD 只描述功能，不描述成功条件。

这些问题大多数都不需要放弃这个技能，而是通过更好的输入和更严格的后续评审来修正。