planning

规划

制定尽可能精简的计划，以降低实施风险并保留重建成本高昂的状态。用户需求和已核实的事实决定计划；参考实现只提供行为证据，无权自行改变范围。

流程

1. 明确具体成果、证据、二元或量化的成功阈值、范围边界和停止条件。如果请求已经指出产物和成功信号，就采用这些内容。否则，应先修正仅描述活动的目标，再开始规划。
2. 将目标与建议的实现机制分开：即使实现方式改变，目标是否仍然成立？确保同事无需了解组件内部情况，也能单独理解目标并验证目标是否达成。
3. 对于存在相互依赖阶段、需要恢复工作或跨越上下文限制的任务，选择完整的持久化计划；对于清晰且能在一个会话内完成的工作，使用行内列表；对于范围和验收标准明确的工作，直接实施。文件数量和工具调用次数只是参考信号，不是触发条件。将缓存 TTL、失效机制和键结构等隐藏决策检查清楚后，再将工作视为简单任务。
4. 检查现有测试、规范命令、相关代码以及任何现有的头脑风暴规范。沿用仓库模式。必要时，按照项目的 ADR 规范记录重要的架构权衡。
5. 明确文件、责任归属、接口约定、依赖关系、具体任务、验证方式和退出条件。围绕可运行的能力组织阶段，将实现和测试放在一起。先处理决策差异较大的事项；按阶段顺序保持执行依赖关系。
6. 根据用户需求核对计划。确保阶段状态与后续步骤一致。切勿为了迁就尚未完成的代码而降低验收标准，也不要增加推测性的检查和机制。
7. 如果用户只要求规划，就交付计划。如果已获授权实施，则继续实施。只有当执行方式会显著影响成本、风险、隔离性或审查质量时，才询问执行模式。

持久化状态

制定完整的工作计划时，请阅读 plan-format.md，并使用 init-plan.sh 创建初始计划；定位时应以已安装的技能目录为准，而非调用方的工作目录。如果项目已采用规范或计划系统，则保留该系统的产物格式；技能负责澄清、内容和审批关卡，而非产物的表现形式。否则，未提交的会话状态使用 .plan/task_plan.md，正式提交的计划使用 docs/plans/。

覆盖现有计划前先进行检查。继续在原处推进同一项工作；如果不同工作会取代尚未勾选的任务，则先询问应以哪个计划为准。绝不要悄悄丢弃或批量关闭未完成的工作，包括跟踪器条目。只有在解决该选择后才能使用 --force。仅当用户要求额外交付物，或主计划无法清晰表达状态时，才添加辅助产物。

条件式指导

• 对于模糊目标、伪装成目标的拟议机制，或规划深度的选择，请阅读 goal-definition.md。
• 对于完整计划、模板、测试发现、源代码指引、接口选择或计划质量审查，请阅读 plan-format.md。保留规范中的精确值，并在每项任务中写明具体路径或命令。
• 在拆分阶段、明确负责人或决定需要澄清的事项时，请阅读 task-design.md。选择技术细节前，先尊重用户已有的选择和项目约束。对于结果存在实质差异或权限缺失的情况，应升级处理；常规实现选择由实现者决定。
• 对于垂直切片、检查点、参考语义、阶段执行方式或委派执行，请阅读 execution-and-methodology.md。
• 开始多阶段工作或间隔一段时间后恢复工作时，请阅读 operational-patterns.md，了解恢复、上下文检查和错误处理。
• 深化现有计划时，请阅读 plan-deepening.md；保留其结构，并补充有针对性的研究。
• 选择执行方式、交接工作或整合相关技能时，请阅读 execution-handoff.md。

权限与验证

当当前运行环境的提问工具所需的架构和上下文允许时，请使用该工具；否则请在聊天中提问。将重要未知事项合并提问，对常规细节作出安全假设，切勿捏造问题数量。

确认每项任务都以动词开头、具体、可独立验证，且无需对话历史也能理解。检查各任务之间的命名和接口是否一致。每个阶段都需要包含可运行的能力、明确的验证方式，以及不依赖上下文的恢复边界；流程类事项必须指出其所约束的能力或已观察到的缺陷。开放问题只能包含阻塞性未知事项。计划文档本身并不能证明实现已有进展。

对于有歧义的需求，请使用 ia-brainstorming；对于新的信任边界、身份验证、支付或外部 API 等重要事项，请在实施前进行适用的安全威胁模型审查。撰写文案时请使用 ia-writing。报告计划位置、重要决策和剩余阻塞事项，不要声称尚未执行的检查已通过。