User Action Coverage Review

Purpose

Use this skill to prevent missing browser, integration, and unit coverage from being discovered only at the full gate. This is an impact-scoped coverage review, not a full app audit. Use $full-app-review for whole-app or production-readiness audits.

When To Use

Use after plan acceptance and before implementation for substantial user-facing or workflow work, including:

• new or changed routes, forms, navigation, mutations, saves, deletes, uploads, imports, exports, toggles, filters, role-gated actions, admin/user portal workflows, and deployed-flow behavior
• frontend changes covered by $frontend-design-quality
• release-readiness work where user workflows or critical paths are in scope

The $clarify-before-build exit hands off here: a confirmed Shared Understanding Contract for substantial user-facing work names this skill as the first post-confirmation step, and the action matrix becomes the contract's acceptance-criteria evidence.

Rerun before final validation if implementation scope changes, if a user action is added or removed, or if tests are rewritten.

Workflow

1. Load repo truth.
   • Read applicable AGENTS.md, route/workflow manifests, critical-path inventories, Playwright specs, integration tests, unit tests, and relevant package scripts.
   • Prefer existing repo inventory files over inventing a parallel source of truth — $repo-testing-setup commits these at foundation time.
2. Build the action matrix before implementation.
   • Include every affected click, form submit, save, autosave, upload/import/export, delete/archive, navigation, keyboard path, role-gated mutation, empty/error/retry state, and removed action.
   • Include public, authenticated, admin, and superadmin roles when the surface supports them.
3. Map evidence.
   • Browser/E2E evidence must prove the user can actually perform or cannot perform the action.
   • Integration evidence must cover API routes, persistence boundaries, provider adapters, permissions, workflows, queues/jobs, and cross-module contracts.
   • Unit evidence must cover changed hooks, services, helpers, validation, rendering utilities, state machines, and branch behavior.
4. Convert gaps into implementation tasks.
   • missing, stale, partial, and negative assertion needed rows are not observations to defer silently; they become work items before final validation.
   • Removed actions need negative browser assertions where the old UI/action would otherwise be reachable.
   • Update flow inventories and critical-workflow manifests in the same change when the repo has them.
5. Reconcile before the full gate.
   • Rerun the matrix after implementation if scope changed.
   • Do not start the canonical full gate until each in-scope row is covered, blocked, or explicitly deferred by the user.

Required Matrix

Use this shape in planning notes, implementation handoff, or final report:

| User action | Route/surface | Role/persona | Data state | Expected behavior | Playwright/E2E evidence | Unit/integration evidence | Status |
|---|---|---|---|---|---|---|---|
| Save profile | /settings/profile | signed-in user | valid form | persists and shows success | WEB-123 | profile-route.test.ts, useProfileSave.test.ts | covered |

Allowed status values:

• covered
• missing
• stale
• partial
• negative assertion needed
• blocked
• deferred by user

Acceptance Bar

Do not call the review complete until:

• every in-scope user action is listed
• every critical path maps to browser/E2E plus integration evidence
• changed logic has unit or focused integration coverage identified
• removed actions have absence coverage or a documented reason
• stale tests, stale manifests, and stale flow inventories are listed as implementation tasks
• blockers name the exact missing dependency, fixture, auth, environment, or product decision