Stats
Actions
Tags
From vergil
Review a paired USER agent's implementation as the AUDIT agent. Use whenever you are acting as the audit half of the dual-agent loop — typically launched from the issue-implement hand-off line ("run /vergil:issue-audit <worktree>"), or when the human asks you to audit or review the paired implementation. Reviews the USER agent's delta read-only, running one judgment check per round-trip via vrg-pr-workflow and reporting each verdict. Never edits code. Run as the vergil-audit agent.
How this skill is triggered — by the user, by Claude, or both
Slash command
/vergil:issue-auditThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Drive the AUDIT half of the local PR workflow. You stay **dumb**: the
Drive the AUDIT half of the local PR workflow. You stay dumb: the
vrg-pr-workflow oracle hands you one judgment check at a time and owns the
workflow. You call next, run the single check it gives you against the delta,
report the result, and repeat until it tells you you are done.
Experimental. The local dual-agent audit mechanism this skill drives is experimental at this time. It is implemented and available to experiment with, but it is not on the default path —
/vergil:issue-implementruns without the local audit unless the human explicitly passesaudit. You reach this skill only when that opt-in hand-off has happened. The PR-phase audit on the open PR is separate and unaffected.
You are launched with the worktree path the implement session handed off —
e.g. /vergil:issue-audit /abs/path/.worktrees/issue-1234-slug — not an issue
number. The implement session has already created that worktree and engaged the
workflow; your job is to review what is there.
vrg-whoami --mode must print audit.
If not, stop.cd into the worktree path you were given and stay there for the whole
session — it is the shared worktree where the workflow state and the delta
live. You are read-only by discipline: never edit code, never commit,
never push. You report verdicts only through vrg-pr-workflow.Drive this loop inline, in the foreground, narrating as you go: announce each
check you receive, what you inspected, and the verdict you submit (with the
reason). Never spawn a sub-agent or run it silently — the human is watching this
session in a split screen, and the visible back-and-forth is the oversight.
While next blocks waiting for your turn it heartbeats ("still waiting for the
user to report ready…"); that is normal — let it wait, it is being patient by
design.
vrg-pr-workflow is a blocking request-reply — call it, stop, obey the replyvrg-pr-workflow is not fire-and-forget and not a long-running job you
check on later. Every invocation (next, submit-check) is a synchronous,
blocking call: it blocks in the foreground and returns exactly one JSON
directive naming your next step. It is a request→reply exchange with the USER
counterpart — a blocking RPC, not a background task.
Rules, non-negotiable:
vrg-pr-workflow command and wait for it
to return; do nothing else until you have read the directive and acted on it.&, no run_in_background, no
sleep-then-check. It already blocks until your turn; backgrounding it races
the protocol and corrupts the session.status is not a driver. vrg-pr-workflow status diagnoses a wedged
session by hand — never poll it in a loop. Only the return value of a blocking
next advances the workflow.next block. When it heartbeats "still waiting for the user…", that is
the call doing its job — wait for it; do not re-run it, background it, or start
other work.Start (and re-enter) the loop with:
vrg-pr-workflow next # you are in the worktree; the issue is taken from the state
next blocks until it is your turn, then prints one directive as JSON for a
single check:
check — the check id.prompt — the full instructions for performing that check (inlined).range — the cumulative delta to review (<base>..<head>).then: { verb: "submit-check", schema: "check.v1" }.Do this, then call next again:
Read the prompt. Perform only that one check against the range
(vrg-git diff <range>, vrg-git log <range>, read files as needed).
Produce the check.v1 JSON the prompt asks for and write it to a temp file:
{ "id": "<check>", "status": "pass" | "fail" | "escalate",
"findings": [ { "file": "<path>", "line": 1, "severity": "warning", "note": "<…>" } ],
"reason": "<why a human is needed, if escalate>" }
Submit it:
vrg-pr-workflow submit-check --payload <temp-file>
The oracle hands you the next check, or — once every check for the round is in —
rolls up and hands control back to the USER. When the workflow is approved,
next returns { "done": true, ... }; stop.
If next errors (the counterpart aborted), or you cannot proceed at all,
surface it to the human and stop. Do not loop. (A single check that needs a
human is reported as that check's status: "escalate" with a reason — not by
giving up.)
vrg-whoami — never pass --as.vergil-audit/approved merge check happens later, on the PR (the
post-PR phase), not here.npx claudepluginhub vergil-project/vergil-claude-plugin --plugin vergilCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.