Common App Quality

Common Application Features & Quality Standards

A stack-agnostic quality gate. Its job: make sure the commonly expected — and commonly forgotten — parts of an application feature actually get built, without the user having to ask for them every time.

The skill has three components:

Supporting files: reference/stack-detection.md (how to read a codebase before writing), reference/audit-playbook.md (finding gaps in existing code).

Non-negotiable prime rule

This skill defines what must exist, never what technology to use.

The project's existing stack, architecture, folder layout, naming, component library, state management, validation library, and UI conventions always win. If the project uses Yup, do not introduce Zod. If it uses its own <DataTable>, do not install a table library. If a checklist item is already solved by an existing shared component or helper, reuse it — never re-implement.

The examples in this skill are illustrative patterns, not a prescribed stack.

When the gate applies

Apply it when the task touches any of:

• a form, an input, or a field-level change
• create / read / update / delete of a domain entity
• a grid, table, list, or any rendering of a collection
• a modal, drawer, wizard, or multi-step flow
• an API endpoint, handler, or server action that accepts user input
• a screen that fetches data
• an explicit request to audit or "finish" a feature

Skip it (and say so in one line) for: pure refactors with no behavioural change, build/tooling/config work, docs, internal scripts, one-off migrations, and non-user-facing library code.

Scope rule: the gate covers what the user asked for and what that change directly touches. It is not a licence to rewrite adjacent screens. Gaps found outside the current scope get reported, not silently fixed.

The workflow

Run these five steps for every in-scope task.

1. Detect the stack and conventions — before writing any code

Read reference/stack-detection.md and do it. Never assume a framework, never assume REST, never assume a component library. Find an existing screen that already does the thing well and mirror it.

Also load, if present, the project's own overrides:

• .claude/app-quality-standards.md (project-level tuning of this skill)
• CLAUDE.md, CONTRIBUTING.md, style guides, design-system docs

Project overrides beat this skill wherever they conflict.

2. Select the applicable checklist sections

Open reference/checklist.md and pick only the sections in scope. Don't run grid checks on a settings toggle.

3. Implement using the Implementation Rules

reference/implementation-rules.md explains how each requirement is satisfied in a stack-neutral way. Consult reference/examples/ for the shape of a correct implementation, then translate it into the project's actual idiom.

4. Self-audit against the checklist before declaring completion

A feature is not complete until it has passed the gate. Re-read the selected sections against the code you actually wrote — not what you intended to write.

5. Report the gate result

End the task with a short gate summary (format in "Reporting" below). Never finish an in-scope feature silently.

Severity: what to do without asking

Every checklist item carries a tier. This is what stops the skill from either nagging or under-delivering.

Rules for applying tiers:

• Never silently skip a P0 or P1. If one genuinely cannot be done (no backend access, missing design, blocked by an unavailable API), implement everything else and state explicitly what was left out and why.
• Never expand a small request into a rewrite in the name of P2 items.
• If a P1 conflicts with an explicit user instruction, the user wins — note the trade-off once and move on.

The condensed gate

The full list lives in reference/checklist.md. This is the memory aid:

Forms — every field validated by type and business meaning (P0) · required fields enforced (P0) · max/min length on every free-text field (P0) · the same rules on the API (P0) · inline errors next to fields (P1) · validate on blur and on submit, not on first keystroke (P1) · double-submit guarded (P0) · trim and normalise before save (P1) · cancel/reset behaviour (P1) · unsaved-changes guard (P2) · first field focused (P2).

CRUD — all four operations reachable from the UI (P0) · edit action visible per row using a pencil icon (P1) · delete action with an icon and a confirmation naming the record (P0) · actions consistently positioned across screens (P1) · create and edit share one form (P1) · list refreshes after mutation (P0) · permissions respected — hide or disable what the user may not do (P0).

Grids — sortable on the columns users actually sort by (P1) · search/filter on the identifying columns (P1) · pagination or virtualisation beyond ~50 rows (P1) · loading, empty, error, and no-results-for-filter states all distinct (P0/P1) · sane column count on small screens (P1) · total row count shown (P2) · filters reflected in the URL where the project already does this (P2).

Feedback — success confirmation for every mutation (P1) · actionable error message on failure (P0) · in-flight indicator on every async action (P1) · destructive actions confirmed (P0) · optimistic updates rolled back on failure (P0).

Errors — every API call has a failure path (P0) · no raw stack traces or backend exception text shown to users (P0) · validation errors from the API mapped back onto fields (P1) · network/timeout handled distinctly from 4xx/5xx (P1) · retry offered where sensible (P2).

Integrity — duplicate prevention enforced server-side, not just in the UI (P0) · authorisation checked on every endpoint (P0) · referential integrity and cascade behaviour decided on delete (P0) · idempotent or guarded create (P1).

A11y — every input has a real label (P0) · keyboard reachable and operable (P0) · focus visible (P0) · errors announced and linked via aria-describedby (P1) · icon-only buttons have accessible names (P0) · contrast meets 4.5:1 (P1) · modal traps and restores focus (P1).

Responsive — no horizontal scroll at 360px (P1) · touch targets ≥ 44px (P1) · tables degrade sensibly on mobile (P1) · modals usable on small screens (P1).

Reporting

After an in-scope task, close with a compact summary. Keep it short — this is a receipt, not a report.

Quality gate — Customer master screen
Applied:  A (form validation), B (CRUD), C (grid), D (states), E (feedback)
Added:    email + phone format rules on UI and API; 120-char cap on name;
          pencil/trash row actions; delete confirm naming the record;
          sort on name/created; search box; empty + error states; save toast
Skipped:  K (scale) — list is capped at 200 rows server-side
Proposed: unsaved-changes guard on navigate away (P2) — want it?

When auditing rather than building, report findings grouped by severity with file/line references, and ask before applying anything beyond P0.

Anti-patterns

• Adding a validation library, table library, or toast library the project does not already use, without asking.
• Producing a 40-line checklist dump for a two-field form.
• Claiming an item is done when the code doesn't do it. Verify by reading the code you wrote.
• Client-only validation. It is a UX affordance; the API is the boundary.
• confirm("Are you sure?") in a project that has a dialog component.
• A text link saying "Edit" where the project's icon set already has a pencil.
• Rewriting unrelated screens because they failed the gate. Report instead.