IMPLEMENTAUDIT
On this page
  1. 1. Paste one request
  2. 2. Watch what gets written
  3. 3. If the skill is not loaded
  4. 4. If evidence fails
  5. 5. Trust it only if
  6. What happens next
  7. What should feel different
First run

Quick Start

This page walks through the first IMPLEMENTAUDIT run from the user's point of view.
You paste one concrete repo request into Claude Code or Codex, then look for the files and markers that prove the run stayed bounded.

If this is your first time and the command below feels too fast, open For new users first, then return here for the canonical first command.

1. Paste one request

If the skill is already loaded, start here.
Open Claude Code or Codex from the repository you want changed and paste one concrete repo request into chat:

Concrete taskstart
/implementaudit add tests for the login timeout bug

If you already have findings, point at them directly:

Findings fileaudit
/implementaudit close the findings in AUDIT.md
No audit file required for the first try.
A normal repo request is enough; IMPLEMENTAUDIT creates or binds the work record (audit object) before it edits.

2. Watch what gets written

A good run creates inspectable evidence instead of relying on chat memory.
For phased or larger work, inspect the run folder.
For compact work, require the final response to identify the bound work record, cited artifacts, final audit ledger, and transcript markers.

Compact work may not create .IMPLEMENTAUDIT/runs/<task-slug>-<id>/; in that case, the bound work record is located by the final response, final audit ledger, cited artifacts, and marker order. A run folder is expected only when the work is phased.

.IMPLEMENTAUDIT/runs/<task-slug>-<id>/
  STATE.md
  ROADMAP.md
  THINKING.md
  PROTOCOL.md
  tools.md
  context.md
  sidecars.md                             # optional-tool status and fallback
  phases/phase-N.md
  applied-context.md / applied-memories.md  # prior context, if loaded
  repo-map.md                              # file/dependency map, if created

Transcript markers such as AUDIT_COMPLETE appear in the chat or final transcript, not as run-folder files.

Run folder, when phased.IMPLEMENTAUDIT/runs/<task-slug>-<id>/
State file<run-root>/STATE.md records current phase, audit-object state, decisions, and authorization state.
Roadmap and phase checklistFor phased work, <run-root>/ROADMAP.md and <run-root>/phases/phase-N.md show promised work before editing.
Before/after evidenceBefore/after checks (Smoke A/B) appear in phase evidence and command output cited by the run.
Failure logFor phased work, <run-root>/STATE.md -> ## Andon log records class, cause, countermeasure, and rerun evidence.
Final audit ledgerThe final audit ledger, cited artifacts, and transcript markers explain closure or handoff.

3. If the skill is not loaded

Use the install path for your host, then return to the pasted request above.
Install verification covers package extraction and integrity only; it does not prove the host loaded the skill.

Claude CodeUse Claude Code's current plugin or skill install/update flow, then verify the host shows the skill before treating it as loaded.
CodexUse the release-asset install or manual skill copy path, then verify the local host can load /implementaudit.

Open the full installation page.

4. If evidence fails

The run should not retry blindly and should not fake completion.
The visible path is:

  1. Evidence fails.
  2. Stop the line.
  3. Classify abnormality.
  4. Inspect cause.
  5. Choose a bounded countermeasure.
  6. Rerun the relevant check.
  7. Escalate only with new evidence.
  8. Hand off only on a real blocker.

The formal interrupt loop is Andon, but the ordinary meaning comes first: failure becomes visible, recorded, and bounded.

check failed  login timeout test still red
ANDON_PROBE  class: failed-criterion; cause: missing timeout assertion
countermeasure  add bounded test case only
rerun evidence  relevant timeout test passes against baseline
outcome  resume phase or hand off if still blocked

5. Trust it only if

A good run ends with AUDIT_COMPLETE before IMPLEMENTAUDIT_RUN_COMPLETE.
That means the final audit found final, checkable evidence for the in-scope items.
It does not mean the agent committed, pushed, tagged, released, or published anything.

  • For phased work, the run folder exists and STATE.md shows the current phase or closure state.
  • The roadmap or phase checklist exists before you accept edits.
  • Before/after evidence is present for the edited scope.
  • Any failed check has a failure row, cause, countermeasure, rerun evidence, and outcome.
  • AUDIT_COMPLETE appears before IMPLEMENTAUDIT_RUN_COMPLETE. If blocked, a handoff names the blocker and next owner action instead.

What happens next

  1. Request - a concrete repo task or audit finding enters the run.
  2. Work record - the agent binds the request to inspectable evidence; phased work also claims a run folder.
  3. Plan - the planner writes a bounded roadmap and phase checklist when the work needs phases.
  4. Inspect - the agent reads real files before promising edits.
  5. Check - before/after evidence is recorded.
  6. Interrupt - failure stops work and records the path.
  7. Close - final audit verifies or hands off honestly.

What should feel different

A normal agent run can blur planning, editing, retrying, and done.
The first IMPLEMENTAUDIT run should make those boundaries visible:

  • request
  • run folder or work record
  • state
  • checks
  • interruption
  • final audit