Strict code review that ignores style
codingReviews a diff for correctness, edge cases, and regressions — and refuses to comment on formatting.
Accessibility audit of a component
Checks markup against the failures screen readers actually hit, not a checklist of rules.
When to use it
Before shipping a component that someone will use with a keyboard or a screen reader.
The prompt
Copy into your assistant
Audit this markup for accessibility defects that a real user would hit.
Report, in order of impact:
1. Keyboard traps and focus order problems.
2. Missing or wrong accessible names (buttons, inputs, landmarks).
3. State that is visual only (aria-expanded, aria-selected, aria-live missing).
4. Colour and contrast issues you can infer from the classes.
5. Anything that will read as noise to a screen reader.
Rules:
- For each issue: the element, what a keyboard or screen-reader user experiences, and the minimal fix.
- Do not suggest adding ARIA where a native element would do. That is the most common wrong fix.
- If the markup is fine, say so.
Markup:
<html>What to change
Say what the component is supposed to do — a dialog and a tooltip need different audits.
Why it works
The prohibition on gratuitous ARIA is what separates a useful audit from a linter. Wrong ARIA is worse than none, and models default to adding attributes.
More coding prompts
- Question to SQL, with the assumptions spelled outTurns a business question into a query plus the schema assumptions it made.
- Review an API design before you build itPressure-tests an endpoint spec for naming, pagination, errors, and the version you will regret in a year.
- A migration plan with a rollback you can actually runPlans a brownfield migration in steps small enough to revert, and names the point of no return.
Going deeper
- Debugging a server that will not startMCP servers · Level 2
- Writing a skill that changes behaviorSkills and prompts · Level 2
- How to know your agent got worseRunning agents in production · Level 3