用途
walking-skeleton-plan 用于将一份已批准的 spec 转换为结构化的实施计划，输出到 docs/<slug>-plan.md。计划面向后续的执行流程，强调以小步、可集成、可测试的方式推进开发。
主要原则
- 第 1 步是行走骨架：让规格的主路径端到端运行（例如"客户下单，系统保存订单，订单列表显示该订单"）。主路径所经过的每一层都取最小值（如数据、逻辑、接口、测试），并作为基础保留在代码库中。
- 一步一项能力：每个步骤只增加一件事，例如取消订单、校验、编辑、删除或一个配置项。
- 始终集成：每个步骤结束时项目可构建、主路径可用、完整测试套件通过。
- 无孤儿代码：步骤中新增的每个函数、表、依赖和模板都必须在同一步骤内有调用方。
- 可测试：每个步骤都说明完成时可测试什么，包括自动化测试和一次手动检查。
- 一个功能：步骤不等于功能，整个计划在功能所在分支上运行（git-commit-organizer），每步一次提交。
排序规则
- 先做行走骨架。
- 其次做会改变后续所有步骤形态的事项，例如在返回错误的首批端点之前先定好 API 错误格式，使之后所有端点从一开始就使用它。
- 然后逐项功能，一步一个。
- 再做不改变公开接口的加固，例如限流、安全设置、配置。
- 样式与最终文档审查放在最后。
计划中需写明排序决策，便于用户提出质疑。
输出格式
docs/<slug>-plan.md，采用 simplified-technical-language 的文档语言，包含：标题"<Feature> Implementation Plan"、规格与分支信息表格、按步骤列出名称与覆盖的验收标准的概览表，以及各步骤（如 Step 1 - Walking skeleton）的 Adds 与 Can be tested when done 说明。
覆盖检查
每条验收标准必须在概览中至少出现一次，并要求用脚本核对而非目测，脚本示例如资料所提供的循环 grep 检查。仅被部分覆盖的标准需标注，并指出完成它的步骤。
完成
提交计划（git-commit-organizer）；在聊天中按阶段分组展示步骤列表与排序决策；如用户用工具跟踪工作，可提供 work-items-breakdown；在开始 execute-plan-loop 前必须先询问用户。