a11y-loop 0.1.0

package/skill/a11y-loop/SKILL.md

@@ -0,0 +1,332 @@
+---
+name: a11y-loop
+description: >-
+  Make accessible markup the default when writing UI, then verify it in a real
+  browser instead of assuming. Use whenever generating or modifying user
+  interface code (HTML, JSX/TSX, Vue, Svelte, Astro, CSS) — forms, modals,
+  menus, tabs, tables, navigation, pricing pages, dark mode, colors — and
+  whenever the user asks for an accessibility audit, an a11y check or fix, a
+  WCAG review, a contrast fix, or help with screen readers, keyboard
+  navigation, focus order, ARIA, alt text. Supplies standing generation rules
+  (semantic HTML first, ARIA discipline, APG keyboard contracts, labels, focus
+  visibility, AA contrast in light and dark, reduced motion, 24x24 targets), a
+  mandatory audit-fix-re-audit loop driven by the `a11y-loop` CLI (axe-core in
+  Chromium across default, dark, forced-colors, reduced-motion and 320px
+  passes), and honest reporting of what automation cannot judge. Keywords:
+  accessibility, a11y, WCAG 2.2 AA, ARIA, axe-core, contrast ratio, screen
+  reader. Not for backend-only work with no UI.
+license: MIT
+compatibility: >-
+  Verification needs Node.js >= 20 and Playwright Chromium. Install with
+  `npm i -g a11y-loop && npx playwright install chromium` (set
+  PLAYWRIGHT_BROWSERS_PATH first if you keep browsers off the system drive).
+  The generation and honesty rules apply with or without the CLI; every step
+  that says "audit" requires it.
+metadata:
+  "a11y-loop/version": "0.1.0"
+paths:
+  - "**/*.html"
+  - "**/*.tsx"
+  - "**/*.jsx"
+  - "**/*.vue"
+  - "**/*.svelte"
+  - "**/*.astro"
+  - "**/*.css"
+allowed-tools: 'Bash(a11y-loop *) Bash(npx a11y-loop *) Bash(node ${CLAUDE_SKILL_DIR}/../../src/cli.js *)'
+---
+
+# a11y-loop
+
+These are standing instructions. **For the remainder of this session, whenever
+you write or modify UI code, apply §1 as you write it, run §2 before you call
+the work done, and speak about the result only in the terms allowed by §3.**
+They stay in force across turns — you do not need to be reminded.
+
+Prompting alone does not work. UIs generated from accessibility-oriented
+prompts measure *slightly worse* than accessibility-agnostic ones (W4A'25,
+17.32% vs 15.93% violation rate). §1 is the setup; §2 is the product. Skipping
+the loop reverts you to the baseline where 84% of AI-generated pages carry
+accessibility failures.
+
+## Resolving the CLI
+
+Resolve once per session, first form that answers `--version` wins. Call the
+result `A11Y` below.
+
+1. `a11y-loop --version` — installed globally or as a project dependency.
+2. `npx a11y-loop --version` — no install needed.
+3. `node ${CLAUDE_SKILL_DIR}/../../src/cli.js --version` — this skill sitting
+   inside a checkout of the a11y-loop repo.
+
+```
+A11Y audit <url>                     # dev server — primary loop path
+A11Y audit --file path/to/page.html  # served over 127.0.0.1 (never file://)
+A11Y audit --html "<fragment>"       # wrap + serve generated markup
+    --json --out report.json --sarif out.sarif --interact states.mjs
+    --headed --no-best-practice --quiet
+A11Y contrast <fg> <bg> [--large] [--ui] [--fix] [--json]
+A11Y diff --before before.json --after after.json
+```
+
+Exit codes: `0` no violations · `1` violations found · `2` tool error.
+
+Every audit runs five passes automatically: default 1280x720, dark mode,
+forced-colors, reduced-motion, and 320x256 (the WCAG-sanctioned equivalent of
+400% zoom for SC 1.4.10). Dark-mode contrast failures are common and invisible
+to a single default-mode scan, so never hand-roll a single-pass axe call
+instead.
+
+JSON report shape: `findings.violations`, `findings.needsReview`,
+`findings.bestPractice`, `manualChecklist`, `summary`; each finding carries a
+stable `fingerprint`, a `wcag` block (`sc`, `name`, `level`, `minVersion`,
+`wcag22Only`), `act[]` rule IDs, and — for contrast — concrete
+`suggestions[]` with hex values and before/after ratios.
+
+---
+
+## §1 Generation rules
+
+Apply while writing, not afterwards.
+
+**Semantic HTML first.** `<button>`, `<a href>`, `<input>`, `<select>`,
+`<dialog>`, `<table>`, `<nav>`, `<main>`, `<h1>`–`<h6>`. Native elements bring
+focus, keyboard behavior, and state announcement for free; a `div` brings none
+of it. The four rules of ARIA use ([Using ARIA](https://www.w3.org/TR/using-aria/),
+now a discontinued draft but still the canonical statement):
+
+1. "If you can use a native HTML element or attribute with the semantics and
+   behavior you require already built in, instead of re-purposing an element
+   and adding an ARIA role, state or property to make it accessible, then do
+   so."
+2. "Do not change native semantics, unless you really have to."
+3. "All interactive ARIA controls must be usable with the keyboard."
+4. "Do not use `role="presentation"` or `aria-hidden="true"` on a focusable
+   element."
+
+**No ARIA is better than bad ARIA.** Wrong ARIA actively misrepresents the
+interface to screen reader users — worse than none. Empirically, pages *with*
+ARIA average more failures than pages without (WebAIM Million 2026: 59.1 vs
+42.0). Add ARIA only when you can name the native gap it fills.
+
+**A role is a promise.** `role="button"` commits you to Enter and Space
+activation, focusability, and a disabled state. `role="tab"` commits you to the
+whole arrow-key contract. ARIA creates zero behavior; an unfulfilled promise is
+a false accessibility interface. If you cannot implement the contract, use the
+native element or ship the plain version.
+
+**Every APG-pattern component follows its APG keyboard contract.** Dialog,
+tabs, accordion, menu button, combobox, disclosure, radio group, switch,
+tooltip, listbox — contracts in
+[references/apg-patterns.md](references/apg-patterns.md). For any widget not in
+that file, read its APG page before implementing it.
+
+**Names and labels.**
+- Every input has a programmatic label: `<label for>`, wrapping `<label>`, or
+  `aria-label`. A placeholder is not a label.
+- Every link and button has a non-empty accessible name. Icon-only controls get
+  `aria-label` (or visually-hidden text); the icon `<svg>` gets
+  `aria-hidden="true"`. Empty links (46.3% of pages) and empty buttons (30.6%)
+  are overwhelmingly icon-only controls.
+- Visible label text must be contained in the accessible name (SC 2.5.3), so
+  voice-control users can say what they see.
+- Group related fields in `<fieldset>` with `<legend>`.
+
+**Structure.** `<html lang="…">` on every document. One `<h1>`; heading levels
+descend without skipping — pick the level from the outline, style with CSS.
+Landmarks: `<header>`, `<nav>`, `<main>` (exactly one), `<footer>`. A skip link
+to `<main>` on full pages.
+
+**Focus.** Always ship a visible `:focus-visible` indicator with at least 3:1
+contrast against what surrounds it. Never `outline: none` without a
+replacement. Never a positive `tabindex`. `tabindex="-1"` only for
+programmatic focus targets. After a route change or view swap in an SPA, move
+focus deliberately (to the new `<h1>` or a `tabindex="-1"` container) and
+announce it — focus otherwise stays on a destroyed node.
+
+**Color.** Every text/background pair must meet WCAG AA in **both** light and
+dark mode: 4.5:1 normal text, 3:1 large text (>=24px, or >=18.5px bold), 3:1
+for UI component boundaries and meaningful graphics. Low-contrast text is the
+single most common failure in the wild (83.9% of pages). When choosing or
+adjusting a color, run `A11Y contrast <fg> <bg> --fix` and take a returned
+candidate rather than guessing. Never encode meaning in color alone — pair it
+with text, shape, or an icon.
+
+**Motion and pointers.** Wrap non-essential animation in
+`@media (prefers-reduced-motion: reduce)` and actually reduce it there. Pointer
+targets are at least 24x24 CSS px, or adequately spaced (SC 2.5.8). Anything
+draggable needs a single-pointer alternative — a click, a button, a field (SC
+2.5.7). No content that appears on hover unless it is dismissible, hoverable,
+and persistent (SC 1.4.13).
+
+**Dynamic content.** Async results, validation errors, toasts, and filter
+counts must be announced: `role="status"` / `aria-live="polite"` (or
+`role="alert"` for errors), with the live region present in the DOM *before*
+the text arrives. Associate field errors via `aria-describedby` and set
+`aria-invalid`. Reflect widget state in `aria-expanded`, `aria-checked`,
+`aria-selected`, `aria-current` — and update it in the same handler that
+changes the visuals.
+
+**Before you save a UI file, re-read it against
+[references/ai-failure-modes.md](references/ai-failure-modes.md)** — the
+blacklist of failures generated code reproduces most: clickable `div`,
+icon-button with no name, placeholder-as-label, skipped headings,
+`outline: none`, `aria-labelledby` pointing at an id that does not exist,
+`aria-hidden` on a focusable element, role without behavior, missing `lang`,
+ignored reduced motion, SPA focus loss, unannounced updates, positive
+`tabindex`, invented alt text.
+
+---
+
+## §2 The loop
+
+**After any UI change, before reporting the work as done:**
+
+1. **Make it renderable.** Start or reuse the dev server, run the build, or
+   write the fragment to a file. Pick the input mode: `<url>` for a running app
+   (preferred — it audits what actually ships), `--file` for a static page,
+   `--html` for a component fragment you just generated.
+2. **Audit, including the states you just built.** A load-time scan finds
+   nothing inside a closed modal. Write a small interact module naming each
+   state your change introduced and pass it with `--interact`; each state is
+   driven and then audited:
+
+   ```js
+   // .a11y/states.mjs
+   export const states = {
+     'settings-dialog-open': async (page) => {
+       await page.getByRole('button', { name: 'Settings' }).click();
+     },
+     'signup-form-error': async (page) => {
+       await page.getByRole('button', { name: 'Create account' }).click();
+     },
+     'results-loaded': async (page) => {
+       await page.getByLabel('Search').fill('wcag');
+       await page.getByRole('button', { name: 'Search' }).click();
+       await page.getByRole('list', { name: 'Results' }).waitFor();
+     },
+   };
+   ```
+
+   Opened a modal? Added an error state? Added a route, a tab panel, an
+   expanded menu, an async list? Each one is a state. Audit it.
+
+   ```
+   A11Y audit http://localhost:5173 --interact .a11y/states.mjs --json --out .a11y/run-1.json
+   ```
+
+3. **Read `findings.violations` and `findings.needsReview`.** Both. A
+   needsReview item is a place the engine knows it could not decide — usually
+   contrast over a gradient, image, or translucent layer. Resolve it by
+   reasoning about the source, not by ignoring it.
+4. **Fix in the source files**, never in the report or by suppressing a rule.
+   For contrast findings, use the report's `suggestions[]` or
+   `A11Y contrast <fg> <bg> --fix`, which returns both a lighter and a darker
+   passing candidate with hue preserved; pick the one closest to the design
+   intent and apply it to the design token, not to one element.
+5. **Re-audit to a new file, then diff.**
+
+   ```
+   A11Y audit http://localhost:5173 --interact .a11y/states.mjs --json --out .a11y/run-2.json
+   A11Y diff --before .a11y/run-1.json --after .a11y/run-2.json
+   ```
+
+   `diff` matches by fingerprint and reports FIXED / NEW / REMAINING. NEW means
+   your fix broke something else. If the same finding alternates between FIXED
+   and NEW across iterations you are oscillating — stop, read both findings
+   together, and change the approach instead of the value.
+6. **Repeat from 2 until `violations` is empty and `diff` reports no NEW.**
+   Then read the `manualChecklist` and carry it into your report (§3).
+
+**Never declare UI work finished without a clean audit of the states you
+built.** If the CLI cannot run — no Chromium, no dev server, a sandbox with no
+browser — say so plainly, state that the change is unverified, and give the
+exact command the user should run. Do not substitute your own reading of the
+code for the audit.
+
+For a fragment with no app around it, pass the markup inline with `--html`, or
+write it to a scratch file and use `--file` (safer on any shell, and required
+when the fragment contains quotes):
+
+```
+A11Y audit --html "<button class='icon'><svg/></button>" --json --out .a11y/frag.json
+A11Y audit --file .a11y/scratch/price-card.html --json --out .a11y/card.json
+```
+
+`--headed` when you need to watch a state fail. `--no-best-practice` when
+best-practice noise is drowning the real violations; the WCAG-mapped findings
+are unaffected.
+
+---
+
+## §3 Honesty rules
+
+The claims below are the ones that produced a $1,000,000 FTC penalty against an
+accessibility overlay vendor in 2025 and that 800+ signatories of the
+[Overlay Fact Sheet](https://overlayfactsheet.com/) exist to refute. They are
+also simply not what an automated pass shows.
+
+**Never say, about anything this loop produced:** "accessible", "fully
+accessible", "WCAG compliant", "meets WCAG 2.2 AA", "passes WCAG",
+"guarantees", "ensures", "certified", "100% accessible", "makes your app
+accessible", "no manual testing needed", "reduces legal risk", "ADA
+compliant". Never present a score or grade as a verdict.
+
+**Say instead:** "`a11y-loop audit` found no automatically detectable failures
+in the states I drove (default, dark, forced-colors, reduced-motion, 320px
+reflow; states: settings-dialog-open, signup-form-error). Here is what still
+needs human review."
+
+**Always report the coverage limit with its denominator.** Automated testing
+reaches a minority of WCAG failures, and the honest figures disagree because
+they measure different things: Deque puts automation at **57% of issues by
+volume of individual instances** across 13,000+ pages; Adrian Roselli counts
+**17 of the 55** WCAG 2.2 A/AA criteria as having any ACT-approved automated
+rule (31%), and not fully covered even there; accessible.org counts **7 of 55**
+as reliably flagged (13%). Nine A/AA criteria cannot be meaningfully tested by
+any tool. Cite one figure with its denominator, not a bare percentage.
+
+**Always surface the `manualChecklist`.** It is a deliverable, not a
+disclaimer — it names the criteria automation could not judge for the
+components you actually built. Include it in your summary to the user, not just
+in the JSON.
+
+**`needsReview` findings are unresolved uncertainty, never passes.** Report
+them as open questions with what you did about each.
+
+**Mark every alt text and accessible name you wrote as DRAFT needing human
+confirmation.** You cannot see the image, and hallucinated image descriptions
+are a documented failure mode of generated code. `alt="decorative image"`
+passes every automated check and is worse than `alt=""`. Write the draft, label
+it, and ask for confirmation:
+
+> `alt="Two people reviewing a document at a desk"` — **DRAFT**, written from
+> filename and surrounding copy; please confirm it describes the actual image,
+> or set `alt=""` if it is decorative.
+
+**Recommend real assistive-technology testing before production**, and say
+which is cheapest to start with: NVDA (free, Windows), VoiceOver (built into
+macOS/iOS). Automated checks and your own reading cannot tell you whether the
+interface is usable — only people using it can, and testing with disabled
+users is what actually closes that gap. See
+[references/manual-testing.md](references/manual-testing.md) for the full
+not-automatable list and a keyboard script a non-expert can run in five
+minutes.
+
+**Attribute the engine.** Findings come from axe-core (MPL-2.0, Deque Systems)
+and the WCAG success criteria are W3C's. Cite findings as
+`SC 4.1.2 Name, Role, Value (Level A) · ACT 97a4e1 · axe: button-name` — the
+success criterion is the obligation; ACT rule IDs are informative secondary
+identifiers, not the source of the requirement.
+
+---
+
+## References
+
+Read on demand; none of it costs context until you open it.
+
+| File | Use it when |
+|---|---|
+| [references/wcag22-quick-ref.md](references/wcag22-quick-ref.md) | You need the exact SC number, level, contrast threshold, or what is new in WCAG 2.2 |
+| [references/apg-patterns.md](references/apg-patterns.md) | You are building a dialog, tabs, accordion, menu, combobox, disclosure, radio group, switch, tooltip, or listbox |
+| [references/ai-failure-modes.md](references/ai-failure-modes.md) | Before saving generated UI code, and when a finding needs a wrong-vs-right example |
+| [references/manual-testing.md](references/manual-testing.md) | You are writing the §3 hand-off, or a user asks what the audit did not check |

package/skill/a11y-loop/evals/evals.json

@@ -0,0 +1,168 @@
+{
+  "skill_name": "a11y-loop",
+  "schema_note": "skill-creator evals.json schema (skill_name + evals[] with id/prompt/expected_output/expectations). The non-standard `should_trigger` field is additive metadata for description tuning; the machine-readable trigger set the skill-creator run_eval.py script consumes is a bare array in trigger-evals.json alongside this file.",
+  "evals": [
+    {
+      "id": 1,
+      "should_trigger": true,
+      "prompt": "Create a signup page at src/signup.html with fields for full name, email, password and a country dropdown, plus a submit button. Style it with a plain stylesheet, no framework.",
+      "expected_output": "An accessible signup page whose generated markup was audited in a real browser and iterated to zero violations, reported without any conformance claim.",
+      "expectations": [
+        "Every input has an associated <label for> (or a wrapping <label>); no field relies on a placeholder as its label",
+        "Inputs carry appropriate autocomplete tokens such as name, email, current-password or new-password",
+        "The document has <html lang> set and a single <h1>",
+        "A visible :focus-visible indicator is defined in CSS and no rule sets outline: none without a replacement",
+        "An a11y-loop audit command was actually run against the generated page (--file or --url, not file://)",
+        "Any violations reported by the audit were fixed in the source file and the page was re-audited",
+        "The final summary does not claim the page is accessible, compliant, or that it passes WCAG",
+        "The final summary surfaces the manual checklist or otherwise names what still needs human review"
+      ]
+    },
+    {
+      "id": 2,
+      "should_trigger": true,
+      "prompt": "Add a Settings dialog to the React app in src/App.jsx. It should open from a gear icon button in the header and contain two toggles and a Save button.",
+      "expected_output": "A dialog implementing the APG modal-dialog contract, with the opened state driven and audited via --interact, not just the closed page.",
+      "expectations": [
+        "The gear icon button has a non-empty accessible name (aria-label or visually hidden text) and the icon itself is aria-hidden",
+        "The dialog has an accessible name via aria-labelledby or aria-label, focus moves into it on open, Escape closes it, and focus returns to the trigger on close",
+        "Focus is constrained to the dialog while it is open (native <dialog> showModal, inert, or an explicit trap)",
+        "The toggles use role=\"switch\" with aria-checked, or a native checkbox, and the state attribute is updated in the same handler as the visual change",
+        "An --interact module was written that opens the dialog, and the audit was run with it so the open state was audited",
+        "The response does not claim the dialog is accessible or compliant"
+      ]
+    },
+    {
+      "id": 3,
+      "should_trigger": true,
+      "prompt": "Build a three-tier pricing section for our marketing site: Starter, Team, Enterprise. Cards with a feature list each and a Choose plan button. Make it look modern.",
+      "expected_output": "A pricing section with a correct heading outline, named buttons, AA contrast in light and dark mode, and a clean audit including the 320px reflow pass.",
+      "expectations": [
+        "Heading levels descend without skipping (the plan names are not styled-down h4s under an h1) and visual size is set in CSS rather than by heading level",
+        "Each 'Choose plan' button has an accessible name that distinguishes which plan it selects",
+        "Feature lists use real list markup",
+        "Text and background color pairs were checked against WCAG AA, using a11y-loop contrast or the audit's contrast findings rather than being assumed",
+        "An a11y-loop audit was run and the 320x256 reflow pass produced no unresolved horizontal overflow",
+        "The final summary avoids the words compliant, guarantees, and fully accessible"
+      ]
+    },
+    {
+      "id": 4,
+      "should_trigger": true,
+      "prompt": "Our brand color is #7C9EC4 and we use it for body text links on white, and for button labels on a #F3F4F6 grey. Add a dark theme too. Update src/tokens.css.",
+      "expected_output": "Contrast-checked token values for light and dark themes, with concrete failing/passing ratios reported and candidates chosen from the CLI rather than guessed.",
+      "expectations": [
+        "a11y-loop contrast was run for the stated color pairs, including the --fix flag or the report suggestions, rather than the ratios being estimated",
+        "The reported contrast ratio for #7C9EC4 on white is identified as failing the 4.5:1 requirement for normal text",
+        "Replacement colors are applied to the design tokens rather than to individual elements",
+        "The dark theme values were contrast-checked separately, not assumed to inherit from the light theme",
+        "Link styling does not rely on color alone to distinguish links in body text",
+        "The response cites SC 1.4.3 (and 1.4.11 where UI boundaries are involved) with the ratio it measured"
+      ]
+    },
+    {
+      "id": 5,
+      "should_trigger": true,
+      "prompt": "The dashboard needs tabs: Overview, Billing, Members. Add them to src/components/Dashboard.tsx.",
+      "expected_output": "A tabs implementation following the APG contract, with each tab panel state audited.",
+      "expectations": [
+        "The implementation uses role=\"tablist\" / role=\"tab\" / role=\"tabpanel\" with aria-selected, aria-controls and aria-labelledby wired to ids that resolve",
+        "Roving tabindex is implemented: the selected tab has tabindex 0 and the others -1",
+        "Arrow key navigation between tabs plus Home and End are implemented, matching the APG keyboard contract",
+        "The apg-patterns.md reference was consulted or its contract is visibly followed rather than approximated",
+        "An audit was run covering more than the initially selected panel, for example via an --interact module that selects each tab",
+        "No conformance claim appears in the summary"
+      ]
+    },
+    {
+      "id": 6,
+      "should_trigger": true,
+      "prompt": "Run an accessibility audit on http://localhost:3000 and tell me what's wrong.",
+      "expected_output": "An audit run through the CLI with violations and needsReview both reported, coverage stated with a denominator, and the manual checklist surfaced.",
+      "expectations": [
+        "a11y-loop audit was run against the URL, producing JSON output",
+        "Both findings.violations and findings.needsReview are reported, with needsReview presented as unresolved uncertainty rather than as passes",
+        "Findings are cited by WCAG success criterion number, name and level",
+        "The coverage limitation is stated with its denominator (for example 57% of issue instances by volume, or 17 of 55 criteria having any automated rule)",
+        "The manual checklist is included in the response to the user, not only left in the JSON file",
+        "Real assistive technology testing is recommended before production",
+        "The response does not present a score or grade as a verdict"
+      ]
+    },
+    {
+      "id": 7,
+      "should_trigger": true,
+      "prompt": "A reviewer says the icon buttons in src/Toolbar.jsx aren't accessible. Can you check and fix them?",
+      "expected_output": "Accessible names added to icon-only controls, decorative icons hidden, target size checked, and the fix verified by audit rather than asserted.",
+      "expectations": [
+        "Each icon-only button receives an accessible name via aria-label or visually hidden text",
+        "The decorative svg or icon element is marked aria-hidden=\"true\"",
+        "Target size is considered against the 24x24 CSS px minimum of SC 2.5.8",
+        "The change was verified with an a11y-loop audit rather than only by inspection",
+        "Any accessible name inferred from an icon shape rather than existing text is flagged as needing human confirmation",
+        "SC 4.1.2 Name, Role, Value is cited"
+      ]
+    },
+    {
+      "id": 8,
+      "should_trigger": true,
+      "prompt": "Add alt text to all the images in src/pages/about.html.",
+      "expected_output": "Draft alt text clearly labelled as unverified, with decorative images given empty alt, and an explicit request for human confirmation.",
+      "expectations": [
+        "Every alt value the model wrote is explicitly labelled DRAFT or otherwise marked as needing human confirmation",
+        "The response states that the images were not seen and the descriptions are inferred from filename, context or surrounding copy",
+        "Images judged decorative are given alt=\"\" rather than a description or a phrase like 'decorative image'",
+        "The user is asked to confirm or replace each draft",
+        "The response does not claim the images are now accessible"
+      ]
+    },
+    {
+      "id": 9,
+      "should_trigger": true,
+      "prompt": "I fixed the contrast issues you found. Did it work, and did I break anything?",
+      "expected_output": "A re-audit plus a fingerprint diff against the previous report, reported as FIXED / NEW / REMAINING.",
+      "expectations": [
+        "A fresh audit was run to a new report file rather than reusing the earlier one",
+        "a11y-loop diff was run with --before and --after pointing at the two reports",
+        "The answer distinguishes FIXED, NEW and REMAINING findings",
+        "Any NEW findings are treated as regressions introduced by the fix and addressed rather than reported and left",
+        "The loop is only declared finished when violations is empty and diff reports no NEW"
+      ]
+    },
+    {
+      "id": 10,
+      "should_trigger": false,
+      "prompt": "Refactor the argument parsing in bin/deploy.js to use node:util parseArgs instead of the hand-rolled loop, and keep the existing flags working.",
+      "expected_output": "A straightforward CLI refactor with no accessibility work and no audit attempted.",
+      "expectations": [
+        "The refactor is completed using node:util parseArgs with the existing flags preserved",
+        "No a11y-loop command was run",
+        "No accessibility manual checklist, WCAG citation, or contrast discussion appears in the response",
+        "No unrequested ARIA, alt text, or label changes were introduced"
+      ]
+    },
+    {
+      "id": 11,
+      "should_trigger": false,
+      "prompt": "This query times out on the reports table. Can you rewrite it to use a window function instead of the correlated subquery? SELECT id, (SELECT COUNT(*) FROM events e WHERE e.report_id = r.id) AS n FROM reports r;",
+      "expected_output": "A rewritten SQL query with no accessibility content.",
+      "expectations": [
+        "A window-function rewrite of the query is provided",
+        "No a11y-loop command was run",
+        "No WCAG success criteria, contrast ratios, or accessibility checklist appear in the response"
+      ]
+    },
+    {
+      "id": 12,
+      "should_trigger": false,
+      "prompt": "There's a typo in README.md — 'recieve' should be 'receive'. Fix it.",
+      "expected_output": "A one-word documentation fix, nothing else.",
+      "expectations": [
+        "The typo is corrected in README.md",
+        "No a11y-loop command was run",
+        "No accessibility guidance, audit, or checklist appears in the response",
+        "No other files were modified"
+      ]
+    }
+  ]
+}

package/skill/a11y-loop/evals/trigger-evals.json

@@ -0,0 +1,20 @@
+[
+  { "query": "Create a signup page at src/signup.html with name, email, password and a country dropdown", "should_trigger": true },
+  { "query": "Add a Settings dialog to src/App.jsx that opens from a gear icon button in the header", "should_trigger": true },
+  { "query": "Build a three-tier pricing section with cards and a Choose plan button, make it look modern", "should_trigger": true },
+  { "query": "Our brand color is #7C9EC4 on white for body links — add a dark theme to src/tokens.css", "should_trigger": true },
+  { "query": "The dashboard needs tabs: Overview, Billing, Members. Add them to Dashboard.tsx", "should_trigger": true },
+  { "query": "Style the nav bar so it collapses into a hamburger menu on mobile", "should_trigger": true },
+  { "query": "Run an accessibility audit on http://localhost:3000 and tell me what's wrong", "should_trigger": true },
+  { "query": "A reviewer says the icon buttons in src/Toolbar.jsx aren't accessible, can you check and fix them", "should_trigger": true },
+  { "query": "Add alt text to all the images in src/pages/about.html", "should_trigger": true },
+  { "query": "Is this modal usable with a screen reader and the keyboard alone?", "should_trigger": true },
+  { "query": "Check whether our color palette meets WCAG AA contrast", "should_trigger": true },
+  { "query": "I fixed the contrast issues you found — did it work, and did I break anything?", "should_trigger": true },
+  { "query": "Refactor the argument parsing in bin/deploy.js to use node:util parseArgs", "should_trigger": false },
+  { "query": "This query times out, rewrite the correlated subquery as a window function", "should_trigger": false },
+  { "query": "There's a typo in README.md, 'recieve' should be 'receive'", "should_trigger": false },
+  { "query": "Add retry with exponential backoff to the S3 upload in workers/ingest.js", "should_trigger": false },
+  { "query": "Write a GitHub Actions workflow that runs the unit tests on push", "should_trigger": false },
+  { "query": "Why is my Express middleware running twice per request?", "should_trigger": false }
+]