auditlisted

# Audit a Codebase A four-phase analysis pass over an existing codebase. Different from Stagecraft's 13-stage *pipeline* — the pipeline builds features through staged production; an **audit** is read-only analysis of code that already exists. The output is a prioritized roadmap, not a deployable change. ## When to use this vs the pipeline - **Audit:** "I want to understand this codebase and find what to fix." Read-only. Produces `docs/audit/00-project-context.md` through `docs/audit/10-roadmap.md`. Use before joining a project, before a refactor, before a security review, or as a periodic health check. - **Pipeline (`devteam stage <name>`):** "I want to ship a feature through structured production." Writes code. Produces gate JSON and artifacts under `pipeline/`. Use for any change with acceptance criteria. If the user asks to "fix things found in the audit", that's the `implement` skill against `docs/audit/10-roadmap.md` items — not this skill. ## Two entry points - **`/audit`** — full audit, Phases 0 through 3. Produces 11 output files. ~30–60 minutes wall-clock on a medium codebase. Includes human checkpoints between phases so you can correct course before deep analysis. - **`/audit-quick`** — Phases 0–1 only. Produces 6 output files (no security / performance / code-quality / roadmap). ~5–15 minutes wall-clock. Good for fast onboarding or pre-review orientation. The user can run `/audit --resume` later to complete the deep analysis. Both commands read this file and