用途：把一个大型或含糊的项目拆成带显式依赖的任务列表，并输出 Mermaid 依赖图和关键路径分析。它只有两种可能输出：完整计划（Phase 0-4），或当范围未通过 Step 0.2 门槛时只给澄清问题，两者不会出现在同一轮。
主要能力与流程： Phase 0 项目分析：先用 Explore 代理（model: haiku）读取 CLAUDE.md、README.md，识别项目类型、组件模块、技术栈、约定与相似已完成的特性。Step 0.2 范围门槛：若请求没有点明具体交付物和大致边界（如“改进这个应用”），则停下，只给 2-3 个澄清问题，不产出任务拆分、TaskCreate 调用、Mermaid 图或文件。若交付物清楚但缺次要细节（时间线、技术栈偏好、团队规模），可提问并标注假设后继续。 Phase 1 任务拆分：拆成 3-7 个里程碑，再在每个里程碑下建任务，粒度目标为每任务 2-8 小时。 Phase 2 依赖映射：为每个任务确定前置（blockedBy）、被阻塞关系与可并行项，用 TaskUpdate 的 addBlockedBy 记录。 Phase 3 可视化：只有所有 blockedBy 记录完毕后，才机械地按每条记录生成一条 Mermaid 边，并沿同样的边计算关键路径，最后双向自检（每条边对应一条记录，每条记录对应一条边）。 Phase 4 进度跟踪：用 TaskList 展示计划，随实现推进用 TaskUpdate 更新 in_progress/completed，外部阻塞写进 metadata 并用 AskUserQuestion 暴露。
可移植性：环境没有 Task/TaskCreate 工具时，自行分析而非委托 Explore 代理，并用普通 markdown 清单（- [ ] 任务名，blocked by: ...）跟踪任务。在评测或沙箱运行中，不要调用真实的 Task/TaskCreate/TaskUpdate/TaskList 工具；若要求把调用记录写入文件（如 outputs/tasks.json），则改为写文件。
使用示例：project-planner Implement user authentication with OAuth2 and JWT；project-planner Refactor payment module to use strategy pattern 等。
限制：时间估算仅在用户提供估算时才给出，不虚构时长；图表与关键路径必须来自记录数据而非记忆；范围门槛不通过时不得软化处理为“先假设再继续”。依赖结构非简单链式时参考 references/dependency-shapes.md。