audit

<tool_restrictions> EnterPlanMode and ExitPlanMode are banned. This skill is Arc's own structured process. </tool_restrictions>

<arc_runtime> Requires the full Arc bundle. Arc-owned paths (agents/, references/, disciplines/, templates/, scripts/, rules/, skills/) resolve from the plugin root — the directory containing agents/ and skills/. Everything else is the user's repository. </arc_runtime>

<platform_context> Adapt to the current harness rather than assuming Claude tool names — task tracking, structured questions, and subagent delegation each degrade gracefully when absent. Load references/platform-tools.md when a mapping isn't obvious.

Where native task tracking exists, check for an existing task for this audit and mark it in_progress before starting. </platform_context>

<required_reading> Load each at the phase that needs it, not up front:

Phase	Load
1 — detect	references/audit-detection.md, references/audit-signals.md
3 — dispatch	references/audit-reviewer-rules.md, references/audit-reviewer-prompts.md, disciplines/dispatching-parallel-agents.md, references/maintainability-review.md
3 and 4 — score and calibrate	references/audit-scorecard.md, references/audit-stage-calibration.md
4 — vet	references/finding-vetting.md
5 — report	templates/audit-report.md

Load when relevant:

• references/react-audit-signals.md — React, Next.js, TanStack Query, or React Native projects. Pass the relevant sections into reviewer prompts as audit signals.
• references/index.md — the full reference catalogue, when a finding needs background you can't name a file for. </required_reading>

<rules_context> Project coding rules come from .ruler/ when it exists, otherwise Arc's own rules/.

references/audit-reviewer-rules.md lists which rules each reviewer receives and the frontend implementation checks for daniel-product-engineer and accessibility-engineer. Load it before composing reviewer prompts.

These inform implementation and accessibility checks only. Do not score visual taste, invent a visual direction, or create redesign findings; defer visual direction to the project's design source of truth. </rules_context>

Parse arguments:

• $ARGUMENTS may contain:
  • A path (e.g., apps/web, packages/ui, src/)
  • A plain-language focus (e.g., "security", "performance", "architecture", "accessibility")

Do not advertise audit flags or variants. If the user provides a path or focus, treat it as scope guidance for the same default audit workflow.

Gardening modes (lightweight, run periodically):

The harness that earns trust decays: docs drift from code, rules go stale. When the focus is "doc gardening" or "rule gardening", skip reviewer dispatch and run the matching cheap pass instead. These are cheap enough to run on a cadence, not only when something is wrong.

• Doc gardening — walk the project's documentation (README, docs/, AGENTS.md, CONTEXT.md, package docs) and, for each claim, check it against the code. Fix what is clearly stale (wrong paths, renamed commands, dead links); flag what needs a human decision.
• Rule gardening — check that the project's written rules (.ruler/ or rules/) are still followed. For each violation, ask whether it is intentional before flagging. Flag dead rules for deletion: never triggered, no longer relevant, or already enforced mechanically elsewhere (linter, boundaries, CI).