agentsclimarketplace

User action coverage review

Skill jimtin/production-ai/skills/user-action-coverage-review

Skills and guardrails that make AI coding agents prove their work: planning gates, test preflights, fail-closed deployment, and a self-improving skill library.

Install
npx -y skills add jimtin/production-ai --skill user-action-coverage-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Impact-scoped review that maps user actions, critical paths, roles, states, and mutations to Playwright/E2E plus unit/integration evidence. Use after an accepted plan and before implementation for substantial feature, frontend, workflow, route, mutation, auth/role, upload, save/delete, navigation, admin/user portal, or release-readiness work; rerun before final validation if scope changes.

SKILL.md

4.3 KB, as published. Nobody here has run it

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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.