用途：把模糊的产品想法收敛为范围清晰的规格，并将已有规格拆解为原子任务和可演示的冲刺计划。支持两种模式：访谈模式用于深入追问技术实现、界面与体验、顾虑与权衡，直到问题能用一句话描述；冲刺拆解模式用于读取规格，生成任务与冲刺分组。
适用场景：用户只有粗略产品计划需要定范围；需要梳理实现细节与取舍；规格已就绪需要拆分；或希望在建前验证问题是否被正确定义。
文档管理：先搜索项目已有规格再决定新建或更新。同一核心问题仅细化或转向实现时，更新原文件并改名为当天日期、更新元数据；问题定义根本改变时才新建。输出目录优先扫描 specs/、planning/、docs/specs/、product/，找不到则默认使用 specs/；若在外部库，检查 agents.md 或 claude.md 的覆盖配置。命名格式为「语义名称 - YYYY-MM-DD.md」，如 Checkout flow spec - 2024-03-25.md、Checkout flow sprints - 2024-03-25.md。文件需含 frontmatter（status、last）与必需上下文说明，底部维护 Changelog，仅记录重大变更。
冲刺拆解原则：任务须原子、可独立提交评审合并；小任务组合成清晰冲刺目标；每个冲刺产出可运行、可测试、可在其上继续构建的软件；每项任务给出明确验证标准（测试或具体验证方式）；依赖优先；固定时间、可变范围；预留约 10-20% 产能用于降险，如探针、调研或验证。任务使用稳定 ID（T1、T2），关联规格章节以保持可追溯，并显式标注依赖。
流程：访谈模式先读计划文件，持续深挖，直至问题框架清晰、关键风险浮现，再写入规格，理想情况下规格可被描述为不超过 9 个主要组件；冲刺模式先通读规格、划分可追溯章节，建任务登记表，再分组冲刺，并按任务大小、循环依赖、验证标准、完成定义、演示场景等自检，必要时可用子代理以全新上下文复核，最后将计划写入与规格同目录的 markdown 文件。
限制：明确不做时间估算，由人补充时间线；除明确要求且有足够上下文外，不分配任务给人员或角色。输出具体格式可依项目调整，小型项目用简单列表即可。该资料暂未提供平台支持、收费、价格或其他使用限制。