construction-planlisted

# 施工规划文件生成器（Construction Plan） **版本：v1.1.0**（变更记录见仓库 README 的 Changelog；生成的 PLAN 文件头部会带模板版本号） 把一份任务来源（审查报告 / TODO 清单 / bug 列表 / 用户口述的多项任务）整理成一份**可跨对话接力执行**的施工规划文件。核心机制：一个对话只做一个工作包（WP），做完勾选 + 写交接日志 + 关对话，下一个 WP 新开对话——靠文件续接，不继承上下文。 ## 语言规则（全局） - **输出语言跟随用户输入语言**：用户用中文 → 生成的 PLAN 文件、汇报、日志全部中文；用户用英文 → 全部英文；其他语言同理。 - 代码标识符、命令、文件路径一律保留英文原文。 - 本 skill 指令自身用中文编写，仅用于指导 AI，不构成对输出语言的限制。 ## 何时使用 - 用户说：做施工文件 / 施工规划 / 开工规划 / 把任务编成工作包 / 做成 FIX-PLAN 那种 / 一个对话一个任务 / 按顺序接力做 / construction plan / work packages - 用户给出 ���4 项任务的清单或报告，且明显一个对话做不完 - 用户担心上下文过长，要求把任务落到文件里分次做 ## 何时不用（禁忌症） 开工前先对照，命中任一条就**不要生成施工文件**，直接告诉用户理由并给出更轻的做法： - 全部任务一个对话内做得完（约 1 小时工作量、改动 ≤3 个文件）——直接做，套这套机制的开销比上下文损失还大 - 任务少于 4 项且彼此独立——逐条做即可 - 纯调研 / 问答，不产生代码改动——没有施工可言 ## 工作流（按顺序执行） ### 第一步：读项目约定 读项目根目录 CLAUDE.md（没有就跳过），提取三样东西： 1. **红线清单**——必须先问用户才允许的操作���如改安全配置、数据结构变更、删大段代码、git 强制操作、生产发布），用于给工作包打 🔴 标记 2. **验证命令**——语法检查、测试套件、启动方式，用于写「验收」和「整轮验证清单」 3. **沟通约定**——语言、结论先行等；若项目未指定，按上方「语言规则」跟随用户 ### 第二步：拆工作包 把任务拆成工作包（WP01、WP02…；功能升级类可用 UP 前缀、修复类 FIX 前缀，与项目既有文件呼应），规则： - **一包 = 一个对话能做完的量。尺子是「要���的文件数 × 陌生程度」，不是代码行数**——吃上下文的是阅读和理解，不是敲键盘。参考线：小包 ≤3 个文件；中包 4~8 个文件或约 250 行；超过就拆 a/b。 - 复杂包可前置一个**只读侦察包**（只调研出方案、零代码改动），实施包引用其结论。 - 同一文件域的相邻任务尽量并包，减少新对话重复读文件。 - **排序**：小而安全的在前 → 红线项居中（需用户拍板，不卡住前面的活）→ 大重构 / 拆文件放最后（它搬动一切，必须等功能全部落定）。 - 标依赖：某包必须在另一包之后做的，写进总览开头的一段话里。 ### 第三步：标红线 对照第一步的红线清单逐个 WP 检查，命中即在标题加 🔴，并在包内固定写一句：**开工前先把方案发用户确认，批准后才动手**。项目无红线清单时用通用默认：安全/权限配置变更、数据结构迁移、删除超 50 行代码、git 强制操作、生产发布。 **执行期红��守则**（写进每个 WP 的注意事项或会话纪律）：实施中若发现计划外的红线触