Quality-check — QA routing hub

Route first → open the specialist → do the work. This file is the router plus a few load-bearing rules. Deep workflows live in specialists.

When a specialist clearly fits, load it directly — skip re-reading this hub.

Portability

• Hub + browser-verify / web-quality / frontend-design / data-semantic-quality ship in Evan-Kim2028/agent-skills — clone is enough for FE proof paths.
• Optional companions (tdd, diagnose, doubt-driven, ship, …) may come from Matt Pocock / Addy Osmani packs — see companion-install. Grok may already bundle check-work.
• Missing specialist → If specialist missing (do not invent skill files).

How to use this hub

1. Match the task in the routing table (one primary skill).
2. Open that specialist’s SKILL.md now before coding or claiming done.
3. If the skill is missing, use If specialist missing fallbacks below.
4. For multi-step work, follow the matching pipeline (A–C).
5. Stop only when Done criteria pass.

Load at most 1–3 specialists. Do not spray-load the whole table.

Routing table

One default name per row. Aliases only if that name is not installed.

Pipelines

A — Consumer UI (search, filters, trade, chat, sticky)

1. tdd — race-aware tests if URL/debounce/local sync
   → if debounce/URL: read references/interaction-races.md
2. Implement
3. doubt-driven-development if any sync invariant
4. browser-verify (type/click ~2s; no input flicker)
5. web-quality if forms/focus/touch
6. check-work before “done”

Do not claim done after unit green alone on consumer typing/sticky surfaces.

B — Production bug / regression

1. diagnose — reproduce, minimize
2. tdd — test that fails on old behavior
3. Fix root cause
4. Browser/visual proof if user-visible
5. Tag defect class: state-sync | mobile-chrome | search-language | deploy-trust | label-data

C — Ship feature

1. tdd while building
2. frontend-design if UI
3. check-work → review → shipping-and-launch if production
4. If the change claims a live data/product number moved: principle 8 (metric-gated closeout)

E — Residual / metric-gated closeout

1. Name the live metric before the change (query prod, not a doc)
2. Ship the code/data change
3. Re-measure the same metric from the same path
4. If it did not move: the ticket is not closed — residual, not a new feature
5. Estimate/coverage metrics → data-product-eval; identity rates → data-identity-resolution

D — Human QA session (file only)

1. qa — clarify and file issues
2. triage / to-issues if already planned

bug → diagnose → tdd → fix → [doubt] → browser proof → check-work
feature → tdd → [frontend-design] → check-work → review → ship

Shared principles (hub-level only)

1. Prove where the user lives

Vitest green ≠ consumer green. Search/filter/sticky/share: open a real browser before “done.”

Test: Would a user typing for two seconds notice flicker, rewind, or empty flash?

2. Interaction races

Local input + debounce + URL (or other external) sync → must read references/interaction-races.md before implementing or reviewing. Do not invent dual useEffect sync without that matrix. Row “settle, then extend” is the usual miss.

3. One shared primitive

If two features debounce the same URL param pattern, share one hook + one suite.

4. Adversarial review ≠ delete safety

If review says “remove this ref,” require: replacement invariant + which race-matrix row proves it.

5. Red before green on regressions

User-facing fix ships a test that failed on the old code (journey-shaped when racey).

6. Defect classes

Tag escaped bugs; add one automated check that would have blocked the class.

7. Minimum proof by risk

8. Merge is not the metric

CI green and a merged PR are not evidence a live number moved. Before claiming done on a data-product or residual ticket: write the metric, the query/path, the before value, and the after value. If after ≈ before, you shipped a residual.

Test: can you show the same production query before and after? If you only have a merge commit, you did not close it.

If specialist missing

Do not invent a fake skill name. Run the fallback, then note the gap.

Hard anti-patterns

• Consumer UI ship with only unit tests
• “Race-proof” after removing lastSynced without race-matrix row 3
• Fix prod bug with no regression test
• Using qa (file issues) when user asked to fix
• check-work alone as proof of no visual flicker
• Loading >3 specialists for one task
• Snapshot/assert weaken to silence failures
• Closing a data ticket because CI passed while the live metric is unchanged

When not to use this hub

Build vs prove (with frontend-design)

Attribution / install: references/companion-install.md, references/sources.md.

Done criteria

• Routed to default specialist(s) and opened their SKILL.md (or used fallback)
• User-visible failure has an automated oracle
• Debounce/URL sync: race matrix applied (L3 read)
• Browser/visual proof when typing/layout/gesture risk is non-trivial
• Regression: defect class tagged
• Repo lint/typecheck/tests green as required
• Merge-bound: check-work or review done
• If a live metric was the success criterion: before/after captured from the same path