plan-in-files 是一个面向多步骤工作的文件化规划工作流技能，适用于涉及多个步骤、多个文件或跨会话的任务，例如重构、迁移、多文件功能开发等需要避免因上下文丢失而重做的工作。
核心行为：在开始多步骤工作前，先把计划写入磁盘；执行过程中持续更新该文件，使文件成为进度的唯一可信来源，而非记忆或聊天记录。
文件存放：一次性工作默认放在仓库根目录的 PLAN.md；若仓库保留计划历史，则放在 docs/plans/<yyyy-mm-dd>-<topic>.md。是否加入 gitignore 或提交，先询问一次，之后遵循仓库惯例。
计划结构：包含标题、目标（一句话，用用户的原话）、完成条件（可观察的结束条件）、约束（必须保持成立的事项，如不破坏 API、不新增依赖、当天发布）、步骤（每步是对具名文件的一个动作或一条具名命令）、笔记（发现、坑点、被证伪的假设）和日志（日期时间与记录）。步骤需具体，例如“把 verifyToken 从 api/auth.ts 移到 lib/token.ts 并更新三处导入”，而非笼统的“重构认证层”。
使用方式：先写计划，工作量大或具破坏性时先给用户看；一次只做一步；每完成一步立即在文件中勾选，而非等到最后；现实与计划冲突时修改计划；遇到意外随时追加到 Notes；完成后在日志写一行收尾记录并保留文件，作为代码形态成因的记录。
恢复已有计划时：先读文件，再用 git log、git diff 和运行测试核对已勾选步骤是否真实完成，纠正不实记录，然后从第一个真正未完成的步骤继续。
规则：未经验证不得勾选；不得伪造进度；计划保持在一页以内；一步若实为五步，先在文件中拆分再继续。
不适用场景：单文件编辑、一行修复、提问等简单任务。判断标准是：如果丢失会话会导致超过五分钟的返工，才值得写计划文件。