skill-test

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

自动化模式：解析 modes.automation（project.local.yaml → project.yaml → 默认值 collaborative）。每次调用 AskUserQuestion 和 每次文件写入都遵循 .claude/docs/automation-modes.md （collaborative 始终询问 · guided 仅询问重大事项 · autonomous 记录并继续； automation_always_ask 类别始终询问）。

技能测试

验证技能（.claude/skills/*/SKILL.md）和 Agent（.claude/agents/*.md） 的结构合规性与行为正确性。无外部依赖——完全基于现有的技能／钩子／模板架构运行。

四种模式：

模式	命令	用途	Token 成本
static	/skill-test static [name|all]	结构检查器——每项技能执行 7 项合规检查，另含 Agent、委派和兼容性观察项	低（每项技能约 1k）
spec	/skill-test spec [name]	行为验证器——评估技能或 Agent 测试规范中的断言	中（每项约 5k）
category	/skill-test category [name|all]	类别评分标准——根据类别专属指标检查技能或 Agent	低（每项约 2k）
audit	/skill-test audit	覆盖率报告——技能、Agent 规范及最近测试日期	低（总计约 3k）

通过测试能证明什么。 所有模式都会读取文件；没有任何模式会运行技能。static： 文件具备技能所需的结构，但不能证明技能行为正确。spec：仔细阅读后， 指令涵盖了每种情况，但不能证明 Claude 运行时会遵循这些指令。category： 技能符合其类别的书面评分标准。audit：哪些技能和 Agent 有规范，以及每项 最近一次检查的时间。技能的实际效果只有在运行时才能体现：在项目的临时副本中， 针对真实请求，使用和不使用该技能，并在你使用的每个模型上进行测试 （Anthropic 的 Agent Skills 最佳实践，“先构建评估”）。

---

阶段 1：解析参数

根据第一个参数确定模式：

• static [name] → 对单项技能运行 7 项结构检查，或对单个 Agent 运行观察项
• static all → 对所有技能运行 7 项结构检查（Glob .claude/skills/*/SKILL.md），并对每个 Agent 运行观察项
• spec [name] → 读取技能或 Agent 及其测试规范，并评估断言
• category [name] → 根据 studio-tests/quality-rubric.md 运行类别专属评分标准
• category all → 对每项技能，以及目录中带有 category: 的每个 Agent，运行类别评分标准
• audit（或不带参数）→ 读取目录，列出所有技能和 Agent，并显示覆盖率

如果参数无法识别，输出用法说明并停止。

旧版规范文件夹。 使用 Glob 查找 CCGS Skill Testing Framework/catalog.yaml。如果该文件存在，先说明：“CCGS Skill Testing Framework/ 已在 1.2.0 中重命名为 studio-tests/，此技能仅读取 studio-tests/。请将你编写的所有规范移至该目录；UPGRADING.md（v1.1.3 → v1.2.0，studio-tests/）说明了具体方法。” 然后继续使用 studio-tests/。

在运行 spec 或 category 前解析名称。 在 studio-tests/catalog.yaml 中查找：skills: 下的条目是技能 （.claude/skills/[name]/SKILL.md）；agents: 下的条目是 Agent （.claude/agents/[name].md）。如果目录中没有对应条目，则使用这两个文件中 实际存在的那个。只有当两个文件都不存在时，才报告“'[name]' 既不是 .claude/skills/ 中的技能，也不是 .claude/agents/ 中的 Agent。”并停止。 即使名称也是普通词汇，也应将其视为名称：/skill-test spec help 测试的是 /help 技能，而不是请求本技能的用法说明。

这 7 项检查用于检查 SKILL.md 结构，因此只适用于技能。给定 Agent 名称时， static 仅运行以下观察项：Agent 文件没有可检查的阶段或判定关键词。绝不要将 该 Agent 报告为缺失。

---

阶段 2A：静态模式 — 结构检查器

对于每个待测试的技能，完整阅读其 SKILL.md 和 references/ 文件夹中的所有文件， 并将它们作为一个技能整体执行全部 7 项检查——最长的技能会将各阶段分别放在 references/ 中。前置元数据检查（1、6 和 7）读取 SKILL.md。

检查 1 — 必需的前置元数据字段

文件的 YAML 前置元数据块必须包含以下所有字段：

• name:
• description:
• argument-hint:
• user-invocable:
• allowed-tools:

FAIL：缺少任何字段。如果文件的前置元数据无法解析，也视为检查 1 失败； 格式错误的 YAML 属于本项检查要捕获的结构缺陷，而不是无法评估的文件；请参阅下方的每技能结果规则。

检查 2 — 多个阶段

技能必须至少有 2 个带编号的阶段标题。查找以下模式：

• ## Phase N 或 ## Phase N:
• ## N.（带编号的顶层章节）
• 如果阶段没有明确编号，至少有 2 个不同的 ## 标题

FAIL：找到的类阶段标题少于 2 个。

检查 3 — 结论关键词

技能必须明确说明结果。以下任一项均可接受：

• 关卡／审查结论 — PASS、FAIL、CONCERNS、 APPROVED、BLOCKED、COMPLETE、READY、COMPLIANT、NON-COMPLIANT
• 继续／停止结论 — PROCEED、PIVOT、KILL、GO、NO-GO
• 严重程度等级 — CRITICAL、HIGH、MEDIUM、LOW。审计类技能会按严重程度 对发现的问题进行排序，而不是对整个运行给出单一结论。

FAIL：如果以上关键词均不存在，且技能会生成评估——其描述或正文承诺进行审查、审计、检查、关卡判断或就绪度判断。

WARN（绝不判为 FAIL）：如果以上关键词均不存在，且技能的输出是产物或值，而非判断结果。/settings 是参考示例：它会输出并写入配置，没有需要给出的结论。不要为了满足本项检查而凭空添加结论。

如果采用更狭窄的列表——只接受关卡结论，其他情况一律判为 FAIL——就会错误地判定一些技能失败，原因并非它们自身的问题：/prototype 和 /vertical-slice 在各自的描述中声明了 PROCEED/PIVOT/KILL，/adopt 和 /security-audit 按严重程度排序，而 /settings 则按设计不提供结论。一个会对合理模式造成误判的检查器将不再受人信任。

检查 4 — 协作协议用语

技能必须包含先征得同意再写入的措辞。查找以下内容：

• "May I write"（规范形式）
• 文件写入指示附近的 "before writing" 或 "approval"
• 同一章节中彼此相邻的 "ask" 和 "write"

WARN：如果未找到（部分只读技能可以合理地省略此项）。 FAIL：如果 allowed-tools 包含 Write 或 Edit，但未找到先征得同意再写入的措辞。

检查 5 — 后续步骤交接

技能结尾必须包含推荐的下一项操作或后续路径。查找以下内容：

• 提及另一个技能的末尾章节（例如 /story-done、/gate-check）
• “Recommended next” 或 “next step” 等措辞
• “Follow-Up” 或 “After this” 章节

WARN：如果未找到。

检查 6 — 分叉上下文复杂度

如果前置元数据包含 context: fork，技能应至少有 5 个阶段标题 （## 级标题或带编号的 Phase N 标题）。分叉上下文适用于复杂的多阶段 技能；简单技能不应使用它。

WARN：如果设置了 context: fork，但阶段少于 5 个。

检查 7 — 参数提示合理性

argument-hint 不能为空。如果技能正文提到多种模式 （例如 “Mode A | Mode B”），参数提示应体现这些模式。将参数提示与第一个阶段中 的 “Parse Arguments” 部分交叉核对。

WARN：如果参数提示为 ""，或文档中说明的模式与参数提示不一致。

Agent 与委派观察（不计分）

对技能运行 bash .claude/scripts/agent-check.sh --skill [name]， 对 Agent 运行 bash .claude/scripts/agent-check.sh --agent [name]，或运行一次 bash .claude/scripts/agent-check.sh 执行 static all。它只会打印 观察结果，不会给出结论，且这里的任何内容都不会改变技能的结论。请在 Observations: 下报告，并逐项评估：

• DELEGATION: 技能中将工作交给 Agent 的部分。阅读后说明任务简述是否给出了目标、输出格式、工具和来源、边界，以及它交给 Agent 的工作是否只需调用少数几次工具，或是重新检查技能自身的工作。其 markers: 是指示查看位置的词数，不是评分。
• AGENT: 已设置的模型、工作量和轮数限制，以及描述旁列出的工具：指出描述中的任务不需要的任何工具。
• NOTE: 无法解析的 frontmatter；asks-user（Agent 没有提问工具，因此问题应放在其报告末尾）；被忽略或实际作用超出说明的设置（agent-type-list、preload-off、disallowed-specifier、memory-grants）。
• OVERLAP: 两个描述共享的独特词语：说明每个描述是否仍能明确区分自己的 Agent，或者哪种请求会被错误地交给另一个 Agent。

如果脚本无法运行，请写 Observations: not run (<reason>)。不要省略该部分：缺少该部分会被视为没有发现问题。

兼容性观察（不计分）

对技能运行 bash .claude/scripts/compat-inventory.sh --skill [name]， 对 Agent 运行 bash .claude/scripts/compat-inventory.sh --agent [name]，或运行一次 bash .claude/scripts/compat-inventory.sh 执行 static all。每个 FOUND: 行都表示文件依赖 Claude Code 独有的功能，并列出了相应功能：问题、子 Agent、技能加载、shell 行、参数、frontmatter、指令、钩子、设置或工具。Claude Code 会运行这些功能，因此它们都不是缺陷，也不会改变结论。在 Compatibility: 下报告，每项功能占一行，并列出对应结构和行号；对于 static all，改为按功能给出 COUNT: 总数。一条 NOT FOUND: 行表示名称未匹配到任何文件：请如实说明。如果脚本无法运行，请写 Compatibility: not run (<reason>)。

---

静态模式输出格式

针对单个技能：

=== Skill Static Check: /[name] ===

Check 1 — Frontmatter Fields:    PASS
Check 2 — Multiple Phases:       PASS (7 phases found)
Check 3 — Verdict Keywords:      PASS (PASS, FAIL, CONCERNS)
Check 4 — Collaborative Protocol: PASS ("May I write" found)
Check 5 — Next-Step Handoff:     WARN (no follow-up section found)
Check 6 — Fork Context Complexity: PASS (8 phases, context: fork set)
Check 7 — Argument Hint:         PASS

Observations (not scored):
  Delegation, "Phase 3: Implementation" (line 202): ux-designer, ui-programmer.
    The brief names the output file and limits but no sources to read.

Compatibility (not scored):
  questions: AskUserQuestion (lines 13, 88) · shell-lines: shell-line (line 10)
  frontmatter: allowed-tools, argument-hint, model, user-invocable (lines 4-7)

Verdict: WARNINGS (1 warning, 0 failures)
Recommended: Add a "Follow-Up Actions" section at the end of the skill.

针对单个 Agent：不提供结论，只提供观察结果：

=== Agent Static Check: qa-lead ===

Model: inherit · Effort: unset · Turn limit: 20
Tools: Read, Glob, Grep, Write, Edit, Bash. Fits the job (it writes test plans).
Observations (not scored):
  asks-user (lines 31, 52): tells the agent to get approval before writing.
  overlap with qa-tester (creation, regression, test): each still singled out.
Compatibility (not scored):
  frontmatter: tools, tools-string, model, maxTurns (lines 4-6)

WARN 或 FAIL 行会在括号中说明原因，且任何非 COMPLIANT 结论都以一行 Recommended: 结尾，指出修复方法。

单技能的 Verdict: 是四种值之一，与 static all 的 Result 列相同：COMPLIANT（无警告、无失败）、WARNINGS（有警告，无失败）、NON-COMPLIANT（有任何 FAIL），或 NOT ASSESSED（文件无法读取或解析，或检查无法运行——请注明原因）。

对于 static all，先输出汇总表，然后列出任何不合规的技能：

=== Skill Static Check: All 74 Skills ===

Skill                  | Result       | Issues
-----------------------|--------------|-------
gate-check             | COMPLIANT    |
design-review          | COMPLIANT    |
story-readiness        | WARNINGS     | Check 5: no handoff
...

Summary: 48 COMPLIANT, 3 WARNINGS, 1 NON-COMPLIANT, 1 NOT ASSESSED
Aggregate Verdict: N WARNINGS / N FAILURES / N NOT ASSESSED

Agents (observations, not scored): 49 read
  asks-user: N agents · agent-type-list: N · preload-off: N · frontmatter: N
  Overlap pairs: [each pair, with whether both are still singled out]
  Delegation blocks: N in N skills; [the ones whose brief lacks a part]

Compatibility (not scored): N FOUND lines in N of N files read
  [feature]: [construct] N files, N hits; ...   (one line per feature)

NOT ASSESSED 在此处是单个技能的结果，不只是汇总行。 如果技能文件缺失或因其他原因无法读取（权限不足、文件未找到），导致无法开始任何检查，则应报告为 NOT ASSESSED 并注明原因——绝不能从表格中省略，也不能计为 COMPLIANT。其排名高于 COMPLIANT，低于 WARNINGS 和 NON-COMPLIANT。若文件已读取，但其 frontmatter 无法解析，则属于不同情况：检查 1 会失败（见上文），因此应报告为 NON-COMPLIANT，而非 NOT ASSESSED——这是技能本身的缺陷，不是检查工具无法访问文件。

还要说明分母。 标题中的 All 74 Skills 必须是实际检查的数量，而不是存在的技能总数：两者不同时，报告 [N] of [M] skills checked。汇总计数之和若小于标题中的数量却未作说明，正是此技能旨在发现的问题。

静态模式下不写入任何文件。

---

阶段 2B：规范模式 — 行为验证器

步骤 1 — 定位文件

使用在第 1 阶段解析出的技能文件或 Agent 文件。 从 studio-tests/catalog.yaml 中查找规格文件路径——使用匹配的 skills: 或 agents: 条目中的 spec: 字段。

如果缺少其中任何一项：

• 缺少技能或 Agent：第 1 阶段的消息。
• catalog 中缺少规格文件路径： "No spec path set for '[name]' in catalog.yaml."
• 在指定路径找不到规格文件： "Spec file missing at [path]. Run /skill-test audit to see coverage gaps."

步骤 2 — 读取两个文件

完整读取技能文件——其 SKILL.md 和 references/ 文件夹中的每个文件——或 Agent 文件，以及测试规格文件。

步骤 3 — 评估断言

根据运行模型能看到的内容进行评估。 技能在会话中运行，生成的 Agent 在自己的上下文中运行；两者都会加载项目的 CLAUDE.md，以及通过 @path 行导入的所有文件（生成的 Agent 会逐字引用 coordination-rules.md，但不会读取该文件）。也要读取这些文件。其中陈述的规则适用于每项技能和 Agent——请注明规则出处文件。如果技能或 Agent 自身的文件与之矛盾，以其自身文件为准：它是更具体的指令。

对于 Agent，需根据 Agent 文件评估规格中的各章节；还要评估其 frontmatter 在 skills: 下列出的每项技能，因为 Claude Code 会在 Agent 启动时将这些技能加载到 Agent 中：

• 静态断言 — 逐项对照 Agent 的 frontmatter 和正文进行检查。断言若指定了字面值（如 model: 别名、frontmatter 键、工具名称），则必须与文件精确匹配：model: inherit 不符合“模型层级为 sonnet”，近似匹配始终判定为 FAIL，而非 PARTIAL。
• 测试用例 — 按照下文评估技能测试用例的方式，根据 Agent 的书面指令评估每个用例的预期行为。若用例指定了门槛 ID（LP-FEASIBILITY、CD-PILLARS 等），则应调用该门槛：生成技能会先让 Agent 读取 .claude/docs/director-gates/[gate-id].md，因此该文件中的 Prompt 和 Verdicts 就是 Agent 对此用例的指令——也要读取该文件。
• 重定向和升级处理用例 — 要求 Agent 执行由其他角色负责的工作，或遇到无法自行解决的冲突。若已加载的 coordination-rules.md 涵盖了相应步骤，则该用例符合要求——规则 2（不在自身职责范围外作出有约束力的决定）、规则 3（将冲突升级给共同上级）或规则 5（未经授权，不得操作其目录之外的文件）——并且 Agent 自身的文件在协作对象、委派、升级处理或“禁止事项”列表中写明了负责该工作的角色。请引用两处；不要求 Agent 用自己的措辞复述重定向要求。若 Agent 文件声称此类工作由自己负责，或没有任何已加载文件说明其负责者，则判定为 FAIL。
• 协议合规性 — 使用规格自带的 ## Protocol Compliance 列表，代替下文的四项技能检查。

对于技能，以同样的方式，逐项根据技能的 frontmatter 和正文（SKILL.md 及其 references/ 文件）检查规格中的每条静态断言；字面值必须精确匹配。/skill-test static 只运行其 7 项固定检查，因此规格自身的静态条目——例如 verdict 关键词、阶段、在指定文件前提出的“我可以写入吗”——只会在此处评估。

本步骤的其余内容同时适用于技能和 Agent。

对规格中的每个测试用例：

1. 阅读夹具描述（假设的项目文件状态）
2. 阅读预期行为步骤
3. 阅读每项断言复选框

如果用例没有夹具，则将其输入视为夹具；如果没有断言列表，则将每条预期行为项目视为一项断言——大多数 Agent 规格都采用这种写法；不能仅因为没有单独的检查清单，就不定义用例的判定结果。 对于每项断言，评估在正确遵循技能的书面说明且符合固定测试数据状态的情况下，是否能满足该断言。这是一项由 Claude 评估的推理检查，而非代码执行。

为每项断言标记：

• PASS — 技能说明明确满足此断言
• PARTIAL — 技能说明部分涉及此断言，但存在歧义
• FAIL — 在给定固定测试数据的情况下，技能说明无法满足此断言
• NOT ASSESSED — 完全无法评估此断言：它指定了规范从未定义的固定测试数据状态、依赖静态阅读无法确定的运行时行为，或引用了不存在的文件或章节（文件只是未说明相关行为时，应标为 FAIL 或 PARTIAL，而非此项）。其排名高于 PASS（无法评估的断言并未得到满足），且低于 PARTIAL 和 FAIL（有人识别出的歧义比无人能触及的问题更具可操作性）。不要因为技能“可能”会处理，就把无法评估的断言判为 PASS——规范的目的正是取代这种判断。

对于技能的 Protocol Compliance 章节（始终存在），应像评估案例断言一样，逐条对照技能文件评估规范自身列表中的每一项——标记为 PASS、PARTIAL、FAIL 或 NOT ASSESSED。规范会列出案例中未重复的规则（“由以上协议合规断言覆盖”），因此，不予评估的列表就成了一组无人检查的规则。若列表未涵盖以下四项检查，则将其作为最低要求补充：

• 检查技能是否要求在写入文件前询问“我可以写入吗”
• 检查技能是否在请求批准前先展示评估结果
• 检查技能是否以建议的下一步结束
• 检查技能是否避免未经批准自动创建文件

Step 4 — 生成报告

=== Skill Spec Test: /[name] ===
Date: [date]
Spec: studio-tests/skills/[category]/[name].md

Static Assertions:
  [PASS] [assertion text]
  [NOT ASSESSED] [assertion text]
     Reason: [why it could not be evaluated]

Case 1: [Happy Path — name]
  Fixture: [summary]
  Assertions:
    [PASS] [assertion text]
    [FAIL] [assertion text]
       Reason: The skill's Phase 3 says "..." but the fixture state means "..."
  Case Verdict: FAIL

Case 2: [Edge Case — name]
  ...
  Case Verdict: PASS

Protocol Compliance:
  [PASS] Uses "May I write" before file writes
  [PASS] Presents findings before asking approval
  [PARTIAL] No explicit next-step handoff at end

Overall Verdict: FAIL (1 case failed, 1 protocol line partial)

案例判定取其各项断言中最差的结果；总体判定取静态断言、各案例和 Protocol Compliance 中最差的结果，顺序如下： FAIL、PARTIAL、NOT ASSESSED、PASS。只要有一项断言无法评估，总体结果就不能是 PASS。

对于 Agent，标题格式为 === Agent Spec Test: [name] ===，Spec: 应填写其在 studio-tests/agents/ 下的路径，并在案例 1 之前放置 Static Assertions: 区块。

Step 5 — 提出写入结果的请求

“我可以将这些结果写入 studio-tests/results/skill-test-spec-[name]-[date].md 并更新 studio-tests/catalog.yaml 吗？”

如果对方同意：

• 将结果文件写入 studio-tests/results/
• 更新 studio-tests/catalog.yaml 中对应技能或 Agent 的条目：
  • last_spec: [date]
  • last_spec_result: PASS|PARTIAL|FAIL|NOT ASSESSED — 总体判定

---

Phase 2D：类别模式 — 量规评估

Step 1 — 定位技能和类别

使用 Phase 1 中确定的技能或 Agent 文件。 在 studio-tests/catalog.yaml 的 skills: 或 agents: 条目中查找 category: 字段。

如果两个文件都不存在：使用 Phase 1 的消息。 如果没有 category: 字段：“目录中的 ‘[name]’ 未指定类别。请先在其条目中添加 category: [name]。”

对于 category all：收集所有带有 category: 字段的技能和 Agent，并分别用表格报告技能和 Agent。 category: utility 技能仅针对 U1（静态检查通过）和 U2（如适用，门控模式正确）进行评估——U1 请跳转至静态模式。 对照 .claude/skills/*/SKILL.md 和 .claude/agents/*.md（Audit 模式的 Step 2 glob）进行交叉检查：按名称列出目录中缺失的技能或 Agent，或目录中存在但未设置 category: 的条目，并将其标为 NOT ASSESSED——不得在本轮中悄然排除。

步骤 2 — 阅读评估标准章节

阅读 studio-tests/quality-rubric.md。 提取与类别匹配的章节（例如，### gate、### team；Agent 的类别位于 ## Agent Categories 下，例如 ### director）。 如果评估标准中没有该类别对应的章节，结果为 NOT ASSESSED： 指出缺少的章节，绝不能借用其他类别的指标。

步骤 3 — 阅读技能

完整阅读技能的 SKILL.md 和 references/ 文件夹中的每个文件，或 Agent 的 .claude/agents/[name].md， 以及项目上下文 Phase 2B 步骤 3 所述的内容 — CLAUDE.md 或其导入的文件中的规则如果满足某项指标，则该指标视为满足，并引用该文件。其关于重定向和升级处理的规则也决定领域、延迟处理和升级指标（D2、D3、L2、S1–S3、O2）。

步骤 4 — 评估评估标准指标

对于类别评估标准表中的每项指标：

1. 检查技能或 Agent 的书面指令是否明确满足该项标准
2. 标记为 PASS、FAIL、WARN 或 NOT ASSESSED（无法评估该指标 — 说明原因）
3. 对于 FAIL/WARN/NOT ASSESSED，指出文本中的具体缺口（引用相关章节、注明其缺失，或说明无法评估的内容）

步骤 5 — 输出报告

对于 Agent，标题为 === Agent Category Check: [name] ([category]) ===。

=== Skill Category Check: /[name] ([category]) ===

Metric G1 — Review mode read:      PASS
Metric G2 — Director panel width:  FAIL
  Gap: Phase 3 spawns only CD-PHASE-GATE at `workflow: full`; TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE absent
Metric G3 — Lean mode: PHASE-GATE only: PASS
Metric G4 — Solo mode: no directors:    PASS
Metric G5 — No auto-advance:       PASS

Verdict: FAIL (1 failure, 0 warnings)
Fix: Size the Phase 3 panel from `modes.workflow` — PR at `minimal`, TD + PR at
     `standard`, all four at `full` — and name any perspective a narrower panel leaves out.

类别判定结果按以下顺序优先匹配：FAIL（存在任意失败指标）；否则为 WARNINGS（存在任意警告指标）；否则为 NOT ASSESSED（存在任意无法评估的指标，例如评估标准章节缺失、文件无法读取）；否则为 PASS（所有指标均通过）— 与静态模式和规范模式的优先级相同。结果记录在目录的 last_category_result 中。

步骤 6 — 提议更新目录

“可以更新 studio-tests/catalog.yaml，记录此类别检查的结果（last_category、last_category_result）吗？对象是 [name]。”

---

阶段 2C：审计模式 — 覆盖报告

步骤 1 — 阅读目录

阅读 studio-tests/catalog.yaml。如果文件缺失，注明目录尚不存在（首次运行状态）。

步骤 2 — 列出所有技能和 Agent

Glob .claude/skills/*/SKILL.md，获取完整技能列表。 从每个路径中提取技能名称（目录名称）。

Glob .claude/agents/*.md，获取完整 Agent 列表 — 覆盖范围以仓库本身为准，而不是目录（.claude/rules/skill-authoring.md §5： gate 会推导其覆盖范围，不会枚举该范围）。将两次 glob 的结果与目录中的 skills:/agents: 条目进行比较，并按名称报告目录中缺失的任何技能或 Agent，以免未编入目录的项目悄然遗漏。

步骤 3 — 构建技能覆盖表

对于每项技能：

• 检查是否存在规范文件（使用目录中的 spec: 路径，或 glob studio-tests/skills/*/[name].md）
• 从目录中查找 last_static、last_static_result、last_spec、last_spec_result、 last_category、last_category_result、category（如果目录中没有，则标记为 “never”/“—”）
• 优先级取自目录的 priority: 字段（critical/high/medium/low）

步骤 3b — 构建 Agent 覆盖表

对于目录 agents: 部分中的每个 Agent：

• 检查是否存在规范文件（使用目录中的 spec: 路径，或 glob studio-tests/agents/*/[name].md）
• 从目录中查找 last_spec、last_spec_result、last_category、 last_category_result、category

步骤 4 — 输出报告

=== Skill Test Coverage Audit ===
Date: [date]

SKILLS (74 total)
Specs written: 73 (99%) | Never static tested: 74 | Never category tested: 74

Skill                  | Cat      | Has Spec | Last Static | S.Result | Last Cat | C.Result | Priority
-----------------------|----------|----------|-------------|----------|----------|----------|----------
gate-check             | gate     | YES      | never       | —        | never    | —        | critical
design-review          | review   | YES      | never       | —        | never    | —        | critical
...

AGENTS (49 total)
Agent specs written: 49 (100%)

Agent                  | Category   | Has Spec | Last Spec   | Result | Last Cat | C.Result
-----------------------|------------|----------|-------------|--------|----------|----------
creative-director      | director   | YES      | never       | —      | never    | —
technical-director     | director   | YES      | never       | —      | never    | —
...

Top 5 Priority Gaps (skills with no spec, critical/high priority):
(none if all specs are written)

Skill coverage:  73/74 specs (99%)
Agent coverage:  49/49 specs (100%)

审计模式下不写入任何文件。

询问：“是否要运行 /skill-test static all，检查所有技能的结构合规性？运行 /skill-test category all，执行类别评估标准检查？或者运行 /skill-test spec [name]，执行特定行为测试？”

阶段 3：建议的后续步骤

任何模式完成后，提供上下文相关的后续建议：

• 执行 static [name] 后：“运行 /skill-test spec [name]，以在测试规范存在时验证行为是否正确。”
• 执行 static all 且存在失败项后：“优先处理不合规的技能。逐个运行 /skill-test static [name]，获取详细的整改指导。”
• 执行 spec [name] 并通过后：“更新 studio-tests/catalog.yaml，记录本次通过的日期。可以考虑运行 /skill-test audit，查找下一个规范缺口。”
• 执行 spec [name] 未通过后：“检查未通过的断言，并更新技能、Agent 或测试规范，以解决不匹配问题。”
• 执行 audit 后：“从优先级为 critical 的缺口着手。使用 studio-tests/templates/skill-test-spec.md 中的规范模板（Agent 使用：agent-test-spec.md）创建新规范。”