Menü
让 Opus 子线程处理最复杂的分析和执行任务。触发词："问一下opus"、"让opus去做"。主线程（L1）制包，Opus（L3）深度推理。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
从老旧黑盒代码反推「树形索引、逐层下钻」的知识库（业务逻辑/数据库/接口三层），给重构 AI 注入背景。承诺「边界内可审计覆盖 + 残余风险显式登记」，不承诺零遗漏。触发词：「老代码考古」「反推知识库」「重构前背景」「把老项目翻译成文档」「legacy 调查」。
对抗评审 skill。主线程把待评审内容（设计文档 / 代码 / 任意方案）原样打成证据包，并行起 Claude(Opus) 子线程与 codex(GPT 5.5) 做两份独立评审，再由 Opus 裁判逐条裁决采纳/驳回，产出最终报告。Claude 轮用 Agent 工具，GPT 轮用 codex。触发词："克劳德评审"、"对抗评审"。
Use when the user wants to consult Claude for a second opinion, audit, or direct execution. 触发词："问一下克劳德"、"问一下claude"、"问一下sonnet"、"让克劳德去做"、"让claude直接XX"、"问一下opus"、"让opus去做"。This skill uses the Agent tool to spawn a Claude subagent from the main thread. All synthesis and decisions stay in the main thread.
让 Sonnet 子线程分析或执行任务。触发词："问一下sonnet"、"问一下claude"、"让sonnet去做"、"让claude去做"。主线程（L1）制包，Sonnet（L2）深度推理。
从现有代码冷启动、生成七层文档反推总控文档的 skill（用户级通用）。本 skill 的交付物是「扫描摘要 + 任务总控编排文档」，不包含具体层的文档撰写（Phase 3 由 /control 驱动，单独消耗会话预算）。适用场景：项目无文档或文档严重过时、需要系统性规划七层文档补写任务。触发词：「冷启动建文档骨架」「反推文档体系总控」「从代码反推文档」「代码到七层」「反推文档体系」。
读陌生项目代码，自动组建 agent team，产出 AI 友好的项目导览文档（AI-friendly project guide）。 触发词：理解陌生项目、生成项目导览文档、代码到说明书、AI 友好项目文档、摸清一个代码库、 分析这个项目、给这个项目做文档、项目说明书、项目调研文档。 定位：只读调研 + 一次性产出，轻量级。 不是七层文档体系（code-to-7layer / doc-layer-system），不改代码，不需要人工逐步指导。
Basierend auf der SOC-Berufsklassifikation
| name | ask-opus |
| description | 让 Opus 子线程处理最复杂的分析和执行任务。触发词："问一下opus"、"让opus去做"。主线程（L1）制包，Opus（L3）深度推理。 |
| disable-model-invocation | true |
从主线程（L1 / Haiku）发起调用，让 Opus（L3）承担最高复杂度的推理、架构设计、复杂代码生成。
设计哲学：人保留分工权和最终决策权。AI 不做自动路由——用户不说触发词，主线程自己处理。用户说触发词，主线程严格按触发词对应模式执行。
你（主线程）是 L1——信息收集者，不是问题解答者。
这个架构的核心设计是分层协作：
为什么这样分工，而不是直接把所有上下文扔给强模型：
何时选 Opus 而非 Sonnet：
你的核心职责：
你不是在替子线程思考，你是在替子线程收集弹药。 结论是子线程的职责，原文是你的职责。把约束条件写成"代码符合规范"是越俎代庖；把规则原文传进去，让 Opus 自己验证，才是正确的分工。
给清单，不设路障。 子线程用的是比你更强的模型，它清楚自己该读什么。你给的文件清单是「最小必读」（保证它不漏关键信息），不是「只准读这些」——它若判断需要更多上下文，放手让它自己去读。注意：放开的只是「读」；「能写哪些文件」仍由派模式的授权边界严格限定。
| 模式 | 触发词 | 调用模型 |
|---|---|---|
| 问模式 | 问一下opus | opus |
| 派模式 | 让opus去做 | opus |
用户消息
│
├─ 不含触发词 → 主线程直接处理
│
└─ 含触发词
│
├─ "问一下" / "怎么看" / "审查" / "评审"
│ → 问模式（§3）
│
└─ "让XX去做" / "让XX直接" / "派XX"
→ 派模式（§4）
用途：让 Opus 回答一个问题（复杂设计审查、技术架构分析、高难度方案评估等）。Opus 只读不改，输出分析结论，主线程消化后回答用户。
不同问题类型需要不同的上下文。主线程根据问题类型，从以下槽位中选择相关的填入：
[具体问题] — 一句话，可被独立回答，不依赖隐含上下文
[文件引用] — 需要读的代码/文档文件，精确到方法/行范围
适用：代码审查、架构分析、技术问题
格式：文件路径（只读：方法名/行范围）
每个文件引用附带最小必读清单："以下文件务必读取；如你判断需要更多上下文，可自行阅读其他文件"
[背景事实] — 回答此问题必须知道的关键事实
格式：用自然语言描述，写清楚"当前是什么状态"
如果是代码相关：先浓缩再写入（代码→关键事实，禁止贴超过5行的原始代码）
[约束条件] — 回答此问题必须遵守的边界
来源：CLAUDE.md 红线、技术约束、资源约束、已排除的选项及原因
格式：内嵌原文条款，不要写"参考 CLAUDE.md"
[判断标准] — 什么算好答案
例："方案必须兼容现有的游标分页机制"、"优先选择侵入性最小的方案"
[外部信息] — 非代码的参考信息
适用：产品设计、商业策略、竞品分析
例：竞品数据、用户反馈、市场数据、故事设定、人物档案
填槽原则：
| 问题类型 | 通常需要的槽位 |
|---|---|
| 代码审查 | 具体问题 + 文件引用 + 约束条件 |
| 架构设计 | 具体问题 + 文件引用 + 背景事实 + 约束条件 + 判断标准 |
| 产品/交互设计 | 具体问题 + 背景事实 + 判断标准 + 外部信息 |
| 商业策略 | 具体问题 + 背景事实 + 外部信息 + 约束条件 |
| 技术选型 | 具体问题 + 背景事实 + 约束条件 + 判断标准 |
| 创作/写作 | 具体问题 + 背景事实（设定/大纲/人物）+ 外部信息 |
| 人生/决策 | 具体问题 + 背景事实 + 约束条件 + 判断标准 |
这只是参考，实际填哪些槽位由 RAM 检验句决定。
[具体问题]
L1 信息来源声明（必填）：
- 交付形式：直接回复，不写文件，不创建文件
- 已读文件清单（最小必读，子线程可自行补读）：
- [文件路径]（读取范围：方法名 / 行号）
- （代码题必填；非代码题若无文件引用可写"无文件引用"）
- 未纳入本包的已知信息：
- [内容] — 原因：[为什么排除]
[文件引用 / 背景事实 / 约束条件 / 判断标准 / 外部信息]
（按需填入，无关槽位留空。每项内容必须能通过 RAM 检验句。）
输出要求：
- 直接输出结论。不要改任何文件，不要创建文件。
- 如果现有信息不足以给出可靠结论，不要硬答。先声明缺失的关键信息，再给出基于明确假设的条件性结论。
格式：⚠️ 信息不足：缺少 [X]。以下结论基于假设 [Y]。
下面这个粉丝列表分表方案，在 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
输出要求：
- 直接输出结论。不要改任何文件，不要创建文件。
- 如果现有信息不足以给出可靠结论，不要硬答。先声明缺失的关键信息，再给出基于明确假设的条件性结论。
用途：让 Opus 在授权范围内直接执行任务。Opus 自己判断需要改哪些文件（包括新建文件），执行前先汇报改动范围，主线程确认后放行。
核心原则：主线程给"意图 + 护栏"，强模型决定"执行路径"。主线程不替强模型预设文件清单。
主线程 → 发任务 + 验收标准 + 禁入区 + 约束
Opus → 探索代码 → 汇报改动范围计划
主线程 → 确认/调整范围
Opus → 执行改动
主线程 → git diff 验收 → 报告用户
[任务描述] — 要做什么
[验收标准] — 做到什么程度算完成
▸ 禁止区（绝对不能碰的文件/目录/模块）
- [明确排除的范围]
▸ 约束（必须遵守的规则，从 CLAUDE.md 内嵌原文）
- [适用条款]
▸ 范围探索
先探索代码，确定需要改动哪些文件（包括是否需要新建文件）。
在开始写代码之前，先输出改动范围计划：
## 改动范围计划
计划修改：
- [文件路径]：原因
计划新建：
- [文件路径]：原因
需确认：
- [文件路径]：主线程提示里没提到但逻辑上需要，请确认
预计改动量：[大/中/小]
主线程回复"确认"后开始施工。
▸ 完成后
输出改动摘要（每个文件改了什么）。
Opus 完成后，主线程执行验收：
□ 范围检查：git diff --name-only，是否都在授权范围内？
□ 编译检查：改动是否引入编译错误？
□ 约束检查：每条约束都遵守了吗？（N+1、游标分页、@Resource 等）
□ 验收标准：每一项都完成了吗？
□ 越界检查：有没有改动禁止区的文件？
全部通过 → 向用户报告改动摘要。不通过 → 主线程修正，或告知用户具体问题。
使用 Agent 工具直接调子线程，无需 bash 命令：
问模式（只读分析）：
Agent(
description: "一句话描述任务",
model: "opus",
prompt: [制好的 prompt]
)
派模式（执行任务，需要读写文件）：
Agent(
description: "一句话描述任务",
model: "opus",
isolation: "worktree", # 需要文件隔离时加；不隔离则省略
prompt: [制好的 prompt]
)
不需要临时文件，不需要 unset，不需要 bash。
| 异常 | 处理 |
|---|---|
| Opus 不可用 / 配额耗尽 | 告知用户："Opus 不可用，是否需要降级为 /ask-sonnet？" |
| Agent 超时（>180s 无响应） | 重试一次；仍超时报告用户 |
| 输出明显不对 / 空响应 | 检查 prompt 是否有歧义或信息缺口，修正后重试 |
| 输出被截断 | 在 prompt 末尾加"如输出过长，优先输出结论部分" |
| 派模式：改动超出授权范围 | 撤销超出部分的改动，告知用户 |
本 skill 的模板和方法论源自 证据包制作规范（references/dispatch.md，与本 skill 同目录）。
references/dispatch.md，用 RAM 框架深度制包，再通过本 skill 调用