定位与状态
plan-report 是一个帮助用户产出「框架计划报告」的技能，文档类型位于「项目章程」和「详细设计」之间。需要特别说明：该技能已于 2026-07-27 退役，全部能力已并入 issue-pool，框架计划七步流程见 issue-pool/references/plan-writing.md。任何「写计划报告 / 框架计划 / 项目计划 / v1.0 计划 / 版本路线 / 阶段方案」的需求，应改用 issue-pool。
它回答与不回答的问题
它回答：为什么做 / 做到什么程度算完 / 谁用它 / 不做什么 / 分几步走 / 每步停下时业务能问出什么。
它不回答：字段、接口、技术栈、目录命名、cron 表达式——这些属于后续「详细设计文档」。
核心原则
- 先实证再设计：不要凭空推演，先把现状摸清楚。
- 文档类型决定一切：拿到诉求先判断这是哪类文档（项目章程 / 框架计划 / 业务说明 / 详细设计 / PRD），类型错位会让后续努力打折扣。
- 状态描述 > 动作描述：总体目标和验收都用「能 X」句式，状态描述本身就是验收标准。
- 拆版本，不堆功能：每个版本只解决一个主问题。
- 用验收反推交付：先问「怎样算这个阶段完成」，再倒推该交付什么。
- 不做项必须配理由：防 scope creep 的关键武器。
- 始终为读者服务：整篇文档应让完全没接触过项目的人理解项目为什么成立、做到什么程度算完、是否对他有用。
工作流程（7 个阶段）
- Stage 1 摸现实：动笔前摸清现状。含 Step 0 规模快筛，两个判断题——预计耗时（<1 周 / 1-6 周 / >6 周）与可拆独立交付阶段数（1 个 / 2-3 个 / 4+ 个），据此决定退出或用小项目 / 标准骨架。含硬门与信息深度自检；信息不足时按「卡住产出格式」输出待补问题，禁止用「据我理解」硬补。
- Stage 2 定文档类型：确认写的是「框架计划」，否则提示换技能。
- Stage 3 搭骨架：框架计划固定骨架为「定位 → 痛点 → 边界 → 阶段 → 验收」，展开为标准版 10 节，并按项目规模自适应行数。
- Stage 4 填每节内容：按 4 原则落字（先定是什么 / 不是什么、找痛点不说「要做 X」、拆版本不堆功能、用验收反推交付）。
- Stage 5 每个版本用统一三段式：要解决的问题 / 主要交付 / 阶段验收，并按项目类型选择验收句式。
- Stage 6 语言精修：按 5 个替换写法逐节扫一遍。
- Stage 7 自检 + 落盘：做读者视角自检，默认路径 docs/plan/{版本号}-{命题}-{项目名}.md，并同步生成 HTML。
模板
技能提供两套模板：小项目骨架（8-9 节，适用 1 人 1-6 周 / 工具类 / 单团队内部使用）与标准骨架（10 节，适用 1 人 >6 周 / 多人协作 / 4+ 阶段 / 跨团队消费 / 有上层架构基线）。所有阶段必须用统一三段式。
md → html 转换
tools/ 子目录提供 md2html.py 脚本和 style.css。
安装依赖（一次性）：pip3 install markdown
使用：python3 .claude/skills/plan-report/tools/md2html.py docs/plan/v1.0-框架-{项目名}.md
输出会在 md 同目录生成同名 .html。样式由 tools/style.css 控制，脚本会自动找到同目录的 style.css，也可用 --css 参数指定其他样式表。
适用场景
- 新项目立项后第一份「做什么」文档
- 已有项目的大版本规划
- 多阶段迁移计划
- 内部工具的演进路线
不适用场景
- 详细设计文档、PRD / 需求文档、业务说明、拜访 / 分享大纲、周报 / 工作汇总、客户共识会准备
- 项目规模太小（1 周内的脚本改造 / bug 修复 / 小调整），或不需要分阶段的一次性交付项目
限制
该技能已退役，实际使用时请改用 issue-pool。价格、平台、效果等其它信息暂未提供。