用途：根据需求或技术设计，编写可执行的项目实施计划，定义如何落地项目，包括阶段、任务、排序、测试与里程碑。它不负责定义系统架构；若已有技术设计，则以该设计为架构依据。
主要能力与原则：计划按垂直切片组织，遵循曳光弹策略，每个阶段交付一条贯穿各层的薄而完整的切片。第1阶段始终是曳光弹：最简单、能证明架构可行的端到端流程。每个阶段都产出可部署、可演示和验证的增量；测试内嵌在各阶段，不单独设测试阶段。任务ID格式为 PREFIX-PN-NN，如 ONBD-P1-01，前缀由功能名缩写而来，整个计划内唯一。
每个阶段需包含：目标（面向用户或系统可见的能力）、垂直切片（涉及哪些层及端到端流程）、任务（含负责人与估算）、测试（本阶段验证什么及方式）、验收标准、依赖（开始前必须完成的内容）。典型阶段推进为：曳光弹、核心业务逻辑与错误处理、外部集成与异步处理、边界情况与性能、最终生产就绪（分批发布、监控验证、文档）。
使用方式：先检查 .specs/[feature-slug]/ 下是否存在上游文档；若有 TECHNICAL-DESIGN.md 则以其为准并明确引用，不重新推导架构决策；若只有 PRODUCT-REQUIREMENTS.md 则先快速扫描代码库理解既有模式与集成点；两者都没有则做一次聚焦的代码库调研，从任务描述与代码中推导范围与约束。随后通过提问补齐缺失上下文：项目/功能名称与成员、时间线与截止日期、已知约束、最简单的端到端流程、生产就绪的含义。接着确认各阶段信息，判断所需关键章节。
输出：写入 .specs/[feature-slug]/IMPLEMENTATION-PLAN.md，包含概览、实施阶段（各阶段含目标、垂直切片、任务表、测试、验收标准、依赖）、里程碑、依赖、风险，以及适用时的测试策略与回滚计划。测试策略适用于所有项目；回滚计划适用于生产部署。生成后附带摘要、缺失项说明与建议下一步。
限制：不定义系统架构；不编造缺失信息，无法回答时继续访谈；不得将测试推迟到独立阶段，也不应有纯搭建或纯基础设施而无用户可见产出的阶段；风险表应有至少3项。