用途：把已验证的软件需求包转成可执行的交付计划，供团队执行与检查。规划阶段不重新发明产品行为，也不编写代码。若来源只是粗略需求或含糊请求，建议先用 krt-requirements-weaver 生成需求包。
主要能力：确认规划来源；评估规划就绪度；选择规划形态——迭代交付、范围多变或强调增量价值时用敏捷待办列表，小而固定或按阶段推进时用阶段式计划，需要明确里程碑又要在各阶段内增量交付时用混合计划；拆分主要交付物或工作流并排序；定义范围与非目标、优先级、时间线大纲/里程碑/迭代切片、负责角色或团队形态、技术选择或约束、依赖、风险与缓解、部分交付；验证每个主要任务可追溯到需求、约束或风险。
使用方式：开始前加载 references/safety.md，规划前加载 references/planning-workflow.md，评审计划时加载 references/plan-quality-checklist.md，被问及方法依据时加载 references/source-literature.md。检查来源是否包含问题与目标、相关方或参与者、范围与范围外、功能需求、非功能需求或明确约束、假设与开放问题、验收标准或其他可测试的完成线。缺失关键输入时应停止，输出 planning-readiness-note，而非凭空生成计划。
适用场景：已有需求包、需要把需求拆成可执行交付计划的团队；需要选择敏捷、阶段式或混合交付形态的项目；需要识别依赖、风险、角色与增量交付安排的规划工作。
限制：不得在规划中悄悄扩大范围；待办项应反映交付价值或需求切片，不能是随机任务清单；未知日期或时长应使用相对顺序而非虚假精确；推测性日期不得当作承诺；未知事实，如具体价格、平台支持、团队规模或效果，暂未提供。默认输出 delivery-plan 或 planning-readiness-note，写入仓库时使用相对路径。若用户只要求分析，则返回发现与建议的规划形态，不写文件。最终输出包含 artifact_kind、planning_status、规划来源、交付方法、关键计划要素、风险/阻塞与下一步。