/product-audit

name: product-audit
user-invocable: true
disable-model-invocation: true
version: 3.1.0
metadata:
  opencode/autoinvoke: false
argument-hint: <path-or-area> (optional — defaults to the whole product)
author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
license: MIT
description: >
  Audit the whole product across code, quality, process, docs, roadmap, and
  tooling. Persist one severity-ranked, F-numbered report with proposals; never
  fix or file work. Triggers: "product-audit", "audit the product", "full health
  check", "are we product-ready", "CTO review".

Product Audit

Product-wide health check. It only writes `docs/audits/<n>-<YYYY-MM-DD>.md`; every proposed action remains a user decision.

Turn contract — verify before ending the turn

✓ The full PRODUCT AUDIT report was printed in the fixed output format (health by dimension, F-numbered ranked findings, four proposal streams — the roadmap streams always present, `none — <why>` when empty)
✓ The report was WRITTEN to `docs/audits/<n>-<YYYY-MM-DD>.md` (incremental audit id) and committed — the file is the durable deliverable, the chat print is a copy
✓ Nothing else was fixed, filed, or changed — the report file is the ONLY mutation
✓ The closing `→ Next:` block is printed as the ABSOLUTE last output

About to end the turn with any box unchecked? The turn is NOT done — complete the missing box first (weak models drop end-of-document duties; this list is first on purpose).

When to use

• Periodically (every few features) or at a product-ready milestone.
• When you want the broad, honest picture — quality, security, debt, docs, and

roadmap — not the review of a single change (`review-change`) or PR (`audit-pr`).

Unlike diff, PR, or docs-only reviews, this skill covers the whole product.

Scope

The entire codebase and its process artifacts: source, tests, the docs tree, the roadmap, the fix index, open issues, and every feature folder's planning docs. Accept an optional path/area to focus a partial audit; state the scope and, if you sample rather than exhaust a dimension, **say what you sampled** — never imply full coverage you didn't do.

> **Tip (provisional).** The *user* can turn on `ultracode` (a research-preview > Claude Code session setting — no skill can declare it) so this sweep fans out > across parallel subagents instead of one context window; without it, sweep the > dimensions sequentially — only wall-clock changes, never coverage.

Step 0 — Discover the project (always first)

Per the agent guide's **Workflow conventions** + **documentation map**, then read what THIS skill needs: the roadmap, the fix index, the feature folder layout, and the verification gate. From the map decide the product's nature (web / mobile / console / library / backend / infra). Defer deciding which dimensions apply until `AUDIT_DIMENSIONS.md` has been loaded; that resource is the authoritative applicability matrix. Note any optional platform review skills the project installed (extras, never requirements — the internal pack covers every axis).

Progressive loading — audit route

The reference allowlist is exactly the two paths below. Load both after Step 0, in order; they are normative and one hop from this entrypoint.

1. Read [audit dimensions](references/AUDIT_DIMENSIONS.md), mark every dimension applicable or `n-a: <reason>`, and state any sampling. 2. Read [audit process](references/AUDIT_PROCESS.md), execute all ten steps, then return the fixed report below.

A missing resource stops the audit; never reconstruct it from memory. Optional platform review skills remain extras, never replacements for the internal pack.

Output format

This exact structure is BOTH the persisted file (`docs/audits/<id>-<YYYY-MM-DD>.md`) and the chat print — identical content, no free-form variations between runs. Every section below appears in every audit; a section with nothing to report states `none — <why>` instead of being omitted (the roadmap streams especially: "always build the roadmap picture", never silently skip it).

# PRODUCT AUDIT <id> — <product> — <YYYY-MM-DD>
Scope: <whole product | area>
Coverage: <dimensions run | sampled vs. exhaustive>
Verdict: <one-line honest health verdict>

## Health by dimension
  <dimension> .......... ✓ healthy | ⚠ concerns | ✗ at risk | n-a (why)
  ...
  Installed tooling ....... ✓ | ⚠ | ✗ | n-a

## Findings (severity-ranked, one F-sequence for the whole audit)
  F1 [SEV] <dimension> — <finding> — evidence: <file:line | metric | doc> — class: <fix-now|postpone|tradeoff>
  F2 [SEV] ...
  [example — scope-export recurrence] F<k> [med] Workflow discipline — <N>
    consecutive units exported scope via `## Amendments`/descope issues —
    features are being cut too big for real capacity — evidence: <unit list +
    amendments/issues> — class: postpone — route: #64 (atomicity/split rules)

## Delta vs audit <prior-id>
  New: F<k>
  Unchanged: F<k> <- audit <prior-id> F<j>
  Resolved: <prior-id> F<j>
  (none — <why no equivalent-scope prior exists>)

## Proposals — the user decides which to act on

### Issues to open
  - <title> [sev] — from: F<k>[, F<j>] — <why> — route: /triage-issue <id> F<k> — evidence: <…>
  (none — <why>)

### Roadmap — add
  - <feature> — from: F<k> — <rationale & opportunity> — route: plan-feature
  (none — <why>)

### Roadmap — remove / revise
  - <feature> — from: F<k> — <why it no longer fits> — route: triage-issue / roadmap edit
  (none — <why>)

### Tooling — register / re-design
  - <skill|MCP> — register in CLAUDE.md (Optional review extras): <why> — route: user edits CLAUDE.md
  - <skill|MCP> — would change <feature> scope: <why> — route: /design-feature <slug>
  (none — <why>)

## Manual-verification checklist (what automation can't confirm)
  - <item> …

Finding set: F<k> + F<j> + F<m> (print every proposed finding; one finding → F<k>)
→ Next: /triage-issue <id> F<k> F<j> F<m> — classify the complete finding set in one batch (open