system-audit

系统审计

你正在对 Ane 的 MEL/SRHR 系统进行质量、健全性和效率审计。输出一份 Tier 1 工作简报，列出问题及其文件路径，并给出排序建议。你不会执行修复。Ane 会逐项审查并确认。

使用时机

• Ane 输入 /system-audit、/audit、/system-check，或要求检查系统健康状况
• 进行任何 /li curate 之前（审计会发现 curate 应整合的问题）
• 完成实质性的 Agent 改进工作之后，以确认没有发生偏移
• 定期执行，防范悄然发生的偏移

此技能与 /test（仅测试框架）和 /li lint（仅 wiki）互为补充，而非重复。它会进行更广泛的检查，以发现不同层之间的不一致。

工作流程

步骤 1 — 测试框架状态（快速、机械）

按以下顺序运行：

1. python tests/run_tests.py（静态测试；报告它打印的数量，切勿引用记忆中的数字）
2. python tests/run_tests.py --output（夹具模式；某些夹具可能有意未捕获）

解析失败项。将每一行 [FAIL] 按原样连同文件:行号加入发现列表。不要重新运行失败项，也不要尝试修复；只需记录。

本地测试框架全绿不代表整体全绿。阅读最新的 routine-reports/weekly-health-check-*.md，并将其中的测试框架行与刚才的运行结果进行对比。 每周云端例行检查会在配置方式不同的环境中运行同一提交；依赖环境输入的检查可能在云端失败，却在本地通过。报告这两个数字，并将数量或判定中的任何差异都视为发现项，而不是云端的不稳定。这个差异中藏着两个不同的失败，本地运行都无法发现：一项检查因一半词汇来自远程环境未安装的文件而在远程失败；另一项检查的计数在远程更低，因为 glob 遍历了一个空根目录，并报告了针对零个文件的汇总通过。第二种更危险，因为它看起来像是成功。案例背景（2026-09-09 迁移后审计）：本地运行 380/380，全数通过；而云端例行检查自 2026-08-31 起至少十天都报告 318/319，且明确失败。原因是 workflow-drift:qa_block fields resolve 从 qa-block-schema.md 加上 vi/SKILL.md 构建字段词汇表，其中两个字段只记录在技能文件中。本地通过无法暴露这一问题。计数不同时，在修改检查本身之前，先诊断远程缺少哪些输入；通常是规范来源不完整，而技能文件一直在暗中弥补。比较检查名称，而不是总数；诊断前先模拟云端环境。 将 HOME、USERPROFILE 和 PERSONAL_SKILLS_CLONE 指向一个空文件夹，并设置 CLAUDE_CODE_REMOTE=true，运行测试框架；从两次运行中收集 Suite.results 的名称，然后对名称集合进行差异比较。2026-10-07，417 与 358 的差距主要来自重复名称（本地每个 agents 目录都会运行一次每 Agent 检查），真正远程缺失的检查只有 13 项。同一模拟还重现了上次修复未涉及的云端失败。忽略模拟中的 git-identity 失败：它们是由空主目录造成的。

3. 在依据 SKILLS_DIR 进行任何度量之前，先解析它，并报告返回的根目录。 运行 python -c "import sys; sys.path.insert(0,'tests'); import run_tests as rt; print(rt.SKILLS_DIR, len(list(rt.SKILLS_DIR.glob('*/SKILL.md'))))"。多个安装根目录中都存有 SKILL.md 副本，且这些副本彼此存在差异，因此，依据错误根目录测得的行数、预算检查结果或覆盖率声明都不正确。切勿根据 CLAUDE.md 或本技能文件中写明的路径推断根目录；应以测试框架的结果为准。 两次运行的检查总数相同，并不能证明技能变更没有影响，因为基于 glob 的遍历无论覆盖多少文件，每次都只报告一项汇总检查。

   然后将该根目录与 personal-skills 克隆进行比较，列出根目录中缺失的技能，以及内容不同的技能。2026-07-29，解析出的根目录完全缺少 7 项第一方技能，另有 6 项副本已过时，但测试框架仍报告全绿；审计简报最初还因猜测而非解析根目录，写错了目录。两者不同时，复制之前先判断哪一方较旧（比较行数和 diff 方向）：较新的一方不一定是已安装的一方，而且复制操作会覆盖你指定的一方。使用 diff -q --strip-trailing-cr，不要使用 cmp：在 Windows 上，已安装的根目录存有 CRLF 副本，而源文件使用 LF；2026-10-07，按字节比较报告了 21 项误报差异。

第 2 步 — 文档一致性（严重程度中，影响高）

并行阅读：

• ~/.claude/CLAUDE.md — 检查是否存在自相矛盾。常见情况：专家数量不一致（同一文件中出现「16」与「20」）、版本号不一致、层级表不一致。
• <work folder>/CLAUDE.md — 检查是否存在过时数字（专家数量、harness 检查数量、页面数量、Agent 团队成员数量）。
• {ann,vi,li,researcher}/SKILL.md 必须位于你在第 1 步中解析出的 SKILLS_DIR 下，不要使用硬编码路径 — 检查行数与预算是否相符（从 tests/run_tests.py 中的 SKILL_BUDGETS 读取当前数字，该处是权威来源；此处引用的数字不要轻信，它们会过时）。报告剩余空间，不要只报告通过或未通过：技能文件距离预算上限不足 5 行也属于问题，因为下一次编辑会让 harness 因行数计算而失败，而不是因内容本身失败。检查正文中的 em dash 数量（遵循 CLAUDE.md 的语气规则；该规则对技能文件中的列表项分隔符和 frontmatter 有例外）。
• agent-improvements/agent_registry.md — 统计 ### 条目数量。与 Vi 分类表交叉核对是否完整。对照 ~/.claude/agents/<name>.md，逐一确认每个名称对应的文件是否存在。

对每项发现，记录：文件路径、显示的行号、问题所在，以及下方故障修复表中的建议修复方法。

第 3 步 — Overlay 和 CURATE 状态（严重程度中）

并行阅读：

• agent-improvements/{ann,vi,li,researcher,community}-overlay.md — 检查文件大小（上限 35KB）和 Active 条目数量（上限 10）。任一超限：标记为需要压缩的 CURATE，而不只是仅归档的 CURATE。对 community-overlay.md（记录 claimed-space 反馈的日志，创建于 2026-05-06）也要检查相同上限。
• agent-improvements/coordination-log.md — 统计 STATUS: OPEN 条目数量。
• agent-improvements/_pending-ingest.md — 统计 Status: PENDING 行数。提醒 Ane 处理。
• agent-improvements/PROPOSED-*.md — 检查每个文件的 Status: 字段。标记任何已超过 7 天的 AWAITING APPROVAL。

第 4 步 — 清理（严重程度低，杂乱显眼）

检查：

• agent-improvements/_temp_*.md — 超过 7 天的文件都可能已过时。使用 ls -la 获取日期。
• agent-improvements/proposed-agents/*.md — 对每个 .md 文件（README 除外），检查是否存在 ~/.claude/agents/<same-name>.md。若存在，部署后就应该删除暂存副本。使用 diff -q 确认两者是否不同。
• agent-improvements/SESSION-STATE-*.md — 阅读每个文件；检查是否存在内部矛盾（表格单元格与项目符号内容相互矛盾，或进度状态字段不一致）。
• mel_wiki/wiki/raw/ 的大小 — 不应为空（不可变性规则规定 Li 只读、不修改；如果为空，则表示摄取已停止）。

步骤 5 — 架构上限（决策，而非缺陷）

阅读：

• agent-improvements/qa-rejection-log.md — 将其视为案例登记表，而非比率计量表（其标题已于 2026-09-09 撤回比率趋势追踪；趋势数据需等待至少 20 条符合条件的记录）。只有 Ann/Vi 编排的运行会通过 /wrap-up 检查 4b 写入该日志。因此，在将日志空白称为遥测缺口之前，应统计同一时间段内 cost-calibration-log.md 中的编排运行次数：没有运行就意味着日志为空是正确的，这一发现反映的是使用情况，而非缺陷（2026-10-07：自上次记录以来，140 条记录中没有编排运行）。qa-disagreement-log.md 仅供历史参考；它已于 2026-07-30 停止作为实时计数器使用，且 Vi/Li 升级观察触发器因无法测量而撤回；不要把其中的记录计入观察项（2026-08-05 的审计误将其计入，这是沿用了过时的等级系统副本，并将已废止的上限报告为“正在监控”）。
• agent-improvements/cost-calibration-log.md — 统计具有观测到的实际数据与标记为 not observed 的记录。如果实际数据占比低于 30%，可观测性仍然较弱。
• claude.ai 镜像大小 — 镜像现在由两个文件组成：mel-framework-reference.md（核心：常设规则、速查表、视角、ECA 校准）和 mel-framework-appendix.md（编号的框架条目），于 2026-07-30 在 194KB 时拆分。**不要再次提出合并大小阈值。**阈值曾三次上调（2026-04-28 的 117KB 基准、2026-05-10 的 174.7KB、200KB），每次上调都只撑了一周左右，因为问题从来不在大小：claude.ai 没有文件 API，因此任何编辑都会迫使人手动重新粘贴被编辑文件的全部内容。这次拆分直接解决了这个问题，因为现在编辑常设规则只需重新粘贴 30KB，而非 194KB。大小问题不再由你判断：/test 每次都会通过 claude-ai:framework core ≤ 50KB 强制执行；若框架条目又移出附录，该检查就会失败；此外还会通过 claude-ai:framework mirror build stamp current in both halves 检查两部分是否保持同步。这里的判断检查只有在 Ane 调用审计时才会触发，而测试框架始终会触发。你仍需负责的是：运行 python scripts/check_desktop_sync.py，并报告任一部分是否与 claude.ai 上的内容不同步，因为没有脚本能查看实际写入项目知识库的内容。
• wiki 正文中的破折号规范。直接运行 grep -c "—" 会过度计数：它会匹配章节标题、title: 前置元数据、表格行、列表项中的 term — definition 分隔符，以及逐字引用标题中的破折号，这些都不违规。先过滤掉结构性噪声：grep -rnE "—" mel_wiki/wiki/ --include="*.md" | grep -vE ":[0-9]+:#|title:|\||\[\["。将过滤后的计数与最近一次审计偏差基线对比；趋势比绝对计数更重要。人工检查剩余项，因为列表定义中的破折号和引用标题仍会通过筛选；如果逗号会造成真正的歧义，则允许使用同位语结构。

步骤 6 — 延续近期审计漂移项

如果存在 agent-improvements/audit-drift-*.md：

1. 读取最新文件（按文件名中的日期排序）。
2. 检查此前标记的每个问题是否已解决。
3. 将未解决的问题延续到本次发现中，并标记为 [carry-forward from audit-drift YYYY-MM-DD]。
4. 重新标记之前，先根据权威来源核实数值预算。 如果延续的问题中提到了数值预算（行数上限、文件大小上限、令牌上限），请先找到该上限的权威定义：tests/run_tests.py 中的 SKILL_BUDGETS 或 P1_SECTION_TOKEN_CAP，或该问题引用的具名配置。确认这项指标仍然存在且数值未变。如果上限已废弃或更改，则将问题降级为 [stale heuristic, not a live breach]，指出实际管辖的指标，不要重新标记旧数值。背景案例：2026-04-30，测试框架将总行数上限替换为分节令牌上限（P1_SECTION_TOKEN_CAP），但“index.md > 200 lines”违规仍被延续并标记为当前问题。此子步骤不重新实现测试框架：/test 负责执行预算；审计只负责避免重新标记已废弃的预算。

这样可以避免同一问题在每次审计中都被重新标记为新问题，也能避免问题在审计之间被悄然遗漏。

步骤 7 — 技能触发与引导完整性（skill-quality）

应用四部分技能评估标准：触发、结构、引导、精简。其中三项已在其他地方涵盖。技能创建者评估会检查触发质量；superpowers:writing-skills 会检查结构；步骤 3 至 4 和测试框架预算会检查精简。本步骤补充这些检查遗漏的维度：引导，即触发的技能是否确实能约束 Agent 的行为。

阅读 personal-skills skills/ 树下的第一方技能，以及 {ann,vi,li,researcher} 团队技能。对每项技能检查以下三点：

• 触发冲突。 两项可由模型调用的技能，其 description 触发短语存在重叠，且两者都未指定将对方作为转交对象。对 description: frontmatter 行进行 grep，查找共用的触发动词（grill、review、plan、debate、design），并逐一目视检查重叠的技能对。带有 disable-model-invocation: true 的技能只能由用户调用，不会发生冲突，因此应排除。更具体的技能在其描述中明确自身适用范围，并将相邻技能引导到其他方向时，冲突即视为已解决（参见 grill-mel 示例）。
• 引导力度。 正文是否为 Agent 提供具体、有序的操作、编号工作流、决策规则、输出模板或“不要做什么”清单？还是只点明主题，让 Agent 自行发挥？触发后却不能约束行为的技能，就是引导失败。若技能正文中没有命令式工作流、决策规则和输出部分，则应标记。标记前必须阅读正文，绝不能仅凭标题中的关键词扫描来评估这一维度。 渐进式披露技能是常见的假阳性：其 SKILL.md 刻意保持简短，并将引导内容委托给 references/ 或 scripts/ 目录，这也算引导充分。2026-08-15，一次基于标题关键词的扫描标记了七项技能，但逐项阅读后发现七项都符合要求，因为它们的关卡、模式路由和编号阶段位于扫描未匹配到的标题下。先检查同级目录，再阅读。
• 引导内容泄漏。 正文是否允许 Agent 做出描述中禁止的行为？例如，技能声明“不会写入文件”或“禁止写入”，但正文没有任何防止写入的约束；或技能声明“不做决定”，但正文却逐渐开始替 Agent 做决定。应标记描述与正文相矛盾的情况。
• 清单可见性——在读取任何文件之前，先观察这一点。 查看会话开始时加载的可用技能清单，记录哪些技能只显示名称，没有描述。描述未出现在清单中的技能无法通过触发词匹配来选择，因此它只能由用户主动调用，尽管原本并非如此；其描述中的所有路由词也都不起作用。文件检查无法发现这一问题：2026-07-30，9 个第一方技能只显示名称，而 54 个已安装技能在全部 4 个安装根目录中都成功解析，且都具有正常的 description；磁盘上没有任何属性能区分受影响和未受影响的技能（属于同一安装批次，mtime 相同，没有 BOM，描述长度也有重叠）。之后也无法补查，因为清单在会话开始时就已固定，无法重新观察。因此，请在第一轮回复中、打开任何文件之前记录这一情况。原因已经查明，Ane 也已作出决定，因此记录受影响的技能并继续，不要重新推导原因。 名称单独显示是技能清单的既定预算行为，并非缺陷或 Anthropic 的 bug：skillListingMaxDescChars（默认值为 1536）会限制每条描述的长度，skillListingBudgetFraction（默认为上下文窗口的 0.01）会限制整个清单的长度；清单超出预算后，描述就会被截断。Ane 最初决定维持现状，只有在承载关键功能的技能被截掉时才重新审视（agent-improvements/handoffs/system-audit-follow-ups.md，已锁定的决定 1）。这一条件于 2026-10-07 达成，她在 ~/.claude/settings.json 中将 skillListingBudgetFraction 提高到 0.02；新会话确认 proposal、tor-procurement 和 toc-builder 再次显示。如果某个可由模型调用的技能再次被截掉，请报告此事，并建议下一步仅更改设置，将值调至 0.03，待 Ane 同意后再操作。2026-08-15 的检查从头重新推导原因，并将其报告为无法解释的缺陷；这正是本段旨在避免的浪费。因此，请报告受影响的技能，并说明其中是否有承载关键功能的技能；不要着手调查原因，也不要编辑技能文件来修复此问题，因为缺失发生在清单中，而非文件里。一种预期的仅显示名称的情况可以缩小检查范围：带有 disable-model-invocation: true 的技能按设计只显示名称，因此应在标记问题之前排除。不要一概排除 Workflow 条目（.claude/workflows/*.js）。 2026-08-05 版规则曾这样做，当时认为无论 Workflow 的 meta 中包含什么内容，它们都只会显示名称。2026-08-15 的检查推翻了这一说法：3 个 Workflow 都带有 description 和 whenToUse，但 citation-verification 完整显示了描述，而 deliverable-qa 和 vi-execution 只显示名称。Workflow 也可能显示描述，因此一概排除会掩盖两个真实问题。只有当 Workflow 的 meta 中既没有 description 也没有 whenToUse 时才排除，因为这时它没有可显示的内容。若某个技能可由模型调用，或某个 Workflow 的 meta 正常，但其描述未出现在清单中，就应标记。

将每项记录为一条发现，注明技能路径和出现问题的维度（listing-unreachable、trigger-collision、steering-weak 或 steering-leak）。此规则依据 Pocock（2026）《打造出色的 Agent 技能：缺失的手册》改编；引导维度是此步骤为审计新增的内容，而清单可见性维度则是在 2026-07-30 添加的，此前一次检查正确评估了 5 个技能的路由，却漏掉了其中一个技能根本无法通过路由触达的问题。

第 8 步 — 冲突指令审计（已加载内容 lint）

重叠和矛盾的指令会在任务开始前消耗模型的判断力；对于 Claude 5 生成模型，这种故障模式的影响超过缺少规则（Shihipar 2026，Anthropic 上下文工程指南）。审计每个会话都会加载的内容：~/.claude/CLAUDE.md、项目的 CLAUDE.md、输出样式块，以及会话列表中可由模型调用的技能描述。

1. 重复且存在偏差的指令。 同一规则出现在两个内容面中，但措辞、范围或数字不同。对两个 CLAUDE.md 文件执行 grep，查找共享的锚点短语（规则名称、阈值、文件路径），并对匹配段落进行 diff。治理标记区域的重复是有意的，目的是保持 Web 端一致：对于这些区域，请比较匹配的 governance:* 标记对之间的共享规则文本，只标记偏差，绝不要把重复本身标记为问题。
2. 矛盾。 一个内容面要求另一个内容面禁止的事，或针对同一行为设定不同阈值（权限模式、长度上限、引用位置）。逐一核对候选项，并报告双方的文件和行号。
3. 触发归属。 同一行为被两个内容面认领，例如技能描述和 CLAUDE.md 规则都声称拥有同一个触发条件。根据项目 CLAUDE.md 技能路由部分的触发纪律规则解决。

为每项发现分类：矛盾（中）、重复且存在偏差（中），或治理区域之外的良性重复（低，可考虑采用目标 + 指针的方式处理）。治理内容的修复路径为 governance-rules.md + sync_governance_rules.py，绝不要在标记之间手动编辑。

故障-修复映射（快速参考）

问题类别	最可能的修复方法
CLAUDE.md 中的专家数量偏差	将过时数字替换为当前 agent_registry.md 中的数量
Vi 分类表缺少专家	添加与 agent_registry.md 条目匹配的行
Vi 模型规则与注册表冲突	使 Vi 与注册表的 model_default 字段一致；注册表具有权威性
技能文件超出预算	压缩说明文字；将细节移至 wiki；只有在万不得已时才编辑 tests/run_tests.py 中 Ann/Vi/Li/Researcher 的技能上限
正文说明中出现 em dash	按照 mel-report-writer 的示例模式转换（同位语 → 逗号；列表引导语 → 冒号；断句 → 句号）
过时的 _temp_*.md 文件	如果超过 7 天且当前未被引用，则执行 git rm
proposed-agents/ 中存在已部署的 Agent	对暂存副本执行 git rm；~/.claude/agents/ 中的副本是正式版本
Overlay 超过 35KB 上限	执行实质性 CURATE（压缩条目，而不仅是归档）；在这个大小下，Li 仅归档的处理方式不够
qa_block 架构与技能不匹配	架构具有权威性；使技能文本与架构字段名称一致
两个可由模型调用的技能之间存在触发冲突	在更具体的技能描述中标明处理路径，并将相邻路径导向别处；或者对 Ane 总是按名称调用的技能设置 disable-model-invocation: true
引导力弱的技能（会触发但不构成约束）	在正文中添加编号工作流、决策规则或输出模板；仅有描述无法起到引导作用
引导约束泄漏（正文允许描述中禁止的行为）	在正文中添加与描述约束一致的明确限制（例如，禁止写入的技能应声明不得使用 Write/Edit）
已加载内容面之间的指令冲突或重复偏差	保留一条权威声明，并将其他副本替换为指针；治理区域须通过 governance-rules.md + sync_governance_rules.py 重新生成，绝不可手动修改。

输出格式

Tier 1 工作简报。首句给出结论。不得使用 em dash（你正在审计 em dash 的使用规范，不能违反正在检查的规则）。使用通俗英语。使用主动语态。每句不超过 25 个单词。遵循 CLAUDE.md 中的“Tier 1 working brief”规则。

使用此模板：

# System audit — YYYY-MM-DD

**BLUF: [N issues found, M severity-medium, P severity-low, Q architectural decisions. None blocking. X are quick fixes.]**

## Tests run
- python tests/run_tests.py: N/N
- python tests/run_tests.py --output: M/N (deferred fixtures noted)
- Manual audit of: [list]

## Documentation drift (medium severity)

| # | Issue | File | Fix |
|---|---|---|---|

## Skill trigger and steering (medium severity)

| # | Skill | Axis (trigger-collision / steering-weak / steering-leak) | Fix |
|---|---|---|---|

## Conflicting instructions (medium severity)

| # | Directive | Surfaces (file:line vs file:line) | Class (contradiction / duplicate-drifted / benign duplicate) | Fix |
|---|---|---|---|---|

## Hygiene (low severity)

| # | Issue | Evidence | Fix |
|---|---|---|---|

## Architectural ceilings (decision points)

| # | Issue | Implication |
|---|---|---|

## What is working

- [5-8 bullet items: harness clean, qa_block schema operational, P1 triple-load fix landed, etc.]

## Recommended sequencing

- Quick batch (~30 min): [issue numbers; mechanical edits]
- Focused pass (~1 hour): [issue numbers; need judgement]
- Strategic decision: [issue numbers; require Ane's call]

**Evidence base:** [inline file paths]

不要做的事

• 不要自动执行修复。Ane 会逐项审查并运行。
• 不要将已知的延期事项标记为新问题。请交叉核对 agent-improvements/system-audit-*.md 和 audit-drift-*.md，确认哪些内容已有记录并已获接受。
• 不要重复报告测试框架的输出。如果 python tests/run_tests.py 已通过静态方式覆盖某项检查，只需报告测试框架的结果，不要重新推导该发现。
• 不要打分。那是 /grade-system 的职责。
• 不要吹捧系统。问题数量要如实，严重程度也要如实。

收尾

提交简报前，标记维护周期：python ~/.claude/hooks/maintenance_due.py --mark system-audit 2>/dev/null || true（在没有此 hook 的机器上不执行任何操作，例如 Web 容器）。

简报结尾写上：“现在要我执行快速批次修复吗？”然后等待。Ane 确认后再执行。

如果 Ane 确认，执行快速批次（机械性编辑）。对于重点审查项目，每项都要再征求一次确认——这些项目涉及判断，应由 Ane 逐项批准。对于战略决策项目，绝不自动执行。

成本区间

~30–60k 个 token，用于完成一轮常规审计。如果有许多发现需要交叉核实，耗时会更长。未超过 200k 的系统改进上限，仍有充足余量。