编写计划 概述 为一位没见过这个代码库、也没见过这份规格的工程师编写实现计划。假设他们一旦知道确切的接口和确切的测试，就能用项目所用的语言写出地道的代码；也假设在计划留出选择余地的地方，他们会做出合理的选择。他们无从知道的，是你已经决定了什么：哪些文件、哪些名字和签名、规格里的哪些取值、哪些测试证明每个任务。把这些记下来。将整个计划拆成小步骤任务。DRY。YAGNI。TDD。频繁 commit。 开始时宣布： "我正在使用 writing-plans 技能创建实现计划。" 上下文： 此技能应在专用 worktree 中运行（由 brainstorming 技能创建）。 计划保存位置： - （用户对计划位置的偏好优先于此默认值） 范围检查 如果规格涵盖了多个独立子系统，它应该在头脑风暴阶段就被拆分为子项目规格。如果没有，建议将其拆分为独立的计划——每个子系统一个。每个计划应该能独立产出可工作、可测试的软件。 文件结构 在定义任务之前，先列出将要创建或修改的文件以及每个文件的职责。这是锁定分解决策的地方。 - 设计边界清晰、接口定义良好的单元。每个文件应有一个明确的职责。 - 你对能一次放入上下文的代码推理得最好，文件越专注你的编辑越可靠。优先选择小而专注的文件，而非承担过多功能的大文件。 - 一起变更的文件应放在一起。按职责拆分，而非按技术层级拆分。 - 在现有代码库中，遵循已有模…