Web Interface Guidelines
Review files for compliance with Vercel's Web Interface Guidelines.
How It Works
- Fetch the latest guidelines from the source URL below
- Read the specified files (or prompt user for files/pattern)
- Check against all rules in the fetched guidelines
- Output findings in the terse
file:line format
Guidelines Source
Fetch fresh guidelines before each review:
https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
Use WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.
Portability note: WebFetch needs outbound network access. If the fetch fails (offline / blocked / 404), do NOT silently invent rules — state the fetch failure, then fall back to the canonical WIG rule families (accessibility/ARIA, keyboard & focus, contrast, touch targets, motion/reduced-motion, forms & labels, layout/responsive, content/copy, performance). Never report a clean pass off un-fetched rules.
Usage
When a user provides a file or pattern argument:
- Fetch guidelines from the source URL above
- Read the specified files
- Apply all rules from the fetched guidelines
- Output findings using the format specified in the guidelines
If no files specified, ask the user which files to review.
Dynamic Workflow orchestration
This review is multi-angle: the guidelines span several independent rule families that don't share state. Run it as a Workflow, not a linear scan.
- Plan — after fetching guidelines, partition the rules into review lenses (e.g. Accessibility & ARIA, Keyboard / focus / interaction, Visual: contrast, spacing, touch targets, motion, Forms & validation, Layout & responsive, Content & copy, Performance). Map each target file/pattern to the lenses it can violate.
- Parallel fan-out — dispatch one review pass per lens over the in-scope files. Lenses are file-disjoint readers (read-only), so they run concurrently with no write conflict. Stay in scope: only the files/pattern provided — never expand to the whole repo.
- Adversarial verify (2-of-3) — every candidate finding must survive falsification before it ships: cite the exact
file:line, confirm the cited code actually violates the fetched rule (not a guess), and discard any finding you can't reproduce against the real source. A finding kept by <2 independent checks (rule match + line-accurate citation + no false-positive on context) is dropped.
- Synthesize — merge surviving findings into ONE ordered list, de-duplicate overlaps across lenses, sort by severity, and write the final report yourself. Never paste a lens's raw output as the verdict.
- Loop-until-dry (large pattern globs) — if the file set is unbounded, batch it; re-run fan-out per batch until every in-scope file is reviewed. Done = no un-reviewed in-scope file remains.
Output contract
Produce a single findings report:
- One line per violation in the guidelines' specified format (terse
file:line — rule — what's wrong — fix).
- Findings ordered by severity (blocker → minor).
- A short header stating: guidelines source + whether the live fetch succeeded, and the exact file set reviewed.
- If zero violations: say so explicitly AND state the file set + rule families checked (a clean pass must be auditable, not assumed).
VERIFY before returning: re-open each cited file:line and confirm the quoted code exists at that location and genuinely violates the cited rule. Drop anything that fails this check. Confirm every in-scope file was reviewed.
Guardrails
- Evidence or it didn't happen — every finding carries a real
file:line citation pointing at code you actually read. No uncited claims.
- No hallucination — never invent rules not present in the fetched guidelines; never invent line numbers. If you couldn't fetch, say so (see portability note) instead of fabricating a pass.
- Scope discipline — review only the provided files/pattern; do not wander the repo or propose unrelated refactors.
- No regression / read-only — this skill reports findings; it does not rewrite the user's UI unless they explicitly ask for fixes after the report.
1---2name: vl-web-design-guidelines3description: Review UI/frontend code against Vercel's Web Interface Guidelines (accessibility, interaction, layout, content, performance best practices). Use when asked to "review my UI", "check accessibility / a11y", "audit design", "review UX", "check my site against best practices", "WIG compliance", or in FR "revois mon UI", "vérifie l'accessibilité", "audit design", "conformité bonnes pratiques web".4---56# Web Interface Guidelines78Review files for compliance with Vercel's Web Interface Guidelines.910## How It Works11121. Fetch the latest guidelines from the source URL below132. Read the specified files (or prompt user for files/pattern)143. Check against all rules in the fetched guidelines154. Output findings in the terse `file:line` format1617## Guidelines Source1819Fetch fresh guidelines before each review:2021```22https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md23```2425Use WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.2627> **Portability note:** `WebFetch` needs outbound network access. If the fetch fails (offline / blocked / 404), do NOT silently invent rules — state the fetch failure, then fall back to the canonical WIG rule families (accessibility/ARIA, keyboard & focus, contrast, touch targets, motion/reduced-motion, forms & labels, layout/responsive, content/copy, performance). Never report a clean pass off un-fetched rules.2829## Usage3031When a user provides a file or pattern argument:321. Fetch guidelines from the source URL above332. Read the specified files343. Apply all rules from the fetched guidelines354. Output findings using the format specified in the guidelines3637If no files specified, ask the user which files to review.3839## Dynamic Workflow orchestration4041This review is multi-angle: the guidelines span several independent rule families that don't share state. Run it as a Workflow, not a linear scan.42431. **Plan** — after fetching guidelines, partition the rules into review lenses (e.g. *Accessibility & ARIA*, *Keyboard / focus / interaction*, *Visual: contrast, spacing, touch targets, motion*, *Forms & validation*, *Layout & responsive*, *Content & copy*, *Performance*). Map each target file/pattern to the lenses it can violate.442. **Parallel fan-out** — dispatch one review pass per lens over the in-scope files. Lenses are file-disjoint readers (read-only), so they run concurrently with no write conflict. **Stay in scope:** only the files/pattern provided — never expand to the whole repo.453. **Adversarial verify (2-of-3)** — every candidate finding must survive falsification before it ships: cite the exact `file:line`, confirm the cited code actually violates the fetched rule (not a guess), and discard any finding you can't reproduce against the real source. A finding kept by <2 independent checks (rule match + line-accurate citation + no false-positive on context) is dropped.464. **Synthesize** — merge surviving findings into ONE ordered list, de-duplicate overlaps across lenses, sort by severity, and write the final report yourself. Never paste a lens's raw output as the verdict.475. **Loop-until-dry** (large pattern globs) — if the file set is unbounded, batch it; re-run fan-out per batch until every in-scope file is reviewed. Done = no un-reviewed in-scope file remains.4849## Output contract5051Produce a single findings report:52- One line per violation in the guidelines' specified format (terse `file:line — rule — what's wrong — fix`).53- Findings ordered by severity (blocker → minor).54- A short header stating: guidelines source + whether the live fetch succeeded, and the exact file set reviewed.55- If zero violations: say so explicitly AND state the file set + rule families checked (a clean pass must be auditable, not assumed).5657**VERIFY before returning:** re-open each cited `file:line` and confirm the quoted code exists at that location and genuinely violates the cited rule. Drop anything that fails this check. Confirm every in-scope file was reviewed.5859## Guardrails6061- **Evidence or it didn't happen** — every finding carries a real `file:line` citation pointing at code you actually read. No uncited claims.62- **No hallucination** — never invent rules not present in the fetched guidelines; never invent line numbers. If you couldn't fetch, say so (see portability note) instead of fabricating a pass.63- **Scope discipline** — review only the provided files/pattern; do not wander the repo or propose unrelated refactors.64- **No regression / read-only** — this skill reports findings; it does not rewrite the user's UI unless they explicitly ask for fixes after the report.
agentik-os