[HINT] Download the complete skill directory including SKILL.md and all related files
| name | think-plan |
| description | 当需求不清、需要方案对比或要写 spec/阶段计划时使用；产出 spec / 阶段计划，未经批准不进入实现。 |
| argument-hint | <需求描述|范围|方案问题> |
如果 $ARGUMENTS 非空，将其作为需求描述的起点。否则一次一个问题逐个深入：
UI / 前端视觉任务必须额外锁定：
DESIGN.md / 现有 theme-token / 用户提供 / 临时 contract涉及领域概念、业务术语或架构决策时，额外检查：
CONTEXT.md / CONTEXT-MAP.md 或领域术语文档；有则优先读取。待决策，不能沉默选边。复杂实现任务额外使用 REASONS-lite 自查，但不要把所有小任务强行写成 Canvas：
| 维度 | 检查点 |
|---|---|
| Requirements | 问题、DoD、Non-goals、验收标准是否明确 |
| Entities | 领域对象、术语、关系是否显式 |
| Approach | 采用什么策略、放弃了什么备选、为什么 |
| Structure | 改哪些文件 / 组件 / 边界，不改哪些 |
| Operations | 步骤是否可执行、可测试、顺序合理 |
| Norms | 项目命名、测试、日志、错误处理等规范 |
| Safeguards | 安全、兼容性、性能、不变量和回退点 |
当后续实现、验证或 review 发现现实与 plan 不一致时，优先更新 plan/spec artifact，再继续实现；不要只在代码上 patch，导致意图记录漂移。
如果发现需求跨多个相对独立的子系统，先建议拆成多个 spec，再继续设计；不要把互不相干的问题硬塞进一个方案。
已锁定 / 待决策 / 可自由裁量/think-research/think-architecture/think-quality根据问题性质选择合适的思维框架，指导后续方案设计：
| 框架 | 适用场景 | 核心动作 |
|---|---|---|
| 问题拆解（横向） | 可并行的子问题 | 按功能模块/时间/空间维度拆分 |
| 问题拆解（纵向） | 流程性问题 | 按步骤/因果链拆解，找出核心瓶颈 |
| 矛盾分析 | 多因素冲突、优先级不清、trade-off 纠缠 | 列出所有对立面 [A] vs [B] → 判定主要矛盾（解决它后其他矛盾是否缓解）→ 区分性质（对抗性=必须取舍 / 非对抗性=可协商）→ 集中力量解决主要矛盾，监控次要矛盾是否上升 |
| 拓扑关系梳理 | 复杂系统/多组件交互 | 画出组件关系，分析正向/负向依赖 |
| 类比推理 | 缺少直接经验 | 搜索相同或不同领域的类似问题解法 |
| 模型简化 | 问题过于复杂 | 提取核心矛盾，缩小规模，先解决简化版 |
| 第一性原理 | 现有方案全部失败 | 剥离经验假设，连续问"为什么"回到基本事实 |
不需要每次都显式选择——简单任务直接跳到产出 Spec。复杂任务在 Spec 中标注使用了哪个框架。
无论任务大小，输出都遵循“先让人看懂，再让人看全”的顺序：
TL;DR — 一句话目标 + 推荐方案已锁定 — 已确认的目标、边界、约束待决策 — 仍需用户拍板的问题边界 — Goals / Non-goals / Constraints方案 — 方案 A / B / 推荐与取舍领域语言 / ADR-lite — 仅在确有术语冲突或关键决策时出现风险与验证 — 最大风险、验证方式、回退点实施步骤 — 只展开到足以执行与验证的粒度不要一上来把所有抽象层、所有 trade-off、所有边角情况平铺出来；优先让读者先获得方向感。
根据任务规模自适应粒度：
出现以下任一情况时，spec 必须附 Mermaid 图：
简单单文件改动、纯局部重命名、单函数级修补不强制画图。
直接产出 Action 描述级 spec：
## TL;DR
[一句话目标 + 推荐方案]
## 已锁定
- ...
## 边界
- Goals
- Non-goals
- Constraints
## 步骤
1. [文件路径] — [操作] — [验证方式]
2. ...
先产出整体 spec（Action 描述级），再按方向拆分为独立的详细 spec：
docs/specs/
├── overview.md # 整体 spec：目标、架构、各方向概述
├── direction-a.md # 方向 A 详细 spec（含关键接口/契约/必要代码片段）
├── direction-b.md # 方向 B 详细 spec（含关键接口/契约/必要代码片段）
└── ...
每个方向的详细 spec 包含：
Spec 写完后执行检查清单：
已锁定 / 待决策 / 可自由裁量/dev-tdd涉及业务概念时，spec 必须使用项目已有术语；发现一词多义或多词同义时，放入 待决策。建议沉淀术语时使用以下格式：
**Canonical Term**:
一句话定义这个概念是什么。
_Avoid_: 旧词、歧义词
ADR 建议必须克制。只有同时满足以下三条才写入计划：
不满足三条时，不要为了“看起来规范”创建 ADR。
每个方案必须显式指认它"最脆弱的假设"——形式固定为：
If <X> does not hold, <Y> happens.
<X>：这个方案隐含依赖的某个事实（用户行为、外部 API 形状、数据规模、并发量、依赖库行为、团队约定……）<Y>：这个假设崩溃后会发生什么（功能失效 / 数据损坏 / 性能塌方 / 需要回滚 / 切换方案）每份 plan 至少 1 条 premise collapse；多方案对比时每个候选方案各自给一条。
举例：
If 用户量 < 10 万，<内存缓存方案>。If does not hold, 缓存击穿 + DB 雪崩，必须切 Redis。If 第三方 webhook 重试 ≤ 3 次，<幂等键方案>。If does not hold, 重复消费导致订单重复创建。写不出来 = 没真正想清楚方案的边界，回到第 2 节继续推。
如果两个来源 / 解释 / 文档 / 历史决策之间存在矛盾，必须先问用户哪个优先，不允许沉默选边。
触发条件（任一）：
禁止："我猜用户更倾向 A，就按 A 推方案"——这种"沉默选边"会把矛盾埋进 spec，到实现期或 review 期才爆出来，代价更高。
做法：在 spec 的"待决策"区显式列出矛盾点 + 候选项 + 推荐 + 推荐理由，等用户拍板后再继续。
将 spec 提交用户审批。未批准不进入实现。
docs/software-engineering-research/plan.mddocs/software-engineering-research/domain-language-and-adr.md/think-research/think-architecture/readable-final-answer/think-quality/dev-tdd/guard-verify 验证 → /guard-ship 交付/think-unstuck