prd-to-plan
使用 tracer-bullet 竖向切片方法把 PRD 转换成多阶段的落地实施计划,并保存为本地 Markdown 文件(存放在 `./plans/`)。适用于用户希望把 PRD 拆分为多个阶段、生成实施计划、从 PRD 推导阶段计划,或提到 “tracer bullets”。
Best use case
prd-to-plan is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
使用 tracer-bullet 竖向切片方法把 PRD 转换成多阶段的落地实施计划,并保存为本地 Markdown 文件(存放在 `./plans/`)。适用于用户希望把 PRD 拆分为多个阶段、生成实施计划、从 PRD 推导阶段计划,或提到 “tracer bullets”。
Teams using prd-to-plan 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/prd-to-plan/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How prd-to-plan Compares
| Feature / Agent | prd-to-plan | 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?
使用 tracer-bullet 竖向切片方法把 PRD 转换成多阶段的落地实施计划,并保存为本地 Markdown 文件(存放在 `./plans/`)。适用于用户希望把 PRD 拆分为多个阶段、生成实施计划、从 PRD 推导阶段计划,或提到 “tracer bullets”。
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 转计划(PRD to Plan) 使用竖向切片(tracer bullet)把 PRD 拆分为分阶段的实施计划。输出会写成 `./plans/` 目录下的一份 Markdown 文件。 ## 流程(Process) ### 1. 确认 PRD 已在上下文中 PRD 应当已经出现在对话中。若没有,请让用户粘贴 PRD,或指出文件位置。 ### 2. 探索代码库 如果你还没有探索代码库,可以先探索以理解当前架构、既有模式以及集成层(integration layers)。 ### 3. 识别可持续的架构决策 在开始切片之前,先识别那些在实现过程中不太会改变的高层决策,并把它们放在计划的开头,方便每个阶段都能引用: - 路由结构 / URL 模式 - 数据库 schema 的形状 - 核心数据模型 - 身份认证 / 授权的方案 - 第三方服务的边界 ### 4. 起草竖向切片 把 PRD 拆成 **tracer bullet** 阶段。每个阶段都是一个薄的“贯穿式竖向切片”:它要切穿所有集成层的端到端闭环,而不是只对某一层做横向拆分。 <vertical-slice-rules> - 每个切片都要提供一条狭窄但完整的路径(覆盖 schema、API、UI、tests) - 完成的切片应当可演示或可独立验证 - 相比少数几个很厚的切片,更倾向于使用许多更薄的切片 - 不要包含那些很可能随后续阶段而变化的具体文件名、函数名或实现细节 - 但要包含“耐久/可持续”的决策:如路由路径、schema 形状、数据模型名称 </vertical-slice-rules> ### 5. 让用户确认 把你建议的阶段拆分以“编号列表”的形式呈现。对每个阶段展示: - **标题(Title)**:简短且描述性的名称 - **覆盖的用户故事(User stories covered)**:该阶段对应 PRD 中哪些用户故事 并向用户提问: - 这个粒度是否合适?(太粗 / 太细) - 是否需要合并或进一步拆分某些阶段? 根据用户反馈进行迭代,直到用户认可拆分结果。 ### 6. 编写计划文件 如果 `./plans/` 目录不存在,请先创建。然后把计划写成 Markdown 文件,文件名以功能名命名(例如:`./plans/user-onboarding.md`)。使用如下模板: <plan-template> # 计划:<Feature Name> > 来源 PRD:<简要标识或链接> ## 架构决策 贯穿所有阶段的可持续决策: - **路由(Routes)**:... - **Schema**:... - **关键模型(Key models)**:... - (按需增删章节) --- ## 阶段 1:<Title> **用户故事(User stories)**:<从 PRD 提取的列表> ### 需要构建什么(What to build) 对该竖向切片的简洁描述。描述端到端的行为,而不是按层逐一解释实现方式。 ### 验收标准(Acceptance criteria) - [ ] 验收点 1 - [ ] 验收点 2 - [ ] 验收点 3 --- ## 阶段 2:<Title> **用户故事(User stories)**:<从 PRD 提取的列表> ### 需要构建什么(What to build) ... ### 验收标准(Acceptance criteria) - [ ] ... <!-- 为每个阶段重复 --> </plan-template>
Related Skills
request-refactor-plan
通过用户访谈创建一个详细的重构计划,并将其拆分成很小的提交(tiny commits),最后以 GitHub issue 的形式归档。适用于用户希望规划一次重构、创建重构 RFC,或把重构拆成安全的渐进步骤。
write-a-skill
以正确的技能结构、渐进式披露与打包资源来创建新的 agent 技能。适用于用户希望创建、编写或构建新的技能。
write-a-prd
通过用户访谈、代码库探索与模块设计来编写 PRD(产品需求文档),然后以 GitHub issue 的形式提交。适用于用户希望编写 PRD、创建产品需求文档,或规划一个新功能。
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(先写测试)”。
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(把它设计两遍)”。