Chapter 06 · Domain 3（权重 20%）
Commands、Skills 与 Plan Mode
frontmatter 全解与「先想后做」的判据
本章两块内容看似无关，实际共用一条主线：把工作装进合适的容器。前半讲把可复用流程装进 command / skill（以及三个必须记住的 frontmatter 选项），后半讲把一次性任务装进 plan mode 还是直接开干。官方 12 道样题里有 2 道出在本章（Q4、Q5）。
一、Commands 与 Skills 的位置
<repo>/.claude/commands/review.md ✔ 真实存在 · project 级 slash command，入版本库，clone/pull 即得
~/.claude/commands/scratch.md ✔ 真实存在 · user 级 · 个人命令，不共享
<repo>/.claude/skills/<name>/SKILL.md ✔ 真实存在 · project 级 skill，frontmatter 配置见下
~/.claude/skills/<name>/SKILL.md ✔ 真实存在 · 个人 skill 变体（务必改名，避免影响队友）
<repo>/.claude/config.json commands: [] ✘ 不存在 · 官方样题 Q4 的 D 选项，Claude Code 里没有这个机制官方样题 Q4 只考了一件事：要让每个开发者 clone 或 pull 仓库就能用的 /review 命令，放 .claude/commands/。这是 P9 的第一条轴的最直白应用——共享进版本库。三个干扰项分别是：放家目录（不共享）、放 CLAUDE.md（那是项目指令与上下文，不是命令定义）、放一个根本不存在的 .claude/config.json。
二、SKILL.md 的三个 frontmatter 选项
这三个选项是 Domain 3 的必背项，考试直接考过它们的用途区分：
--- .claude/skills/codebase-audit/SKILL.md ---
---
context: fork ✔ 真实存在 · 在隔离的 sub-agent 上下文中运行本 skill
allowed-tools: [Read, Grep, Glob] ✔ 真实存在 · 限制 skill 执行期间可用的工具
argument-hint: "<package-name>" ✔ 真实存在 · 缺参调用时提示开发者补参数
---
逐包审计依赖、导出面与测试覆盖，输出一页摘要。| 选项 | 解决什么问题 | 官方举例 |
|---|---|---|
context: fork |
skill 产出的冗长输出或探索性上下文会污染主会话 | 代码库分析（输出极长）、头脑风暴替代方案（探索性上下文）——跑在隔离的 sub-agent 上下文里，主会话只收结果 |
allowed-tools |
skill 执行期间的权限收敛 | 限制到文件写入操作以防破坏性动作 |
argument-hint |
开发者不带参数调用时无从知道该传什么 | 提示需要的参数名 |
个人变体的正确做法 — 想要一个团队 skill 的私人改版，放
~/.claude/skills/ 并且改名。 改名这一步是 guide 明写的，理由是避免与团队版重名而影响队友。考场识别信号：题干出现「不想影响队友」+「自己用的变体」。allowed-tools：考纲（TS 3.2）把它描述为限制 skill 执行期间的工具访问，本章和全书题目都按这个口径，考试也按这个口径作答。当前产品行为不同：它只让所列工具在调用该 skill 的那一轮免确认，并不限制可用工具——其余工具照样可以调用，由权限设置决定。真正把工具移出可用范围，要用 frontmatter 的 disallowed-tools，或权限设置里的 deny 规则（按 deny → ask → allow 的顺序匹配，deny 优先）。
context: fork：fork 出的 sub-agent 默认在后台运行，此时用的是后台 sub-agent 的较窄工具集；设 background: false 才保留完整工具集。这一点同样不在考纲范围内。
三、Skill 还是 CLAUDE.md？
| Skill | CLAUDE.md | |
|---|---|---|
| 加载方式 | 按需调用（on-demand invocation） | 始终加载（always-loaded） |
| 内容性质 | 任务型工作流：多步、有明确起止 | 普适标准：编码规范、测试约定、review 准则 |
| 典型例子 | 发布清单、迁移向导、依赖审计 | 「所有 public 函数带文档注释」 |
| 放错的代价 | 普适标准做成 skill → 没人调用就不生效 | 低频流程塞进 CLAUDE.md → 其余会话白占 context |
还有一条容易被忽略的边界：题干若强调「自动按文件路径生效」，答案既不是 skill 也不是 CLAUDE.md，而是 .claude/rules/ + glob（ch05）——因为 skill 需要被调用，官方样题 Q6 的 C 选项正是栽在这里。
四、Plan mode vs direct execution
这是 Domain 3 里最像「判断题」的一条，也最容易被过度思考。判据其实很硬：
| 选 plan mode | 选 direct execution |
|---|---|
|
|
Plan mode 的价值命题是在提交变更之前安全地探索代码库并完成设计，避免昂贵的返工。官方样题 Q5（monolith 拆微服务）把四个选项做成了同一条轴上的四个位置，值得逐一体会其中两个错法：
- 「先 direct 干起来，让实现过程自然揭示服务边界」——把发现依赖的时机推迟到已经改了代码之后，返工成本最高。
- 「先 direct，遇到意外复杂度再切 plan」——官方解析点名它忽视了复杂性已经写在需求里，不是可能才出现的东西。这个反驳句式值得记住，它可以套用到很多题上。
两个配套机制
- Explore subagent——把冗长的发现阶段输出隔离出去，只把摘要带回主会话，防止多阶段任务中 context 被探索输出吃光。它与
context: fork是同一个思路在不同容器上的实现。 - plan + direct 组合——两者不是互斥的模式选择。官方给的组合形态是：用 plan mode 做调查与方案设计，然后用 direct execution 执行已定方案（例如先规划 library migration，再按计划实施）。
实践中还有一个信号：如果你能一句话说清「改哪个文件的哪一行、为什么」，那就是 direct；如果你需要先回答「有几种做法、各自代价是什么」，那就是 plan。这条经验规则与 guide 的判据等价，但在读题时更快——考试题干通常会明确给出文件数量或「multiple valid approaches」这类措辞，直接对号入座即可。
外部课程 · CertSafari — 本章 2 个考点（展开查看）
用于补读和错题复盘；第三方 AI 生成练习材料，非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对：2026-10-16。
考点回链 — 本章覆盖：TS 3.2（project vs user 级 commands、
.claude/skills/ 与 SKILL.md frontmatter 的 context: fork/allowed-tools/argument-hint、个人变体改名、skills vs CLAUDE.md）、TS 3.4（plan mode 的四类触发条件、direct execution 的适用范围、Explore subagent 隔离发现输出、plan 调查 + direct 实施的组合）。相邻考点：路径规则见 ch05，迭代精化见 ch07。本章题组
ch06 · Q1 · 准则 P9
Your team has a 9-step onboarding audit (check lockfiles, verify CI config, scan for hardcoded secrets, …) that new maintainers run once when they inherit a service. It produces several hundred lines of intermediate findings before a short verdict. You want it available to everyone on the repo, invoked deliberately, without its output crowding out the main conversation. How should you configure it?
正确 A三个要求逐一对应 TS 3.2：团队可用 → project 级
.claude/skills/（入版本库）；有意调用的多步任务流 → skill 而非 CLAUDE.md；冗长输出不污染主会话 → context: fork，在隔离的 sub-agent 上下文中运行（guide 的原例正是「代码库分析这类产生冗长输出的 skill」）。D3 治标不治本违反 P9B：CLAUDE.md 是始终加载的普适标准容器，一个「继承服务时跑一次」的九步流程放进去，会在其余全部会话里白占 context；而且它完全没有解决输出隔离的诉求。
D3 治标不治本违反 P9C：
~/.claude/skills/ 是个人作用域，不随版本库分发——「available to everyone on the repo」直接落空。个人目录的正当用途是私人变体（且要改名）。D2 过度工程违反 P9D：
paths: ["**/*"] 匹配一切，等于用条件加载机制实现无条件加载，白绕一层；而且 rules 是约定容器，不是按需调用的任务流容器，同样解决不了输出污染。ch06 · Q2 · 准则 P5
You are asked to migrate the codebase from an in-house HTTP client to a third-party library. Preliminary grep shows 62 files import the old client, three of them wrap it with custom retry semantics, and there are two plausible migration strategies (adapter shim vs direct rewrite) with different testing implications. How should you approach this?
正确 DTS 3.4 的三个触发条件在题干里全部出现：大规模变更（45+ 文件，正是 guide 举的例子）、多个可行方案（adapter shim vs 直接重写）、需要先摸清依赖（三个自定义包装）。同时体现了官方推荐的组合形态——plan 做调查与决策，direct 做实施。
D6 概率当保证违反 P5A：「comprehensive upfront instruction」假装你已经知道正确结构，而两个策略的取舍尚未做出。这是官方样题 Q5 的 C 选项工艺——在没有探索代码的前提下假设自己已有答案。
D3 治标不治本违反 P5B：官方样题 Q5 的 D 选项原封不动的形态。复杂性已经写在需求里（45+ 文件、两种策略），不是可能才出现的东西；等它「证明自己复杂」再切换，返工成本已经发生。
D3 治标不治本违反 P5C：逐文件跑测试是好工程习惯，但它管的是实施期的正确性，管不了「该选哪种策略」这个先决问题。选错策略时，每个文件的测试都会通过，而整体架构是错的。
ch06 · Q3 · 准则 P4
A team skill generates migration scripts. During a review you notice that if the model misinterprets the prompt, the skill has the ability to run shell commands and could drop tables. You want the skill to keep working but be structurally unable to execute destructive operations. What is the mechanism?
正确 ATS 3.2：
allowed-tools frontmatter 的定义用途就是限制 skill 执行期间的工具访问，guide 的原例正是「限制到文件写入操作以防破坏性动作」。这是 P4 最小权限在 skill 容器上的直接落地——不是让它别做，而是让它做不到。D6 概率当保证违反 P3B：题干要求「structurally unable」，而 prompt 指令是概率性合规。现成的确定性机制就在 frontmatter 里，没有理由退回赌措辞。
D1 凭空捏造违反 P4C：
context: fork 是真实的 frontmatter 字段，但 TS 3.2 给它的职责是隔离上下文——防止 skill 的冗长输出污染主会话；收敛执行期的工具访问是 allowed-tools 的职责，guide 把这两件事分派给了两个不同的字段。把「沙箱化副作用」安在 fork 上，是给真实机制安上它职责之外的语义（ch01 的 D1 子型）。D1 凭空捏造违反 P4D：
argument-hint 的用途是缺参时提示开发者补参数，它是一个提示串，不是校验器，也不构成执行前的确认闸门。ch06 · Q4 · 准则 P5
A production stack trace points at line 214 of
invoice_totals.go: a nil map is written to when an invoice has no line items. The fix is a two-line guard, the file is self-contained, and no other module depends on the internal behavior. Which approach is appropriate?正确 CTS 3.4 对 direct execution 的定义几乎逐字命中：范围明确、单文件、有清晰的 stack trace。plan mode 的触发条件（大规模变更、多方案、架构决策、多文件）一个都不成立。
D2 过度工程违反 P2A：把「后果严重」误当成 plan mode 的触发条件。资金后果确实提高对正确性的要求（走测试与 review），但 plan mode 的判据是复杂度与方案多样性，不是影响面。
D3 治标不治本违反 P1B：题干给的 stack trace 已经把根因指到了具体行与具体机制（无 line items 时写入 nil map）。再发一版只加日志的变更去「确认」已经确认的事，是把一次生产发布花在重复取证上——P1 要求读懂题干数据，而不是重新采集它。
D2 过度工程违反 P2D：Explore subagent 的用途是隔离冗长的发现阶段输出，防止多阶段任务耗尽 context（TS 3.4）。为一个两行的守卫先做一轮模块测绘，是典型的比例失当。
ch06 · Q5 · 准则 P9
Your team ships a
/deploy-check command in .claude/commands/. You want your own version that also pings your personal staging environment, without changing what teammates get. What should you do?正确 BTS 3.2 的两条合起来用：个人作用域放
~/.claude/（不随版本库共享），且改名以免影响队友——guide 在 skills 的个人变体上明写了改名这一步，命令同理。P9 第一条轴的标准应用。D3 治标不治本违反 P9A：改项目文件就是改所有人的版本，注释不是隔离机制。「without changing what teammates get」被直接违反。
D1 凭空捏造违反 P9C：同名「shadow」是一个被假定存在的覆盖语义。guide 给的做法是改名，正是为了避免依赖这种未定义的重名行为——考试里把未经背书的机制当依据就是 D1。
D1 凭空捏造违反 P9D：
argument-hint 是缺参时的提示串，不是带默认值的开关或特性标志。而且它仍然把个人需求写进了团队共享的文件里。ch06 · Q6 · 准则 P7
A multi-phase task requires (1) understanding how authentication flows through an unfamiliar 200-file service, then (2) implementing a new SSO provider. Phase 1 produces a large volume of file reads and search results. By the time phase 2 begins, the session is near its context limit and the agent starts referring to "the typical pattern" rather than the specific classes it found. What should you change?
正确 DTS 3.4：Explore subagent 的定义用途就是隔离冗长的发现输出、只把摘要带回主会话，防止多阶段任务耗尽 context。题干的症状——开始引用「典型模式」而不是先前发现的具体类——正是 TS 5.4 描述的上下文退化信号。
D3 治标不治本违反 P1A：
--resume 会把同样臃肿的上下文原样带回来，退化照旧。跨天与否和 context 占用无关。D3 治标不治本违反 P7B：更大的 context window 不解决注意力质量问题（官方样题 Q12 的 C 选项被点名的正是这一点）；而且它只是把耗尽的时点推后，多阶段任务照样会撞上。
D5 吞错或炸链违反 P1C：用编译错误代替理解，在一个陌生的 200 文件服务上会产出大量看似能编过、语义却错位的集成代码。它放弃了阶段 1 的目标，而不是解决阶段 1 的成本。
ch06 · Q7 · 准则 P9
A developer invokes your team's
/scaffold-service skill with no arguments. The skill needs a service name and a target runtime, and currently fails with an unhelpful error deep in execution. What is the intended mechanism for this?正确 CTS 3.2：
argument-hint frontmatter 的定义用途就是「在开发者不带参数调用 skill 时提示所需参数」。题干的场景是它的教科书触发条件。D3 治标不治本违反 P9A：让全体会话永久携带一段某个 skill 的参数说明，既错配容器（CLAUDE.md 装普适标准），也不会在调用时刻提示到人——错误照样在执行深处爆出。
D1 凭空捏造违反 P9B：
allowed-tools 限制的是可用工具集合，与参数校验无关；把它当成入参守卫是给一个真实机制安上一个它没有的语义。D5 吞错或炸链违反 P6D：把错误藏进隔离上下文里，开发者更难知道自己漏了参数——这是把可诊断的失败变成静默失败，方向正好反了。