核心用法
PRD-2 是一款面向产品管理和敏捷开发的文档型 Skill，核心功能在于将模糊的产品想法转化为结构化的可执行任务。用户需在项目 agents/prd.json 文件中定义产品需求文档，包含项目信息、分支名称、功能描述以及细分的用户故事列表。每个用户故事必须遵循"作为[用户]，我想要[功能]，以便[获得价值]"的标准格式，并配备具体、可验证的验收标准（如"添加 status 列并设置默认值 pending"、"Typecheck 通过"等）。
该 Skill 特别强调任务拆解的艺术：每个故事应能在单个上下文窗口内完成，避免"构建整个仪表盘"式的巨型任务。系统通过 priority 字段实现依赖驱动的执行顺序——数据库 Schema 变更优先于后端逻辑，后端逻辑优先于 UI 组件，确保构建过程无阻塞。进度追踪通过简单的布尔字段 passes 实现，配合 jq 命令行工具可快速筛选未完成项。
显著优点
人机协作友好：PRD-2 的设计哲学是让 AI 代理和人类开发者使用同一套语言。标准化的 JSON 格式使 Claude Code、Ralph 等工具能够直接解析执行，同时人类 PM 和工程师也能直观理解任务结构。
可验证性优先：与传统 PRD 中常见的"用户体验流畅"式模糊描述不同，该 Skill 强制要求验收标准必须可自动化验证，大幅降低需求返工率。
零依赖零配置：纯 Markdown + JSON 文档，无运行时依赖，不绑定特定技术栈，适用于任何语言或框架的项目。
敏捷迭代支持：通过 notes 字段记录执行观察，支持团队在 Sprint 中持续优化需求理解，形成"规划-执行-学习"的闭环。
潜在缺点与局限性
执行风险需警惕：参考文档中包含 --dangerously-skip-permissions 标志和无限循环代理执行的示例，若用户盲目复制可能导致未经审查的代码变更。尽管 Skill-card 已披露风险，但示例本身的警示性不足。
模板化思维的陷阱：过度依赖标准化格式可能抑制创新性需求的表达，某些探索性、实验性功能难以套入"用户故事+验收标准"的 rigid 框架。
版本兼容隐忧：Claude Code、Ralph 等 AI 工具迭代迅速，文档未注明已测试版本范围，未来可能出现指令格式不兼容的情况。
无内置协作功能：缺乏冲突合并、变更历史、评论讨论等团队协作特性，多人编辑同一 PRD 时需依赖 Git 解决冲突。
适合的目标群体
- AI 原生团队：已采用 Claude Code、Ralph、Amp Code 等 AI 编程助手，希望建立标准化人机协作流程的技术团队
- 产品导向的初创公司：需要快速将 MVP 构想转化为可执行任务的 Founders 和早期产品经理
- 敏捷教练与 Scrum Master：寻求轻量化、可版本控制的需求管理工具，替代 Jira/Confluence 的复杂配置
- 全栈开发者单人项目：个人开发者管理 side project 功能规划，实现"自产自销"的清晰任务追踪
使用风险说明
自动化执行风险：启用 AI 代理自动循环执行 PRD 任务时，可能产生未预期代码变更。建议始终使用独立分支或 git worktree，并在关键节点强制人工审查。
数据完整性风险：JSON 格式虽简洁但缺乏 Schema 校验，手动编辑时易出现语法错误导致解析失败。建议配合 JSON Schema 验证或 IDE 插件使用。
外部依赖失效：Skill 引用 GitHub 仓库和外部博客作为参考资源，若链接失效或内容变更，用户可能无法获取完整文档。
性能与规模限制：单个 PRD 文件承载过多用户故事时，可能超出 AI 上下文窗口限制，大型项目需拆分为多个 PRD 文件。