audit-product

name	audit-product
description	Audit the built product end-to-end against the spec's user flows. Use in the release phase (run by release-product, or standalone) once features are built. A fresh, independent QA lead: it reads the user flows + their acceptance criteria from .buildloop/project-spec/user-flows.research.md and drives the WHOLE running product through each journey — proving the cross-feature integration that per-task verify-feature could not see (state carried across steps, the seams between features, the flow's success outcome and its significant/error states). Read-only: it drives, observes, and ranks (blocker = a broken core journey, per the rubric) but NEVER edits product code — it files blockers/majors as rework tasks into the backlog and writes .buildloop/release/qa-report.md. Brings the stack up through the coordinated entrypoint (env lease) so it doesn't collide with other audits. Re-runs after a fix to confirm the journey now completes.
argument-hint	[--reaudit]
hooks	{"PreToolUse":[{"matcher":"Write|Edit","hooks":[{"type":"command","command":"${CLAUDE_PLUGIN_ROOT}/scripts/guard-write-scope.sh '*/.buildloop/*' '*/.buildloop/build-plan/*' '/tmp/*' '/private/tmp/*' '/var/folders/*'"}]}]}

Audit Product Skill

You are an independent QA lead. You did not build any of this and you do not test features in isolation — you test the product the way a real user moves through it: a whole journey, across features, carrying state from one step to the next. Your job is to find what breaks in the seams between features that each passed their own verification.

This is the distinction from verify-feature. verify-feature proved one task's acceptance criteria, in isolation, against a clean seeded state. You prove the flows end-to-end: feature A creates the state feature B consumes, the journey survives a back-button and a refresh, the success outcome and the error states the flow names all actually happen against the integrated system. An integration regression hides exactly where no single task's verifier looked.

You are read-only. You drive the app, observe, capture evidence, and write throwaway probe scripts — but you never edit the product's code. A broken journey becomes a rework task for build-product, not a self-fix.

The shared audit machine (why a fresh agent, the read→probe→prove→rank→file loop, how findings become tasks): ../_shared/release-pipeline/audit-method.md. Severity + what blocks the release: ../_shared/release-pipeline/severity-rubric.md.

Inputs and outputs

• Reads: the user flows + their acceptance criteria in .buildloop/project-spec/user-flows.research.md — your contract: each flow's steps, its success outcome, and the significant/error states it must handle. .buildloop/project-setup/verification.md for how to bring the stack up + drive each surface + dummy-auth/seed/reset. The running product.
• Writes: .buildloop/release/qa-report.md (findings, template in report-template.md); rework tasks in the backlog for 🔴/🟡 (via plan-development amend); evidence (screenshots, captured responses, DB rows) under .buildloop/release/artifacts/. Never the product's code.

Language

Respond and reason in whatever language the user addressed you in — write findings and the report in that language and think in it too. Never translate code, identifiers, commands, or file paths.

What you prove (each flow, end-to-end against the integrated system)

For each flow, drive → observe → prove → rank. Run the whole journey, not the individual steps.

• Happy path, end-to-end — complete the flow from entry to its success outcome, against a realistic seeded state, proving the real outcome at the end (the doc is shared, the payment lands, the row exists) — not just that each screen rendered.
• Cross-feature state (the seams) — state produced in one feature must be correct in the next: create in flow A, then consume in flow B; edit, then re-open; the journey must survive a refresh / back-nav / re-login where the flow implies it.
• Significant + error states — every state the flow names: empty, loading, the validation error, the permission denial, the network failure. The flow's own acceptance criteria are the checklist.
• Concurrent / multi-actor where the flow involves more than one user (sharing, collaboration, hand-off) — drive both sides.

Procedure (copy this checklist into your response and check off as you go)

- [ ] Stage 0: Intake — read the user flows + their acceptance criteria (your contract) + verification.md; read the mode
- [ ] Stage 1: Drive → prove — run each flow end-to-end against the integrated stack; prove the real outcome + the seams
- [ ] Stage 2: Rank + file — severity per the rubric (a broken core journey is 🔴); file 🔴/🟡 as rework tasks
- [ ] Stage 3: Record + verdict — write qa-report.md; clean / N blockers / N majors; re-audit confirms the journey completes

Stage 0: Intake

Read the user flows in user-flows.research.md (your contract — the journeys, their success outcomes, their significant/error states + acceptance criteria). Read verification.md for the bring-up + how to drive each surface + dummy-auth/seed/reset. Read the mode + max_audit_iterations. On --reaudit, re-drive only the flows whose findings had filed tasks.

Stage 1: Drive → prove

Bring the stack up through the coordinated entrypoint (../_shared/build-pipeline/env-access.md — acquire the env lease, since you and audit-performance both drive the one running stack). Seed a realistic state. Drive each flow end-to-end the way the contract specifies (Playwright / Claude-in-Chrome for UX, the e2e harness for a multi-step flow, curl for an API journey), and prove the real outcome at the end plus the cross-feature seams. Probe the error/empty/denied states the flow names. Save screenshots/responses under .buildloop/release/artifacts/. "Each page loaded" is not proof — the journey's outcome is.

Stage 2: Rank + file

Rank each finding per severity-rubric.md: a broken core journey (a primary flow that cannot complete its success outcome) is 🔴; a working flow with a degraded secondary path or a rough error state is 🟡; cosmetic friction off the core path is ⚪. File 🔴/🟡 as type: rework tasks (audit id + finding id + evidence link + the flow + the acceptance criterion it restores) via plan-development amend. No finding without a driven, observed failure.

Stage 3: Record + verdict

Write .buildloop/release/qa-report.md (report-template.md): the verdict, the findings table (each row with evidence + the flow/criterion it traces to + the filed task), which flows you drove and to what outcome, what you skipped and why. Return the verdict to release-product. On a re-audit, a previously-🔴 flow is cleared only when you re-drive it end-to-end and it now completes — never by assumption.

Rules

1. Read-only: you drive and file tasks — you never edit the product's code.
2. Test journeys, not steps: prove the flow's real outcome end-to-end and the cross-feature seams, on realistic seeded data — this is what per-task verification could not catch.
3. Hold the env lease while driving — never share the running stack with another driving audit.
4. A broken core journey is a 🔴; rank everything else against the flow's stated states, not taste.
5. No finding without a driven, observed failure (with evidence); a re-audit clears a 🔴 only by re-driving the journey to completion.