Audit Skill Sync

VerifiedCaution

Re-syncs every audit skill against code landed since the last sync: closed-issue sweep, delta read, premise re-measure, and owner-map fold-in.

Sby Skills Guide Bot
DocumentationAdvanced
11/7/2026
Claude Code
#audit-skills#doc-sync#multi-agent#git-delta#issue-tracking

Recommended for

Automated summary

Re-syncs all audit skills (.claude/commands/audit-*/SKILL.md) against the code that landed since the last sync, using a deterministic prep step followed by a parallel agent fan-out.

Strengths

  • Deterministic scripted prep step (prep.sh) that emits usable artifacts: open issues, issues closed since the base, map of cited-closed issues, and per-group weights
  • Explicit guidance for rebalancing groups from the printed weights, backed by concrete numbers from prior runs
  • Clear separation of duties: real bugs surfaced during the sweep are reported to the user, never fixed by the sync
  • Reference-commit tracking via BASELINE, plus an explicit ban on nested sub-agents to avoid lost completion notices

Limitations

  • Tightly coupled to a specific repository layout (BASELINE, groups.txt, _audit-owners.md, .agents/skills shims) and unusable as-is elsewhere
  • Only covers prep, fan-out and collection: no final verification, commit step, or BASELINE update is described
  • Assumes a large commit volume and a heavy background-agent launch, which is overkill for a small repository
When to use it

Run it after a batch of fix commits when the audit skills risk describing issues as still open or citing outdated structures.

When not to use it

Do not use it to audit code or fix bugs, nor in a repository that lacks the described audit-suite structure.

Security analysis

Caution
Quality score78/100

No destructive, exfiltration or obfuscation patterns: no curl|sh, no rm -rf, no credential handling, no disabled safety checks, and no instruction-hijacking text. The risk profile is that of a powerful maintenance workflow — executing an unreviewed local prep script, mass-editing agent-instruction files with parallel sub-agents, and committing — so 'caution' rather than 'safe', but nothing here justifies 'risky'.

Findings
  • •Phase 1 executes a repo-local script `.claude/commands/audit-sync/prep.sh` whose contents are not included in the reviewed material, so its actual behavior (git calls, file writes into the scratchpad) cannot be verified here.
  • •The skill drives wide, automated rewrites of `.claude/commands/**`, `.agents/skills/*` shims and `.claude/agents/*.md`, then a `git commit` — mutation of agent-instruction files at scale, gated only by a textual 'commit only when the user asks' rule.
  • •Phase 2 fans out many background `general-purpose` sub-agents with file-write authority in parallel, with a correctness rule ('never edit a file whose owning agent is still running') enforced only by the orchestrator's discipline.
  • •Runs `cargo test` / `_audit-validate.sh` and `git` commands via bash; legitimate but powerful tooling.
  • •Executes repo-local scripts whose contents are not shipped with this file (`prep.sh`, `_audit-validate.sh`, `_audit-route.sh`); the auditor must review those scripts separately since their behavior cannot be verified from the skill text alone.
  • •Spawns one background `general-purpose` agent per group with write access to `.claude/commands/audit-*` files; broad autonomous fan-out editing many instruction files is powerful and only gated by a later `git diff` review.
  • •Shell usage (`bash`, `cargo test`, `git diff/commit`, `rustup which`, PATH manipulation) and an optional user-requested `git commit` are present, but all are scoped to the repository and non-destructive.
  • •No evidence of destructive commands, network exfiltration, credential handling, base64/obfuscated payloads, or attempts to disable safety checks.
How this analysis is made

Examples

Full sync at HEAD
Run the audit-skill sync: call prep.sh with the current BASELINE, print the per-group weights, split any group over twice the median, then fan out one agent per group and collect the proposals.
Sync from a specific revision
Re-sync all audit skills since commit 9f3c2ab (--base 9f3c2ab) and tell me which cited issues were closed in that window.
New audit skill added
I just added .claude/commands/audit-netcode — add it to groups.txt under a sensible group and run a full audit-skill sync so it gets caught up with HEAD.

description: "Re-sync every audit skill against the code that landed since the last sync — closed-issue sweep, delta read, premise re-measure, owner-map fold-in" argument-hint: "[--base <rev>]"

Audit-Skill Sync

Audit skills describe the code: struct sizes, counts, test names, known-open issues. Fix commits change the code without touching those files, so the skills go stale. In every sync so far, most of the rot has been closed issues still described as open. This skill brings every .claude/commands/audit-*/SKILL.md and the shared _audit-* files back in line with HEAD. It does not audit the code and does not fix it: real bugs that surface are reported to the user, not fixed.

Files in this directory:

  • .claude/commands/audit-sync/prep.sh: the deterministic preparation step.
  • brief.tmpl: the instructions every agent reads.
  • groups.txt: which agent owns which skills.
  • BASELINE: the commit the last sync matched.

Phase 1: Prep

SCRATCH=<session scratchpad>/audit-sync
.claude/commands/audit-sync/prep.sh "$SCRATCH"            # base = BASELINE; override with --base <rev>

The script writes the following into $SCRATCH:

  • BRIEF.md
  • open.txt
  • closed_since.tsv
  • cited_closed_recent_map.txt
  • weights.tsv
  • an empty proposals.md

It also prints each group's weight: the changed files routed to it through _audit-owners.md, and the cited issues closed since the base. It exits non-zero if groups.txt misses an audit-* directory or lists one twice. A newly added audit skill must go into a group first.

Look at the printed weights. If one group carries well over ~2× the median of either number, split it in groups.txt before fanning out. Ten groups was the right size for ~300 commits; the per-game audits each get their own group when their routed counts dwarf the rest (the 2026-10-12 run used fourteen for 239 commits, with fo3 and oblivion split out of the old fo3-oblivion pair; the 2026-10-15 run used sixteen for 337 commits, splitting scripting (157 routed files, 22 cited-closed: the M47.2 VM wave) from papyrus-character and fo4 from starfield; the 2026-10-20 run used seventeen for 379 commits, giving performance its own group apart from renderer). Two skills' routed counts are inflated by churn, not code: regression (every .claude/issues/ note) and tech-debt (the docs/audits/ reports, other docs/ edits, .claude/commands/). Discount those two before splitting.

Phase 2: Fan out

Launch one background general-purpose agent per groups.txt line, all in a single message. Each prompt contains:

  • an instruction to read $SCRATCH/BRIEF.md first and follow it exactly;
  • the exact files the agent owns (.claude/commands/audit-<skill>/SKILL.md plus any helper scripts in that directory);
  • the main delta paths for its skills (crates and byroredux/src modules from _audit-owners.md);
  • any skill-specific hot spots: issues from cited_closed_recent_map.txt, or a session closeout in HISTORY.md that touched the area.

The meta group also owns the following, and should check that every shim's description still matches its skill:

  • _audit-common.md, _audit-owners.md, _audit-severity.md, _audit-validate.sh, _audit-route.sh;
  • the .agents/skills/source-command-* shims, which are thin pointers to the canonical command;
  • the .claude/agents/*.md specialists: they rotted for five months because no sync group and no validator glob reached them; 88ea1a2f6 (#5839) added them to the validator corpus and this group, and their layout facts must point at CLAUDE.md / docs/engine (or a live ls / grep) instead of hand-typed trees or file lists.

Agents must not start sub-agents. A nested agent's completion notice never reaches its parent (see /audit-suite, orchestration hazard).

Phase 3: Collect

As each report arrives:

  1. Append its "proposed edits to files I don't own", code gaps and fixed-but-open issues to $SCRATCH/proposals.md. Keep a heading per group.
  2. Once that agent is finished, fold any proposal aimed at another agent's skill into that skill yourself. Never edit a file whose owning agent is still running. Check each claim against the code before you write it: an agent's proposal is a lead, not a fact.

After the meta agent finishes, fold in all the _audit-owners.md row proposals:

  • Rows are first-match prefixes, so a specific row goes above the general row it narrows.
  • Never drop an owner that the general row gave the path, unless the proposal says why.
  • Check each new row with printf '%s\n' <path> | .claude/commands/_audit-route.sh.

Phase 4: Verify

bash .claude/commands/_audit-validate.sh 2>&1 | grep -E 'FAIL|STALE|OK:'
git diff --stat -- .claude .agents

Skill-reading tests: rerun any whose matched text was touched.

| Test | Reads | Run | |---|---|---| | gpu_material_size_claims (4 tests) | every .claude/commands file | cargo test -p byroredux-renderer --lib gpu_material_size_claims | | the_audit_skill_does_not_claim_the_rt_integrity_chain_is_unread | audit-renderer | bin crate, below | | documented_texture_role_list_matches_the_struct | audit-nifal, audit-fo4, _audit-common.md | bin crate, below |

To re-derive the list: git grep -n '\.claude/commands' -- '*.rs', keeping the non-comment hits. The skin_offsets_hasher_tests.rs guards pin _audit-common.md's hot-path rule in code but never read the file.

The bin crate needs rustc ≥ 1.96 (wasmtime 49's MSRV since 15a6b1d2d; #4466 set the earlier 1.94 floor): TC=$(rustup which --toolchain 1.96.0 cargo); PATH="$(dirname "$TC"):$PATH" "$TC" test -p byroredux --bin byroredux -- <filter>.

Phase 5: Close

  1. Write the HEAD that prep reported (<short-hash> <YYYY-MM-DD>) into BASELINE. That is the commit the agents synced against, not a later HEAD.
  2. Report to the user:
    • one line per skill on what was wrong and what changed;
    • real code gaps or bugs to file, after checking each one yourself;
    • issues fixed in code but still open, with their fixing commits. A Fix #A, #B subject auto-closes only #A.
  3. Commit only when the user asks: docs(audit): re-sync audit skills against <base>..<head>.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/audit-skill-sync-mvhm5m12/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/audit-skill-sync-mvhm5m12' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/audit-skill-sync-mvhm5m12/download' --output '.skill-downloads/audit-skill-sync-mvhm5m12/SKILL.md.part' && mv '.skill-downloads/audit-skill-sync-mvhm5m12/SKILL.md.part' '.skill-downloads/audit-skill-sync-mvhm5m12/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

This file does not provide a usable name/description header for this native procedure. It remains available to download and inspect; use the manual method below.

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/audit-skill-sync-mvhm5m12/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills