system-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

System audit — «что работает / что дрейфует / чего нет / что удалить»

系统审计 — «哪些可用/哪些已漂移/哪些缺失/哪些可删除»

An agent system accretes. Good patterns and bad ones, dead rules nobody reads, facts restated in five places with three of them stale, tools that only ran once. This skill is the periodic sweep that keeps it evolving without inflating: it measures which layers actually fire, deletes what doesn't, and reports findings that carry evidence rather than impressions.

The one thing that makes this audit different from a checklist: every claim must be backed by something you touched with your own hands — a

file:line

, a command's output, a query result. An unverified observation is labelled

гипотеза

and never counted in the verdict.

Agent系统会不断累积内容：既有良好模式，也有不良模式；无人问津的废弃规则；同一事实在五个地方重复表述，其中三处已过时；仅运行过一次的工具。本技能是定期扫描，确保系统持续演进而非膨胀：它会统计哪些层级实际触发过，删除未触发的部分，并基于证据而非主观印象输出审计结果。

**本审计与检查表的核心区别：**每一项结论都必须有确凿的一手证据支持——比如

file:line

（文件:行号）、命令输出、查询结果。未经验证的观察结果会标记为

гипотеза

（假设），且不会纳入最终结论。

Step 0 — Scope, depth, delta (2 minutes, always)

步骤0 — 范围、深度、增量（必做，耗时2分钟）

Depth. Pick from what the user asked, default
```
standard
```
:
- ```
quick
```
  — deterministic collector + lenses 1, 4, 7 inline, no subagents. ~10 min. Use for a routine "как мы", or when the user asks mid-work.
- ```
standard
```
  — collector + all 7 lenses, lenses 2-6 fanned out to parallel
```
recon
```
  subagents (
```
model="sonnet"
```
  ), synthesis + adjudication inline. The default.
- ```
deep
```
  — standard + an independent architecture critique (
```
idea-validator
```
  ,
```
model="opus"
```
  ) and an external-family second opinion (
```
/memory-kit:second-opinion
```
  ), + a fresh-check of external facts (pricing, model ids, deprecated APIs) via WebSearch.
Scope autodetect. Run the collector (step 1) — it reports which layers actually exist in this repo. A lens whose layer is absent is reported as н/п, never invented. Never audit
```
node_modules/
```
,
```
.git/
```
, build output, or vendored code.
Delta. Read the newest prior report in
```
context/audits/
```
(or wherever it lives). For each of its priorities: done · partially · ignored. An audit whose last round was ignored has one finding worth more than all the others — say so first.

深度选择：根据用户需求选择，默认
```
standard
```
（标准）：
- ```
quick
```
  （快速）：确定性收集器 + 视角1、4、7的在线检查，不调用子Agent。耗时约10分钟。适用于常规状态检查，或用户在工作中途发起的审计请求。
- ```
standard
```
  （标准）：收集器 + 全部7个视角，视角2-6并行分配给
```
recon
```
  子Agent（
```
model="sonnet"
```
  ），综合分析与裁决在线完成。默认选项。
- ```
deep
```
  （深度）：标准审计 + 独立架构评审（
```
idea-validator
```
  ，
```
model="opus"
```
  ）和外部第三方意见（
```
/memory-kit:second-opinion
```
  ），并通过WebSearch重新检查外部事实（定价、模型ID、已弃用API）。
范围自动检测：运行收集器（步骤1）——它会报告当前仓库中实际存在的层级。若某个视角对应的层级不存在，则标记为н/п（不适用），绝不凭空捏造。绝不审计
```
node_modules/
```
、
```
.git/
```
、构建输出或第三方依赖代码。
增量对比：读取
```
context/audits/
```
（或存储位置）中最新的上一次审计报告。针对报告中的每一项优先级任务，标记状态：已完成·部分完成·未处理。若上一轮审计的所有任务均未处理，则本次审计首要结论需明确指出这一点。

Step 1 — The deterministic collector (before any reasoning)

步骤1 — 确定性收集器（推理前执行）

bash

undefined

bash

undefined

from the repo being audited; pass a path as $1 to audit a different repo

从待审计仓库执行；传入路径$1可审计其他仓库

bash "${CLAUDE_PLUGIN_ROOT}/skills/system-audit/scripts/collect.sh" > /tmp/system-audit-facts.md


(If this skill lives somewhere else on your machine, run `scripts/collect.sh` from this skill's
own directory — it's read-only and never writes into the audited repo.)

For lens 4 (layer telemetry) also run the transcript profiler — it is the only source of
"did this ever actually fire", and it is read-only:

```bash
python3 "${CLAUDE_PLUGIN_ROOT}/skills/system-audit/scripts/usage.py"

It parses this project's session transcripts and writes

knowledge/usage-frequency.md

: which files, skills and tools were deliberately used (mechanical auto-loads and multi-edit bursts are filtered out), and which have zero reads in 30 days. No transcripts yet → it says so and exits.

The main collector gathers, cheaply and repeatably: layer inventory · doc frontmatter coverage · memory caps · broken path references · git activity and cold files · secret exposure (gitleaks if present, an

.env

-tracked check always) · layer telemetry (per rule/skill/agent: last mention in session transcripts and in git history) · TODO/FIXME density.

Read its output first. It is the factbase; the lenses explain and prioritise it — they don't re-derive it. Anything the script measured is a fact; anything a lens adds must earn its own evidence.

bash "${CLAUDE_PLUGIN_ROOT}/skills/system-audit/scripts/collect.sh" > /tmp/system-audit-facts.md


（若本技能安装在机器的其他位置，请从技能自身目录运行`scripts/collect.sh`——该脚本为只读模式，绝不会写入待审计仓库。）

针对视角4（层遥测），还需运行会话记录分析器——它是唯一能判断“该层级是否实际触发过”的数据源，且为只读模式：

```bash
python3 "${CLAUDE_PLUGIN_ROOT}/skills/system-audit/scripts/usage.py"

它会解析项目的会话记录，并生成

knowledge/usage-frequency.md

：记录哪些文件、技能和工具被主动使用（会过滤机械自动加载和批量编辑操作），以及哪些在30天内无任何读取记录。若无会话记录，脚本会提示并退出。

主收集器会低成本、可重复地收集以下信息：层级清单·文档前置元数据覆盖情况·内存上限·无效路径引用·Git活动与冷文件·秘钥泄露检查（若存在gitleaks则使用，始终检查

.env

文件）·层遥测（每个规则/技能/Agent：会话记录和Git历史中的最后提及时间）·TODO/FIXME密度。

请先阅读收集器输出内容，它是事实基础；各视角会对其进行解读和优先级排序——而非重新推导。脚本测量的内容均为事实；视角补充的任何内容都必须有自身证据支持。

Step 2 — The seven lenses

步骤2 — 七个审计视角

Full briefs (what each lens checks, its evidence rules, its "н/п" condition):

references/lenses.md

. Read it before dispatching.

#	Lens	The question it answers
1	Delivery reality	Does the claimed state (backlog, handoff, README) match disk / git / prod?
2	Knowledge layer	SSOT hygiene: frontmatter, drift, the same fact restated stale in N places, contradictions between SSOTs. Standard: `reference/doc-governance.md` .
3	Operational layer	Rules, agents, memory, the self-improvement loops (findings registry → promotion → drop): coherent and non-contradictory? Standards: `reference/review-loop.md` , `reference/parallel-development.md` .
4	Layer telemetry	Which of those layers ever actually fired? Dead rules, never-invoked skills, agents defined once and never spawned.
5	Tools & infra	Reproducibility (pinned deps, a documented run path), secrets, backup and restore, ownership of external state.
6	Domain gaps	What a professional system of this class has and this one doesn't. The domain is named by the user or inferred; the lens brief lists gap-maps per common domain.
7	Anti-bloat (subtraction)	What to DELETE: never-fired layers, duplicated facts, ceremony with no consumer, over-engineering for a scale that never came.

Dispatch rule for

standard

deep

: lenses 2-6 go to

recon

subagents in one message so they run concurrently; each gets the collector output path, its brief verbatim, the repo root, and the instruction "return raw findings with file:line evidence; do not recommend architecture". Lenses 1, 4 and 7 you run yourself — they need the whole picture and the authority to say "delete".

Model discipline: recon →

sonnet

; critique →

opus

; never pass the orchestrator model down.

完整说明（每个视角检查内容、证据规则、“н/п”条件）：

references/lenses.md

。分配任务前请先阅读。

序号	视角	核心问题
1	交付真实性	声称的状态（待办事项、交接文档、README）与磁盘/Git/生产环境是否一致？
2	知识层	SSOT（单一事实源）卫生：前置元数据、漂移、同一事实在多处重复且部分过时、SSOT之间存在矛盾。参考标准： `reference/doc-governance.md` 。
3	操作层	规则、Agent、内存、自我改进循环（发现记录→升级→淘汰）：是否连贯且无矛盾？参考标准： `reference/review-loop.md` 、 `reference/parallel-development.md` 。
4	层遥测	哪些层级实际触发过？废弃规则、从未调用的技能、定义后从未启动的Agent。
5	工具与基础设施	可复现性（固定依赖、文档化运行路径）、秘钥管理、备份与恢复、外部状态所有权。
6	领域差距	同类型专业系统具备但本系统缺失的功能。领域由用户指定或自动推断；视角说明文档按常见领域列出差距对照表。
7	反膨胀（删减）	可删除内容：从未触发的层级、重复事实、无使用者的形式化流程、针对未达规模的过度设计。

standard

deep

审计的分配规则：视角2-6一次性分配给

recon

子Agent以实现并行运行；每个子Agent会收到收集器输出路径、视角完整说明、仓库根目录，以及指令*“返回带有file:line证据的原始发现；请勿提出架构建议”*。视角1、4、7需自行处理——它们需要全局视角和“删除”权限。

模型规范：侦察任务→

sonnet

；评审任务→

opus

；绝不使用编排器模型处理子任务。

Step 3 — Integrator verification

步骤3 — 集成验证

An audit's only real product is trust in its findings, and that trust is exactly as strong as the weakest unverified claim in it. So subagent reports are INPUT, not record. Before anything enters the report:

Spot-check every load-bearing claim yourself — open the
```
file:line
```
, re-run the command. Proportional to stake: a claim that drives a priority gets checked 100%.
Adjudicate disagreements on merits, never by vote count. One dissenter holding a
```
file:line
```
outranks three abstract concurrences.
Each disputed finding closes as accepted (amended) · rejected WITH evidence · deferred with a named verification step.
A finding you could not verify stays in the report marked
```
гипотеза
```
+ the check that would settle it. Never silently dropped, never promoted to fact.

审计的核心价值是让用户信任其结果，而这种信任的强度取决于报告中最薄弱的未验证结论。因此子Agent的报告仅作为输入，而非最终记录。任何内容纳入报告前需：

亲自抽查所有关键结论——打开
```
file:line
```
对应文件、重新运行命令。抽查比例与重要性成正比：影响优先级的结论需100%验证。
基于事实裁决分歧，而非投票数。一位持有
```
file:line
```
证据的反对者，权重高于三位无证据的支持者。
每个有争议的结论需标记为接受（已修正）· 拒绝（附证据）· 延期（指定验证步骤）。
未验证的结论会在报告中标记为
```
гипотеза
```
（假设），并注明验证方法。绝不静默删除，也绝不升级为事实。

Step 4 — Verdict, severities, priorities

步骤4 — 结论、严重程度、优先级

Severity vocabulary (use these exact markers — they make audits comparable across time):

	meaning
🔴	сломано — a load-bearing thing does not work. Evidence attached.
🟠	дрейфует — works, but the doc/state/fact describing it is stale or contradicted.
🟡	не проверено — a claim nobody has ever tested end-to-end (loops that never ran count here).
⚪	отсутствует — a real gap for a system of this class.
🗑	лишнее — delete candidate.

Then:

The verdict in three lines: что работает · что дрейфует · чего нет. Plain language, no hedging.
Max 5 priorities. Each:
```
what · why now · cost (min/hours) · what breaks if we skip it
```
. A sixth priority is not a priority — park it in the backlog.
The subtraction quota is mandatory: at least 3 🗑 candidates, or an explicit sentence saying the system is genuinely lean and why the telemetry supports that. An audit that only adds is a failed audit.
Cost honesty: if a recommendation costs more than the pain it removes, say so and recommend against it. "Профессиональные системы так делают" is not a reason.

严重程度术语（请严格使用以下标记，确保跨审计周期的可比性）：

标记	含义
🔴	сломано（已损坏）——核心功能无法正常工作。附证据。
🟠	дрейфует（已漂移）——功能可用，但描述它的文档/状态/事实已过时或存在矛盾。
🟡	не проверено（未验证）——从未端到端测试过的功能（从未运行的循环也归此类）。
⚪	отсутствует（缺失）——同类型系统应具备但本系统缺失的功能。
🗑	лишнее（多余）——建议删除的候选内容。

后续操作：

三行结论：哪些可用·哪些已漂移·哪些缺失。语言直白，不含模糊表述。
最多5项优先级任务：每项需包含
```
内容·当前必要性·成本（分钟/小时）·跳过的影响
```
。第六项任务不应列为优先级，归入待办事项即可。
强制删减配额：至少3个🗑候选内容，或明确说明系统确实精简且遥测数据支持该结论。仅新增内容的审计是失败的审计。
成本诚实性：若建议的修复成本高于其解决的问题带来的损失，需明确说明并反对该建议。“专业系统都这么做”不能作为理由。

Step 5 — Close the loop (this is what makes it evolution, not a ritual)

步骤5 — 闭环（让审计推动演进，而非流于形式）

Apply cheap-safe fixes immediately, in this session — a stale path, a missing frontmatter line, an unpinned dep, a broken test. Announce each briefly. Anything with blast radius (deleting a rule, purging history, force-push) → ask first.
Write the report:
```
context/audits/audit-YYYY-MM-DD.md
```
(create the dir if absent) — template in
```
references/report-template.md
```
. It is the delta baseline for the next audit.
Land the rest as tickets in the project's backlog with its own id scheme — not as prose in the report where it dies.
Feed the loops: confirmed finding classes → the findings registry (
```
projects/<name>/review-findings.md
```
, or wherever that project's README maps it); a class on its 3rd occurrence → promote to the CHEAPEST layer that prevents it (deterministic check > agent/spec line > lens brief > knowledge article). Dead layers found by lens 4 → propose the drop.
One line into MEMORY.md, date-tagged: the audit's headline finding.
Tell the user: verdict, the 5 priorities, what you already fixed, what needs their decision.

立即应用低成本安全修复——在本次会话中完成，比如过时路径、缺失的前置元数据行、未固定的依赖、损坏的测试。每项修复简要告知用户。任何影响范围较大的操作（删除规则、清理历史、强制推送）→需先征得用户同意。
撰写报告：保存为
```
context/audits/audit-YYYY-MM-DD.md
```
（若目录不存在则创建）——模板见
```
references/report-template.md
```
。该报告将作为下一次审计的增量基线。
剩余任务转化为工单：纳入项目待办事项并使用项目自身的ID体系——不要仅以 prose 形式写在报告中，以免无人处理。
反馈循环：已确认的问题类别→加入发现记录（
```
projects/<name>/review-findings.md
```
，或项目README指定的位置）；同一问题类别出现3次→升级到能预防该问题的最低成本层级（确定性检查 > Agent/规范行 > 视角说明 > 知识文章）。视角4发现的废弃层级→建议移除。
在MEMORY.md中添加一行带日期标签的内容：审计的核心结论。
告知用户：结论、5项优先级任务、已完成的修复、需用户决策的事项。

Cadence

审计节奏

Run it every ~10 sessions, before a milestone, after a large refactor, when memory trips its caps, or when the user feels the system has bloated. Between runs,

quick

is cheap enough to use as a pulse check. Two audits in the same week on an unchanged repo is itself over-engineering.

每约10次会话、里程碑前、大型重构后、内存达到上限时，或用户感觉系统膨胀时运行审计。两次审计之间，

quick

（快速）模式成本极低，可作为状态脉冲检查。同一周内对未变更的仓库进行两次审计本身就是过度设计。

What NOT to do

禁止事项

Don't report anything you didn't verify as fact.
```
гипотеза
```
is an honest label; a confident wrong finding costs a real fix cycle.
Don't audit the code's business logic — that is a diff-review pass (
```
/memory-kit:session-review
```
covers the session's diff); don't probe the running product — that is
```
/memory-kit:qa-sweep
```
. This audit is about the system that produces the work.
Don't propose a framework. Prefer the smallest deterministic check that prevents a class.
Don't grade on aesthetics. "Could be more structured" is not a finding. "This fact is stated three times, two of them wrong, here are the lines" is.
Don't skip the subtraction quota, and don't delete a shared/rule/doc layer without the user's yes.
Don't let the audit itself grow. If a lens has produced nothing actionable across three runs, drop the lens. The audit is subject to its own rules.

不得将未验证内容作为事实报告。
```
гипотеза
```
（假设）是诚实的标记；自信的错误结论会浪费实际修复周期。
不得审计代码的业务逻辑——这属于差异审查（
```
/memory-kit:session-review
```
涵盖会话差异）；不得探测运行中的产品——这属于
```
/memory-kit:qa-sweep
```
的范畴。本审计针对的是生成工作成果的系统本身。
不得提议引入框架。优先选择能预防问题类别的最小确定性检查。
不得基于美观评分。“可更结构化”不是有效发现。“同一事实表述三次，其中两次错误，对应行号如下”才是有效发现。
不得跳过删减配额，且删除共享/规则/文档层级前需征得用户同意。
不得让审计流程自身膨胀。若某个视角连续三次运行未产生可操作的发现，应移除该视角。审计流程需遵守自身规则。