Repair accessibility, highest-impact first
Confirm barriers against an agreed standard, fix the one with the greatest user impact, and rerun the same checks.
Use this when
Use this when a website or app has a defined accessibility target and you can repeatedly test the relevant pages, components, or tasks for people using keyboards, screen readers, zoom, or other access methods.
How it runs
- Choose the pages, components, and user tasks to test; name the accessibility standard, such as WCAG 2.2 AA; and list the automated scans and manual checks that are actually available.
- Run the baseline, reproduce each finding instead of trusting a tool warning by itself, and rank confirmed barriers by the number of people affected and how severely they are blocked.
- Fix the most harmful barrier with the smallest underlying change, then repeat the same scan, manual check, user task, and relevant regression tests.
- Keep only verified fixes and repeat until no confirmed barrier remains or progress stalls, evidence cannot be collected, work is blocked, or approval is required.
Done when
✓ No confirmed accessibility barrier remains in the agreed pages, components, or user tasks. The same automated scans, available manual checks, affected user task, and regression tests pass after each retained fix without lowering the chosen accessibility standard.
Why it works
A fixed scope and repeated checks keep accessibility work tied to real people and reproducible evidence instead of an endless score chase. Fixing the most harmful confirmed barrier first directs effort to the users who are blocked most severely.
Implementation note
Automated tools can find likely problems but cannot prove a product is accessible. Manual keyboard use, screen-reader checks, zoom, contrast review, and real user testing may still be needed. Record anything the available test setup could not cover.
Source: Forward Future ↗graded B · 85/100 — how grades work →
More quality loops
Clean up the slop
Review your recent diff for debug code, dead branches, and bad names, then fix with minimal edits until lint and tests pass.
Fifteen-minute verification report while you work
A recurring six-phase check (build, types, lint, tests with coverage, secret and debug-log grep, diff size) that prints one fixed-format report every fifteen minutes so you catch drift before the PR, not in review. It is strictly read-only: the loop reports, you decide what to fix. It exits when the tests pass and the report reads READY twice running, escalates instead of retrying when the same check fails three times, and stops after eight checks no matter what. Adapted from ECC's verification-loop skill (affaan-m/ECC, MIT), whose 'continuous mode' names the cadence but has no turn cap, exit, or failure path; all three are added here.
Karpathy-Style CLAUDE.md Self-Check Protocol for Loops
A self-check protocol embedded in CLAUDE.md that every loop iteration obeys before ending a turn: re-read the goal, diff the changes against it, run the verification command, and state what remains — a ritual that catches drift between iterations.