Vc Audit

Invocation for vc-audit (launcher audit)

Same three-path shape as the fleet, with this skill's literals — see the canonical Delegation Matrix:

• Shared three paths
• Launcher catalogue
• Per-launcher rule
• Native vs external

Path	Literal for this skill
1. User-launched worker	vibecrafted audit <agent>
2. Interactive	/vc-audit — execute in this session; use native subagents when required; do not externalize merely because a launcher exists
3. Agent-operator	may dispatch the worker form above via vc-dispatch / operator lines while preserving this skill's identity

Freer native on some runs ≠ abandon external fleet. vc-dispatch and vc-ship keep their own identities.

vc-audit — READ-ONLY Plan-vs.-Code Falsifier

The falsification charter. Where vc-review says "findings-max on a diff" and vc-followup says "is that codebase going in the desired direction", this one says **"default UNVERIFIED — PASS is earned, but Agents reports are just claims that vere not verified for real task completion. Noone ever tested this code in real life scenarios Noone ever

Operator Entry

Living Tree / Worktree Rule

Runs in the operator's current checkout and current branch. Do not create, switch to, or move execution into a git worktree unless the operator explicitly asks for one. Generic words like "isolate", "parallel", or "clean branch" are not enough. Re-read files before judging final state, adapt to concurrent changes, and report a substrate failure if the tree is too poisoned to continue safely. The one sanctioned second mode is a Fleet Worktree dispatch (written plan, pre-committed verifiers, disjoint domains, single-thread integrator — see Living Tree Rule, Mode B); outside that formation, stay in the shared tree.

See Living Tree Rule.

Canonical Orientation Gate

Before this workflow performs any audit, it MUST consume fresh vc-init evidence for the assigned repo. If absent, run vc-init first; treat audit as blocked until repo truth exists.

Loctree:loctree is the default structural perception layer. Use Loctree before grep / docs / "I remember" claims to materialize the Code-Derived Application Map (repo-view, focus, slice, impact, find, follow). Audit decisions that bypass Loctree on questions Loctree handles (importer graphs, blast radius, dead code, symbol locations) are process failures.

Standard launcher:

vibecrafted start
vc-audit claude --prompt 'Audit the 22-task plan in plans/2026Q2-loctree/'
vc-audit codex  --prompt 'Verify post-marbles surface against acceptance criteria'
vc-audit gemini --file /path/to/plan-and-target.md

Repository Work Doctrine

For repository work, start with Loctree as the map: use loct context, loct occurrences, loct body, and loct find --literal before broad manual search. Use AICX for intent and session context. Use rg/grep as fallback or local magnifier, not as a replacement for structural mapping. If Loctree fails or misses a surface, append feedback to ~/.vibecrafted/loctree/loctree-fail.md.

Purpose

Use this skill when a written plan, spec, or multitask brief claims completion. The implementation may have come from vc-workflow, vc-implement, vc-marbles, human work, or any combination — audit refuses to take the completion claim at face value regardless of upstream. It rebuilds the plan's requirements atomically, then forces each one to defend itself with code + test evidence. Whatever cannot defend itself remains UNVERIFIED.

This skill never modifies code. Editing, refactoring, "fixing while auditing", and committing during audit are all forbidden. The output is a verdict matrix, a report, and a trace — nothing else.

When To Use It

Use vc-audit when:

• a written plan / spec / multitask brief claims completion
• the operator hands over a directory of task files plus a checkout
• vc-marbles finished a round and the codebase claims to satisfy the brief; audit checks what actually landed
• a PR + written spec pair needs spec-vs.-code falsification (not just diff hygiene — that's vc-review)

Do not use this skill when:

• the target is a bare PR without a written spec — that's vc-review
• the target is "this repo, is the direction healthy?" — that's vc-followup
• the operator wants the gaps fixed during the pass — that's vc-marbles (audit never touches code)
• the question is "which truth wins?" — that's vc-polarize

Pipeline Position

vc-audit sits in the plan-vs-code falsification slot. Common upstream paths feed into it:

[workflow] ┐
[implement]├──► [AUDIT: READ-ONLY] ──► next decision
[marbles]  │
[mixed]    ┘

Downstream depends on verdict:

• PASS / PASS_WITH_GAPS → vc-polarize, vc-dou, or vc-release
• PARTIAL / UNVERIFIED → operator decides: another vc-marbles round, back to vc-implement for gaps, or scope cut via vc-polarize
• FAIL → operator escalates: spec rewrite or rebuild from vc-scaffold

Audit is never the terminal step. Output always feeds the next operator decision.

Default Stance: Falsification

Default verdict for every requirement is UNVERIFIED. A requirement earns PASS only with all four:

1. Task evidence — quoted acceptance criterion or non-goal
2. Code evidence — file path, function/type/test name, line range
3. Test evidence — test name + run output, or justified test-gap
4. Negative check — old/forbidden behavior not still present

Hard Non-Trust Rules

You MUST NOT trust task frontmatter status, prior agent reports, commit messages, AICX entries, memory slices, kronika notes, "completed" annotations, PR descriptions, inline // done comments, or prior vc-followup / vc-review reports — unless independently confirmed in current code/tests. Each of those is a claim, not evidence. Audit converts claims into evidence by checking code.

Evidence Taxonomy

PASS requires STRONG or MEDIUM on all core requirements.

Operating Model

Audit proceeds in eight phases. Sequential, not optional. Full phase detail in PHASES.md.

1. Context Receipt — Loctree pack, dirty_worktree, hotspots, authority caveats
2. Task Ingestion Receipt — full-read every task; emit Tasks Loaded table
3. Atomic Requirements Extraction — testable items into audit_requirements_matrix.jsonl
4. Positive + Negative Code Verification — loctree-first, both checks
5. Adversarial Pass — actively prove implementation incomplete (five sub-checks)
6. Stage-Aware Verdict — landed vs. deferred scope
7. Per-Task Verdict Table — one row per task, no narrative collapse
8. Self-Attack Pass + Model Check — attack PASS verdicts; emit model_confidence

Verdicts: PASS, PASS_WITH_GAPS, PARTIAL, FAIL, UNVERIFIED, STAGE_PASS, STAGE_PASS_WITH_GAPS, STAGE_PARTIAL, FULL_PLAN_INCOMPLETE_BY_DESIGN.

Severity: P0 (contradicts task / breaks dependents / violates non-goal), P1 (key criterion missing), P2 (test/report/process gap), P3 (cosmetic).

Output Contract

vc-audit produces exactly three files in the report directory:

1. audit_report.md — executive verdict first, per-task table, self-attack pass, model check
2. audit_requirements_matrix.jsonl — one JSON record per requirement: verdict, evidence grade, code locations, test evidence, negative check result
3. audit_trace.log — compact per-phase trace (BEGIN, READ_CONTEXT_PACK, READ_TASK, EXTRACT_REQUIREMENTS, INSPECT_CODE, VERIFY_TESTS, NEGATIVE_CHECK, DEPENDENCY_CHECK, STAGE_CHECK, CLASSIFY, SELF_ATTACK, WRITE_REPORT, END)

Executive verdict MUST include task counts per verdict, P0/P1/P2/P3 counts, top 5 risks, next five actions, and model_confidence: high | medium | low.

Operator dispatch template lives in DISPATCH.md.

Composition with adjacent skills

vc-audit composes with — does not replace — these:

• vc-init — required gate. Without fresh init evidence, audit is blind.
• vc-review — sibling READ-ONLY role at per-implementation diff scope. Use review for "did this PR look clean?", audit for "did the written spec actually land in code?".
• vc-followup — sibling READ-ONLY role at trajectory scope. Use followup for "is the direction healthy?", audit for "did the spec ship?".
• vc-marbles — common upstream. Marbles plasters cracks in excess; audit checks what survived.
• vc-polarize — common downstream. Polarize consumes the audit verdict to decide which truth wins.

Anti-Patterns

Do not in audit mode:

• fix code during audit ("just a small refactor while I'm here")
• mark PASS based on commit messages, frontmatter, or prior reports
• collapse all tasks into a general summary
• skip the negative check ("new code is there, that's enough")
• skip the adversarial pass or self-attack
• treat Stage 1 landed as full-plan PASS
• treat Stage 2 deferred as full-plan FAIL
• produce only the report without a matrix + trace
• trust AICX / kronika / memory slices as repo truth
• bypass Loctree on importer-graph / blast-radius / dead-code questions
• protect your first verdict during self-attack instead of downgrading

Acceptance Criteria

The audit run is done when:

• Every task / plan file has task_read_status: FULL_READ
• Every requirement has evidence grade + verdict
• Every requirement has positive + negative check results
• Self-attack executed on every PASS / PASS_WITH_GAPS
• Model check emitted with confidence rating
• All three output files written
• git diff empty for non-report paths (no code touched)
• Executive verdict references concrete next move

Call to Action

Read PHASES.md before running your first audit — it carries the per-phase detail and the loctree-first negative-check patterns. Read DISPATCH.md before writing your first operator-dispatch body — it carries the canonical 22-task audit prompt shape. Then default every claim to UNVERIFIED and earn each PASS.

Closing Rail

Delivery-proof semantics live in vibecrafted_core.delivery; see docs/runtime/DELIVERY_PROOF_KERNEL_v1.md.

=======================
Remember: audit mode is permission to refuse a claim, not permission
to fix it. You read the spec, you read the code, you grade the
evidence, you stop. The operator owns the next move.
(•̀ᴗ•́)و
=======================

Suchar: Why does the auditor never say PASS at first? Because
UNVERIFIED is the only mood that ages well.  (._.)

𝚅𝚒𝚋𝚎𝚌𝚛𝚊𝚏𝚝𝚎𝚍. with AI Agents by Vetcoders ©2024–2026 LibraxisAI