write-a-prd
通过用户访谈、代码库探索与模块设计来编写 PRD（产品需求文档），然后以 GitHub issue 的形式提交。适用于用户希望编写 PRD、创建产品需求文档，或规划一个新功能。
Best use case
write-a-prd is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
通过用户访谈、代码库探索与模块设计来编写 PRD（产品需求文档），然后以 GitHub issue 的形式提交。适用于用户希望编写 PRD、创建产品需求文档，或规划一个新功能。
Teams using write-a-prd should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/write-a-prd/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How write-a-prd Compares
| Feature / Agent | write-a-prd | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
通过用户访谈、代码库探索与模块设计来编写 PRD（产品需求文档），然后以 GitHub issue 的形式提交。适用于用户希望编写 PRD、创建产品需求文档，或规划一个新功能。
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
当用户希望创建 PRD 时，将调用本技能。你可以根据需要跳过其中一些步骤。 1. 向用户索要对他们想解决的“问题”的长篇、细节充分的描述，以及任何潜在的解决思路。 2. 探索仓库以验证他们的判断，并理解当前代码库的现状。 3. 不断地“访谈用户”：围绕方案树的每个分支追问，直到你们对设计形成共同理解。要逐步走过设计树的每条路径，逐个解决决策之间的依赖关系。 4. 在你理解这些决策之后，勾勒出你需要构建或修改的主要模块。并积极寻找可将“深模块（deep modules）”抽取出来、以便能在隔离环境下进行测试的机会。 所谓深模块（deep module），与浅模块（shallow module）相对：它会把大量功能封装进一个简单、可测试的接口，并且很少会频繁变化。 和用户一起确认这些模块是否符合他们的预期，并让用户确认：哪些模块希望你为其编写测试。 5. 当你已经对问题与解决方案形成完整理解后，使用下面的模板来撰写 PRD。PRD 应以 GitHub issue 的形式提交。 <prd-template> ## 问题陈述（Problem Statement） 从用户视角来看，用户正面临的那项问题。 ## 解决方案（Solution） 从用户视角来看，针对该问题的解决方案。 ## 用户故事（User Stories） 一份非常长的、带编号的用户故事清单。每条用户故事应采用以下格式： 1. 作为一个 <actor>，我希望能够 <feature>，以便 <benefit> <user-story-example> 1. 作为移动银行客户，我希望能查看我账户的余额，以便我能更好地做出关于支出的决策 </user-story-example> 这份用户故事清单应当尽可能详尽，并覆盖功能的各个方面。 ## 实现决策（Implementation Decisions） 实现决策列表。可能包括： - 将要构建/修改的模块 - 将要修改的这些模块的接口 - 来自开发者的技术澄清 - 架构层面的决策 - schema 的变更 - API 合约（API contracts） - 具体交互方式 **不要**包含具体文件路径或代码片段。这些内容很可能会在后续很快变得过时。 ## 测试决策（Testing Decisions） 测试决策列表。需要包含： - 你认为“一条好测试”应当是什么（只测试外部行为，不测试实现细节） - 需要被测试的模块 - 测试的先例/参考（即仓库中类似类型测试的对照） ## 不在范围内（Out of Scope） 描述本 PRD 中明确不包含的内容。 ## 进一步备注（Further Notes） 关于该功能的其他补充说明。 </prd-template>
Related Skills
write-a-skill
以正确的技能结构、渐进式披露与打包资源来创建新的 agent 技能。适用于用户希望创建、编写或构建新的技能。
ubiquitous-language
从当前对话中抽取 DDD 风格的“统一语言”术语表（ubiquitous language glossary），标记歧义，并提出规范的术语选择。保存为 `UBIQUITOUS_LANGUAGE.md`。适用于用户希望定义领域术语、构建术语表、固化用词并强化术语一致性，或提到 “domain model” / “DDD”（领域模型与 DDD）。
triage-issue
通过探索代码库对 Bug/Issue 进行排查归因，并基于 TDD 方式生成修复计划，同时创建对应的 GitHub issue。适用于用户报告了 bug、希望创建 issue、提到“triage”，或想调查并规划某个问题的修复方案。
tdd
使用 RED-GREEN-重构（red-green-refactor）循环进行测试驱动开发。适用于用户希望用 TDD 构建新功能或修复 bug，提到 “red-green-refactor”，希望使用集成测试，或询问“test-first development（先写测试）”。
request-refactor-plan
通过用户访谈创建一个详细的重构计划，并将其拆分成很小的提交（tiny commits），最后以 GitHub issue 的形式归档。适用于用户希望规划一次重构、创建重构 RFC，或把重构拆成安全的渐进步骤。
prd-to-plan
使用 tracer-bullet 竖向切片方法把 PRD 转换成多阶段的落地实施计划，并保存为本地 Markdown 文件（存放在 `./plans/`）。适用于用户希望把 PRD 拆分为多个阶段、生成实施计划、从 PRD 推导阶段计划，或提到 “tracer bullets”。
prd-to-issues
使用 tracer-bullet 竖向切片法，把 PRD 拆分成彼此独立、可以直接认领的 GitHub issues（并形成对应的实现工单）。适用于用户想把 PRD 转成 issues、创建实现任务，或把 PRD 拆成工作项。
improve-codebase-architecture
探索代码库以发现架构改进机会，重点让代码库更容易测试：通过“加深浅模块（deepening shallow modules）”的方式重构模块结构。适用于用户想改善架构、寻找可重构机会、整合强耦合模块、或让代码库更便于 AI 导航与理解。
grill-me
对用户在计划或设计方面进行“无情的质询”，直到形成共同理解，并逐一解决决策树中每个分支的依赖关系。适用于用户希望对某个计划进行压力测试、希望被严格追问他们的设计，或提到 “grill me（来烤我/质问我）”。
frontend-code-review
指导在项目中对前端代码（Next.js/React/TypeScript/Tailwind 等）进行结构、可维护性、性能与一致性审查，基于既定规则清单。适用于用户请求审查 .tsx/.ts/.js/.jsx 等前端文件或前端目录下的页面与组件。不用于后端代码（如 .py）。
edit-article
通过重组文章的段落结构、提升表达清晰度，并收紧措辞来编辑与改进文章。适用于用户希望编辑、修订或完善一份文章草稿。
design-an-interface
使用并行子 agent 为某个模块生成多个根本不同的接口设计。适用于用户希望设计某个 API、探索接口选项、对比模块形状（module shapes），或提到“design it twice（把它设计两遍）”。