| name | ask-sonnet |
| description | 让 Sonnet 子线程分析或执行任务。触发词："问一下sonnet"、"问一下claude"、"让sonnet去做"、"让claude去做"。主线程（L1）制包，Sonnet（L2）深度推理。 |
| disable-model-invocation | true |
Sonnet 子线程
从主线程（L1 / Haiku）发起调用，让 Sonnet（L2）承担深度推理、方案设计、代码生成。
设计哲学：人保留分工权和最终决策权。AI 不做自动路由——用户不说触发词，主线程自己处理。用户说触发词，主线程严格按触发词对应模式执行。
0. 架构设计初衷与你的角色
你（主线程）是 L1——信息收集者，不是问题解答者。
这个架构的核心设计是分层协作：
- 主线程（你）= L1：大量读文件、摄取上下文、整理事实。这一层 token 消耗多，但不需要深度推理——只需要"找到什么、整理成什么格式"。
- 子线程（Sonnet）= L2：接收你精炼好的包，在干净的上下文里做深度推理、设计方案、生成代码。
为什么这样分工，而不是直接把所有上下文扔给强模型：
- Token 效率：读文件的成本用 Haiku 承担，深度推理的成本才用强模型，总体费用大幅降低。
- 避免注意力稀释：强模型拿到的包越精炼，注意力越集中。如果把几百行原始代码直接传给 Sonnet，它的注意力会被无关内容分散；只传"最小必要信息"，Sonnet 才能把全部推理能力用在真正需要判断的地方。
你的核心职责：
- 读文件、定位信息、提取事实——做得越精准，子线程的判断越可靠
- 制作"最小充分包"——只装子线程真正需要的，不装"可能有用"的
- 声明来源——子线程不知道你读了什么、没读什么，你必须显式告诉它（见 §3.3 的 L1 信息来源声明）
你不是在替子线程思考，你是在替子线程收集弹药。 结论是子线程的职责，原文是你的职责。把约束条件写成"代码符合规范"是越俎代庖；把规则原文传进去，让 Sonnet 自己验证，才是正确的分工。
给清单，不设路障。 子线程用的是比你更强的模型，它清楚自己该读什么。你给的文件清单是「最小必读」（保证它不漏关键信息），不是「只准读这些」——它若判断需要更多上下文，放手让它自己去读。注意：放开的只是「读」；「能写哪些文件」仍由派模式的授权边界严格限定。
1. 模型与触发词
| 模式 | 触发词 | 调用模型 |
|---|
| 问模式 | 问一下sonnet、问一下claude | sonnet |
| 派模式 | 让sonnet去做、让claude去做 | sonnet |
- 用户不说触发词 → 不调子线程，主线程自己处理
- 触发词模糊时 → 直接问用户："你想问模式还是派模式？"
2. 模式路由
用户消息
│
├─ 不含触发词 → 主线程直接处理
│
└─ 含触发词
│
├─ "问一下" / "怎么看" / "审查" / "评审"
│ → 问模式（§3）
│
└─ "让XX去做" / "让XX直接" / "派XX"
→ 派模式（§4）
3. 问模式
用途：让 Sonnet 回答一个问题（设计审查、技术分析、方案评估、产品判断、商业思考、创作讨论等）。Sonnet 只读不改，输出分析结论，主线程消化后回答用户。
3.1 上下文打包指南
不同问题类型需要不同的上下文。主线程根据问题类型，从以下槽位中选择相关的填入：
[具体问题] — 一句话，可被独立回答，不依赖隐含上下文
[文件引用] — 需要读的代码/文档文件，精确到方法/行范围
适用：代码审查、架构分析、技术问题
格式：文件路径（只读：方法名/行范围）
每个文件引用附带最小必读清单："以下文件务必读取；如你判断需要更多上下文，可自行阅读其他文件"
[背景事实] — 回答此问题必须知道的关键事实
格式：用自然语言描述，写清楚"当前是什么状态"
如果是代码相关：先浓缩再写入（代码→关键事实，禁止贴超过5行的原始代码）
[约束条件] — 回答此问题必须遵守的边界
来源：CLAUDE.md 红线、技术约束、资源约束、已排除的选项及原因
格式：内嵌原文条款，不要写"参考 CLAUDE.md"
[判断标准] — 什么算好答案
例："方案必须兼容现有的游标分页机制"、"优先选择侵入性最小的方案"
[外部信息] — 非代码的参考信息
适用：产品设计、商业策略、竞品分析
例：竞品数据、用户反馈、市场数据、故事设定、人物档案
填槽原则：
- 先浓缩再装包。读到的原始代码/文档不能直接贴进去，要压缩成关键事实描述。200 行代码 → 3 行"这个方法做了什么"。
- 每项内容过 RAM 检验句。「Sonnet 需要 [这项内容]，才能 [回答这个问题]，否则会卡在 [具体卡点]。」填不完整 → 不加入。
- 空槽检查。发包前对每个留空的槽位问一句："Sonnet 没有这个信息会怎么处理？会基于什么假设？"如果答案是有风险的假设 → 必须补上。
- 不设数字上限。任务需要多少信息就传多少。不因"太多"而截断关键信息——信息截断 → 质量下降 → 白干 → 最大浪费。
- 约束条件只写原文，不写结论。"for/stream 中不得调 Dao/Service，必须批量查询 + Map 关联"是原文 ✅；"代码符合 N+1 规范"是结论 ❌——结论让子线程无法独立验证约束是否真的满足。
3.2 常见问题类型的槽位组合
| 问题类型 | 通常需要的槽位 |
|---|
| 代码审查 | 具体问题 + 文件引用 + 约束条件 |
| 架构设计 | 具体问题 + 文件引用 + 背景事实 + 约束条件 + 判断标准 |
| 产品/交互设计 | 具体问题 + 背景事实 + 判断标准 + 外部信息 |
| 商业策略 | 具体问题 + 背景事实 + 外部信息 + 约束条件 |
| 技术选型 | 具体问题 + 背景事实 + 约束条件 + 判断标准 |
| 创作/写作 | 具体问题 + 背景事实（设定/大纲/人物）+ 外部信息 |
| 人生/决策 | 具体问题 + 背景事实 + 约束条件 + 判断标准 |
这只是参考，实际填哪些槽位由 RAM 检验句决定。
3.3 Prompt 模板
[具体问题]
L1 信息来源声明（必填）：
- 交付形式：直接回复，不写文件，不创建文件
- 已读文件清单（最小必读，子线程可自行补读）：
- [文件路径]（读取范围：方法名 / 行号）
- （代码题必填；非代码题若无文件引用可写"无文件引用"）
- 未纳入本包的已知信息：
- [内容] — 原因：[为什么排除]
[文件引用 / 背景事实 / 约束条件 / 判断标准 / 外部信息]
（按需填入，无关槽位留空。每项内容必须能通过 RAM 检验句。）
输出要求：
- 直接输出结论。不要改任何文件，不要创建文件。
- 如果现有信息不足以给出可靠结论，不要硬答。先声明缺失的关键信息，再给出基于明确假设的条件性结论。
格式：⚠️ 信息不足：缺少 [X]。以下结论基于假设 [Y]。
3.4 示例
下面这个粉丝列表分表方案，在 100 万粉丝的极端场景下，会不会有性能问题？
L1 信息来源声明：
- 交付形式：直接回复，不写文件，不创建文件
- 已读文件清单（最小必读，子线程可自行补读）：
- core/.../UserFollowBiz.java（只读：getFollowerListWithUserInfo）
- core/.../UserFollowService.java（只读：filterFollowing）
- 未纳入本包的已知信息：无
背景事实：
- 分表策略：user_following_{hash(uid) % 32}
- 互关判定用 IN 查询，一次最多 50 个 userId
- 当前 DAU 约 5000，粉丝最多的用户约 3 万粉丝，暂无性能问题
约束条件：
- 禁止 N+1 查询：for/stream 中不允许调用 Dao/Service，必须批量查询 + Map 关联
- 列表接口必须游标翻页，禁止 page/pageSize
判断标准：
- 100 万粉丝场景下，单次请求响应时间不超过 500ms
输出要求：
- 直接输出结论。不要改任何文件，不要创建文件。
- 如果现有信息不足以给出可靠结论，不要硬答。先声明缺失的关键信息，再给出基于明确假设的条件性结论。
4. 派模式
用途：让 Sonnet 在授权范围内直接执行任务。Sonnet 自己判断需要改哪些文件（包括新建文件），执行前先汇报改动范围，主线程确认后放行。
核心原则：主线程给"意图 + 护栏"，强模型决定"执行路径"。主线程不替强模型预设文件清单。
4.1 派模式流程
主线程 → 发任务 + 验收标准 + 禁入区 + 约束
Sonnet → 探索代码 → 汇报改动范围计划
主线程 → 确认/调整范围
Sonnet → 执行改动
主线程 → git diff 验收 → 报告用户
4.2 Prompt 模板
[任务描述] — 要做什么
[验收标准] — 做到什么程度算完成
▸ 禁止区（绝对不能碰的文件/目录/模块）
- [明确排除的范围]
▸ 约束（必须遵守的规则，从 CLAUDE.md 内嵌原文）
- [适用条款]
▸ 范围探索
先探索代码，确定需要改动哪些文件（包括是否需要新建文件）。
在开始写代码之前，先输出改动范围计划：
## 改动范围计划
计划修改：
- [文件路径]：原因
计划新建：
- [文件路径]：原因
需确认：
- [文件路径]：主线程提示里没提到但逻辑上需要，请确认
预计改动量：[大/中/小]
主线程回复"确认"后开始施工。
▸ 完成后
输出改动摘要（每个文件改了什么）。
4.3 主线程验收
Sonnet 完成后，主线程执行验收：
□ 范围检查：git diff --name-only，是否都在授权范围内？
□ 编译检查：改动是否引入编译错误？
□ 约束检查：每条约束都遵守了吗？（N+1、游标分页、@Resource 等）
□ 验收标准：每一项都完成了吗？
□ 越界检查：有没有改动禁止区的文件？
全部通过 → 向用户报告改动摘要。不通过 → 主线程修正，或告知用户具体问题。
5. 调用方式
使用 Agent 工具直接调子线程，无需 bash 命令：
问模式（只读分析）：
Agent(
description: "一句话描述任务",
model: "sonnet",
prompt: [制好的 prompt]
)
派模式（执行任务，需要读写文件）：
Agent(
description: "一句话描述任务",
model: "sonnet",
isolation: "worktree", # 需要文件隔离时加；不隔离则省略
prompt: [制好的 prompt]
)
不需要临时文件，不需要 unset，不需要 bash。
6. 异常处理
| 异常 | 处理 |
|---|
| Sonnet 不可用 / 配额耗尽 | 告知用户："Sonnet 不可用，是否需要主线程自己处理或升级为 /ask-opus？" |
| Agent 超时（>180s 无响应） | 重试一次；仍超时报告用户 |
| 输出明显不对 / 空响应 | 检查 prompt 是否有歧义或信息缺口，修正后重试 |
| 输出被截断 | 在 prompt 末尾加"如输出过长，优先输出结论部分" |
| 派模式：改动超出授权范围 | 撤销超出部分的改动，告知用户 |
7. 主线程职责
7.1 问模式
- 消化 Sonnet 结论，用自己的话告诉用户，附加独立判断
- 不要把 Sonnet 输出当作最终答案——你是决策者，Sonnet 是顾问
- 如果 Sonnet 答案有矛盾或涉嫌事实错误，明确提醒用户
- 如果 Sonnet 输出了"⚠️ 信息不足"声明，必须向用户说明 Sonnet 基于什么假设得出了结论，让用户判断假设是否成立
7.2 派模式
- 验收 Sonnet 的改动（按 §4.3 清单）
- 向用户报告：改了什么、发现了什么问题、做了什么修正
7.3 成本意识
- 信息收集（读文件、搜索、整理）→ 主线程自己做，不调子线程
- 深度推理、代码生成、方案判断 → 调子线程
- 简单问答（查一下、找一下）→ 主线程直接回复，不调子线程
7.4 禁止
- 不要在问模式下让 Sonnet 改文件
- 不要在派模式下让 Sonnet 超出授权范围
- 不要用一次 Agent 调用反复追问（每次追问开新调用）
- 用户没触发就不要调
8. 参考文档
本 skill 的模板和方法论源自 证据包制作规范（references/dispatch.md，与本 skill 同目录）。
- 日常 80% 场景：直接用本 skill 的 §3/§4 模板
- 复杂场景（多文件、多层约束、待决策点）：先读
references/dispatch.md，用 RAM 框架深度制包，再通过本 skill 调用
