test-copilotlisted

Test a feature WITH Simon rather than for him. Claude exhausts every machine-checkable thing first (build, types, tests, seeded states, its own browser pass), instruments the code with reason-coded logs and a correlation id BEFORE starting, then boots and identity-verifies its own dev server and paces Simon through the real user journey ONE step at a time while watching the logs live — so his eyes catch the UX gaps automated tests structurally cannot see, and Claude diagnoses each from the logs and fixes it. Use for "co-pilot test this", "let's test this together", "walk me through testing X", "my tests pass but the app is broken", or before shipping anything a human will click through.
skowalskidev/dotclaude · ★ 2 · Testing & QA · score 78

Install: claude install-skill skowalskidev/dotclaude

# Co-pilot testing **Why this exists:** the suite goes green and the app is still broken. Not subtly — a button that isn't there, a screen you can reach but can't act from, a required field with no input, an order that makes no sense. Assertions only check what someone thought to assert, so they cannot notice a step is *missing*: nothing missing has a test. Unit tests never render; integration tests run headless; e2e scripts a known-good happy path by construction. The defect classes that survive all three are exactly the ones Nielsen's heuristics name — visibility of status, error prevention, recognition over recall, error recovery. So Claude does everything a machine can, then gets out of the way and drives Simon through the real journey while watching the logs. Simon supplies judgement. Claude supplies instrumentation, correlation, and the fix. **Don't duplicate the neighbours:** - `/sk:test-eyeball` — Claude drives the browser itself. No human needed. - `/sk:ship-review` Step 6 — Claude *reasons* over a flow and reports gaps. No live session. - **This skill** — Simon drives the UI, Claude watches the server. Human judgement is the point. Read, don't restate: `~/.claude/references/user-journey-review.md` (what to look for at each step while he drives: dead ends, the three states, the wait, when a lock needs a reason), `~/.claude/references/testing-strategy.md` (gates, seeding, reason-coded logging, failure classes automation can't catch), `~/.claude/references/dev-serv