| name | product-dev |
| description | Use for product development work from PRD to implementation: make technical decisions, stress-test plans, document ADRs or spike/POC findings, break down engineering work, plan files/modules, implement code changes, use TDD when practical, debug issues, review changes, and verify completion. Use when the user asks to build a product feature, turn requirements into development tasks, challenge a technical plan, choose an architecture or technology approach, summarize a technical spike, implement a change, fix a bug, or complete engineering verification. |
Product Dev
用于把“要做什么”拆成“研发如何决策、交付和实现”，并在需要时记录技术方案、总结 spike/POC、指导编码、调试和完成验证。这个 skill 不创建工单、不操作外部项目管理系统、不调度真实多 agent。
何时使用
- 已有 PRD、产品范围、技术约束、设计/测试输入或团队上下文。
- 需要把功能拆成阶段、角色、任务、依赖、交付物、实现要点和验证标准。
- 需要在研发方案设计时记录技术选型、ADR、spike/POC 结论、方案取舍和后果。
- 项目涉及前端、后端、数据、测试、运维、内容等多个研发工作域。
- 需要在编码前明确研发路径、文件/模块影响范围、测试方式和协作边界。
- 需要实际实现代码、修复 bug、按 TDD 推进、调试失败测试或完成前做新鲜验证。
不用于极小个人任务，也不用于替代项目管理系统。
执行方式
- 盘点输入：目标、范围、已有材料、技术约束、角色分工、时间要求、风险。
- 判断是否需要技术决策记录：存在关键技术选型、架构边界、不可逆方案、POC/spike 结论时，先使用 ADR、technical spike 或 decision review reference。
- 识别工作域：前端、后端、数据、测试、运维、内容等；只保留真实需要的研发角色。UI 界面实现可作为独立输入或并行工作流处理，不在这里展开视觉方案。
- 拆阶段：每个阶段交付一个清晰里程碑，避免人为制造过多阶段。
- 拆任务：每个任务必须有 Objective、Output、Validation、Guidance、Dependencies、Steps。
- 建依赖：只写直接依赖；可并行任务明确分组。
- 标人工确认点：范围确认、关键技术选择、设计确认、上线验收、外部凭据或发布动作。
- 补实现要点：对需要编码的任务，列出可能影响的文件/模块、接口、数据、测试方式和预期验证。
- 执行编码任务：需要实际改代码时，按实现、调试和完成验证 references 执行。
- 收尾交接：说明哪些任务已实现，哪些还缺输入或验证。
路由
| 场景 | 读取 |
|---|
| 技术选型、架构方案、ADR、关键决策记录 | references/architecture-decision.md |
| 技术预研、POC、spike 总结、可行性结论 | references/technical-spike.md |
| 方案上线前追问、隐藏假设、分支取舍审查 | references/decision-review.md |
| 研发拆解、阶段、任务、依赖、角色交接 | references/product-dev-template.md |
| 实际编码、变更实现、TDD、小步提交前检查 | references/implementation.md |
| Bug、失败测试、回归、异常行为 | references/debugging.md |
| 完成前评审、验证、交付说明 | references/review-and-finish.md |
输出格式
做研发计划时使用 references/product-dev-template.md。实际编码、调试或收尾时只读取对应 reference，不一次加载所有材料。
边界
- 不重写完整 PRD，只摘要影响研发拆解的目标、范围和约束。
- 不把 ADR 或 spike 写成冗长架构论文；只记录决策边界、证据、取舍、后果和下一步。
- 可以写文件/模块级实现要点和测试建议；实际改代码后，必须报告真实执行过的验证。
- 只有在用户任务明确要求实现或修复时才修改项目文件；不自动创建 issue、提交代码或操作外部系统。
- 不把所有传递依赖都写进依赖图，只标直接阻塞关系。
- 信息不足时，输出假设和待确认项，不编造技术事实、团队角色或时间承诺。
质量检查
- 阶段是否对应真实交付里程碑。
- 任务是否有清晰 Objective、Output、Validation、Guidance、Dependencies、Steps。
- 依赖是否只包含直接依赖。
- 可并行任务是否被明确标出。
- 验证标准是否任务级可判定。
- 人工确认点是否清楚。
- 关键技术选择是否记录了备选方案、证据、取舍和后果。
- 交接说明是否能支持下一步编码执行。
- 代码实现是否遵守现有项目模式。
- 完成声明是否有本轮新鲜验证证据。
