# Common App Quality > Common Application Features & Quality Standards - Skill: `sjplayground/common-app-quality` (Agent Skill, multi-file: 11 files) - Install (CLI): `npx skillmds@latest add sjplayground/common-app-quality` - Raw SKILL.md: https://api.skillmd.com/api/skills/sjplayground/common-app-quality/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: sjplayground (https://skillmd.com/u/sjplayground) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/sjplayground/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: | Component | File | Purpose | |---|---|---| | **Checklist** | `reference/checklist.md` | The quality gate. What must exist. | | **Implementation Rules** | `reference/implementation-rules.md` | How to build it inside *this* project's stack and conventions. | | **Examples** | `reference/examples/*.md` | Reference patterns so the standard is applied, not re-interpreted. | 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 ``, 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. | Section | Applies to | |---|---| | A. Forms & field validation | any form or input | | B. CRUD completeness | any entity screen | | C. Data grids / tables / lists | any collection view | | D. States (loading / empty / error / partial) | anything async | | E. User feedback & notifications | any mutation | | F. Error handling (client + API) | anything that can fail | | G. Accessibility basics | any UI | | H. Responsiveness | any UI | | I. Consistency & affordances | any UI | | J. Data integrity & safety | any mutation or API | | K. Performance & scale | any collection or heavy screen | ### 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. | Tier | Meaning | Action | |---|---|---| | **P0 — Blocker** | Feature is broken, unsafe, or loses data without it. | Implement. Never ask, never defer. | | **P1 — Expected** | A user or reviewer would consider it missing. | Implement by default, as part of the task. Mention it in the summary. | | **P2 — Recommended** | Valuable but scope-dependent or a product decision. | Propose in one line. Implement if trivial and clearly right, or if the user says yes. | 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. ```text 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.