to-prd
- 信任分
- 88/100
- 兼容 Agent
- 1
- 领域
- 工程开发
- 兼容 Agent
- Claude Code
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @mattpocock · 未声明 license
- 安装命令数
- 1 条
需要注意： 未限定 allowed-tools，默认拥有全部工具权限。
想读作者英文原文？ ↓ 滚到正文区切换 · 在 GitHub 查看 ↗
to-prd 把当前对话和你已掌握的代码理解直接合成成 PRD（产品需求文档）——不再访谈用户，因为该问的已经在前面问过了，这一步是「写下来」。
设计思路
作者把 PRD 视为「让人和 agent 都能据此动手」的成品。核心方法论是Deep Module（来自《A Philosophy of Software Design》）：把功能藏在简单、可测、稳定的接口背后，避免到处都是浅模块。这一节会让你主动找 deep module 的拆分机会，并与用户确认拆分方向、确认要测哪些。
工作流
① 探代码（如果还没探过），词汇用项目领域术语，触及区域尊重 ADR；② 草拟「需要新建 / 修改的主要 module」并主动找可独立测试的 deep module，与用户确认 module 划分与各自要不要测；③ 按下面模板写 PRD 并发布到 issue tracker，打 ready-for-agent triage 标。
PRD 模板（节选）
- Problem Statement：用户视角的问题
- Solution：用户视角的方案
- User Stories：长长的编号列表，按
As an <actor>, I want a <feature>, so that <benefit>格式写；尽可能穷举 - Implementation Decisions：要建 / 改的 module、接口、技术澄清、架构决策、schema 变更、API 契约、具体交互——但不写具体文件路径或代码片段（会过时）。例外：原型生成的更精确的 snippet（state machine / reducer / schema / type shape）可内联，并标注它来自原型
- Testing Decisions：什么是好测试、要测哪些 module、prior art
- Out of Scope：明确不做什么
- Further Notes：可选
适合的场景
- 已经在长对话里把方案讨论得差不多了，要把决议落到一份可分发的文档
- 新功能的 alignment：人和 agent 都需要据同一份文档动手
- 需要把 PRD 和后续
to-issues的 vertical slice 直接接起来
何时不要用
- 还没和用户对齐就直接写 PRD：先讨论再写
- 改动只有 1–2 commit：PRD 是 over-engineering
配套
request-refactor-plan（重构类的 RFC，与 PRD 模板互补）、to-issues（PRD 落地为 vertical slice issue 列表）、triage（PRD 已发布后的 issue 状态机管理）、ubiquitous-language（PRD 的术语锚定）。
This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.
The issue tracker and triage label vocabulary should have been provided to you — run /setup-matt-pocock-skills if not.
Process
Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.
Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
- Write the PRD using the template below, then publish it to the project issue tracker. Apply the
ready-for-agenttriage label - no need for additional triage.
Problem Statement
The problem that the user is facing, from the user's perspective.
Solution
The solution to the problem, from the user's perspective.
User Stories
A LONG, numbered list of user stories. Each user story should be in the format of:
- As an
, I want a , so that
This list of user stories should be extremely extensive and cover all aspects of the feature.
Implementation Decisions
A list of implementation decisions that were made. This can include:
- The modules that will be built/modified
- The interfaces of those modules that will be modified
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
Testing Decisions
A list of testing decisions that were made. Include:
- A description of what makes a good test (only test external behavior, not implementation details)
- Which modules will be tested
- Prior art for the tests (i.e. similar types of tests in the codebase)
Out of Scope
A description of the things that are out of scope for this PRD.
Further Notes
Any further notes about the feature.