Ask sonnet

Skill BackToCimaCoppi/Praxis/skills/ask-sonnet

让 Sonnet 子线程分析或执行任务。触发词："问一下sonnet"、"问一下claude"、"让sonnet去做"、"让claude去做"。主线程（L1）制包，Sonnet（L2）深度推理。From its SKILL.md

Install

npx -y skills add BackToCimaCoppi/Praxis --skill ask-sonnet

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
runs commandsInstructs the agent to run 1 command, including `git diff --name-only`.

SKILL.md

12.7 KB, ~4.8k tokens by cl100k_base, as published. Nobody here has run it

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 调用