| name | lightweight-design |
| description | 轻量设计方案 skill（用户级通用）。为单次局部修改任务编写"任务级 L5/L6"——用决策海拔锁死本次要改什么、怎么改的业务逻辑与关键技术取舍。它是用户审核层与施工期局部临时真值：用户在此拍板，AI 据此（或据此生成的施工蓝图）施工，完工后回补七层文档。 |
轻量设计方案
本 skill 是任务级详细设计的决策层，用户级通用，可跨项目使用。
它解决的问题：实际开发中大量任务是局部修改，不值得（也不应该）每次都重写整域的 L5/L6 文档；但只拿需求直接开工，AI 干着干着就会跑偏。轻量设计方案就是补在中间的那一层：
作用 = L5/L6 的任务切片版：钉死本次修改的业务逻辑与关键技术实现，人和 AI 都看得懂；用户在这一层审核拍板，施工期它就是局部真值，完工后回补七层。
与施工蓝图（construction-blueprint skill）的海拔分工：
轻量设计方案 ── 决策海拔 ── 人看的，用户审核拍板（本 skill）
↓
施工蓝图 ────── 代码海拔 ── AI 看的，开工前对抗评审
↓
施工 → 回补七层文档
1. 什么时候用 / 不用
用（满足任一即考虑）：
- 局部功能开发、局部重构、单链路改造，且存在需人拍板的决策点
- 任务跨多个文件/模块，直接开工容易范围蔓延
- 用户明确要求"先出设计方案再动手"
不用：
| 场景 | 改用 |
|---|
| 小改动（修 bug、加字段、单文件小改） | Claude Code 计划模式，零文档成本 |
| 整域级设计 / 新域立项 | 直接写七层正式文档（L1~L7） |
| 纯执行、无决策点的机械任务 | 直接做 |
| 跨会话、多 agent 的超大任务 | task-control-doc 总控 + 每个专题各自走"轻量设计 → 蓝图" |
2. 生命周期（六态）
起草 → 冲突检查 → 用户拍板 → 施工期临时真值 → 完工回补七层 → 归档降级
| 阶段 | 硬规则 |
|---|
| ① 起草 | 输入 = 需求 / 聊天确认 / 现存七层文档 / 代码摸底 |
| ② 冲突检查 | 起草时必须与现存七层文档核对；发现不一致按 doc-layer-system §2 三级分级走人工裁决，禁止 AI 自行选边。轻量设计不得越权推翻 L1 / L2 / L3 正式真值 |
| ③ 用户拍板 | 唯一必经的人工闸。用户在此层验收设计，拍板后决策冻结；后续施工不得自行重裁 |
| ④ 施工期临时真值 | 施工 AI 只看本文档（或据它生成的施工蓝图），不需要翻整域七层文档；与七层冲突的部分以本文档为准（因为②已裁决过） |
| ⑤ 完工回补 | 按文档内"影响面与回补清单"把正式承诺同步回七层（接口→L3、表→L4、核心决策→L5/L6、测试→L7） |
| ⑥ 归档降级 | 回补完成后在文档头部显式标记"已回补，本文档失效"，防止与七层形成两套真值 |
3. 写作规范（直接继承 L5/L6 写作规范）
本 skill 的写作海拔与 doc-layer-system §5.5/§5.6 及其 references/L5L6写作指南.md 完全同源：
- 决策锁死三件套：每个决策点写清 选了什么 / 放弃了什么 / 为什么
- 海拔规则：只写到决策/意图海拔；判定句——"这句话删掉、读者直接看代码反而更准，它就超标了"
- 试金石：「不写下来的话，一个有能力的 AI 施工时，会不会做出一个看起来合理、但和已拍板结果不同的选择？」会 → 进文档；不会 → 不写
- 精炼 ≠ 含糊：每个决策点必须锁死到唯一选择，禁止"采用合适的策略"式模糊措辞
- 锚点制：标识符（类名/表名/字段名）每个论点至多一个，仅供定位
- 禁止：代码、伪代码、逐方法调用链复述——这些属于代码海拔，归施工蓝图
与 L5/L6 正式文档的唯一区别：范围是本次任务切片，不是整域；且生命周期是临时的（完工回补后失效），而 L5/L6 是长期真值。
4. 文档模板
# 轻量设计方案：{任务名}
> 状态：草稿 / 已拍板 / 施工中 / 已回补失效
> 真值基线：{依据的七层文档 / 用户决策 / 代码摸底}
## 1. 背景与意图（3 行内：为什么改、改成什么样）
## 2. 范围与非范围
本次改：…
本次明确不改：…（负面清单要硬，不许模糊）
## 3. 决策表 ★核心章节
| 决策点 | 选定 | 放弃 | 为什么 |
|---|---|---|---|
（有几个需人拍板的点就写几行，不设上限；逐条过试金石）
## 4. 业务规则与状态流（如有）
表格 / 状态图；规则用业务语言，不用字段清单代替
## 5. 关键技术实现（决策海拔）
事务边界 / 缓存策略 / 幂等 / 同步异步 / 并发处理 等取舍
每条至多一个代码锚点
## 6. 影响面与回补清单
完工后要回补哪几层、哪几份文档（逐份点名）
## 7. 风险与待确认
阻塞级（必须先决策，未决禁止进入蓝图/施工）vs 非阻塞（可延后）
5. 审核与下游衔接
- 拍板点：第 3 节决策表 + 第 2 节负面清单是用户审核的主靶面；用户确认即冻结
- 下游：拍板后据本文档生成施工蓝图（
construction-blueprint skill）；蓝图的"验收映射"章节必须把本文档每个决策点映射到具体变更条目
- 施工中决策变更：施工中发现已拍板决策需要改 → 退回本层重新拍板，不允许在蓝图或代码里悄悄改
6. 项目补丁挂载点
以下内容由各项目的项目级补丁声明（如项目的七层补丁 skill 或项目 CLAUDE.md）：
| 挂载项 | 内容 |
|---|
| 存放路径 | 本文档与施工蓝图的统一任务目录 |
| 红线对照 | 项目工程红线 / 域边界规则，起草时逐条对照 |
| 死亡线升级 | 命中项目死亡线区域时的评审升级规则（如 ask-opus / adversarial-review） |
| 回补钩子 | 完工后的文档同步规则与检查脚本 |
7. 质量自检清单
