think

name	think
description	开工前澄清需求、列 Non-Goals、给候选方案。任何超过 30 分钟、跨多文件、或语义不完全清晰的任务，开始前必须执行；避免 Agent 抱着模糊的理解直接动手。

/think · 开工前的需求澄清与方案设计

使用场景

任一条件满足就用：

• 预计耗时超过 30 分钟
• 涉及跨模块改动
• 用户需求描述模糊或可多种解读
• 涉及业务规则、状态机、不可逆操作

允许用户主动说"跳过 think 直接做"，但跳过的责任由用户承担。

目标

在动手之前，把"我究竟要解决什么问题"、"边界在哪里"、"怎么验证完成"先讲清楚，让 Agent 进入 planning mode——Agent 默认会立刻动手，而企业场景下"立刻动手"几乎等于"立刻偏题"。

必须步骤

1. 复述目标

用一句话总结用户的需求。如果发现自己复述不出来，立即向用户确认，不要继续。

2. 识别 Non-Goals

列出至少 2 条"本次明确不做"的事情。如果列不出，说明 scope 还不够清晰。

3. 影响范围分析

• 涉及哪些模块 / 服务 / 文件？
• 是否触及 .qoder/business-logic/ 中已沉淀的领域规则？相关哪几篇？
• 是否有上下游消费者会受影响？

4. 方案对比

至少给出 2 个候选方案。每个方案列出：

• 优势
• 风险
• 实现成本（粗估）

最后给出推荐选择与理由。

5. 验证标准

本次任务"什么算完成"？至少包含 1 条可执行的验证命令或观察方法（不要写"看起来对就行"）。

6. 风险与回滚

列出至少 1 个潜在风险与对应的兜底方案。

禁止事项

• ❌ 不允许跳过"复述目标"——这是检测是否真的理解需求的关键
• ❌ 不允许只给一个方案——单方案等于没有选择，反映思考深度不足
• ❌ 不允许把"不知道"包装成方案——信息不足时明确列出"需要澄清的问题"
• ❌ 在 plan 未经用户确认前，不允许动手写实现代码

输出格式

## Goal
（一句话目标）

## Non-Goals
- ...
- ...

## 影响范围
- 涉及文件：...
- 相关 business-logic：...

## 候选方案

### 方案 A：...
- 优势：
- 风险：
- 成本：

### 方案 B：...
- 优势：
- 风险：
- 成本：

### 推荐
选 A 因为...

## 验证标准
- 命令：`pnpm test xxx`
- 观察：...

## 风险与回滚
- 风险：...
- 回滚：...

## 需要用户确认的问题
（如果有）

与其他 Skill 的关系

• 完成后通常进入实施阶段，配合 /small-diff 控制 diff 大小
• 任务结束前必走 /check 验证 diff
• 遇到 bug 用 /hunt 系统化排查