Audit UI code with ak:web-design-guidelines

Use ak:web-design-guidelines for a read-only review of web UI code. Before each review, the Skill fetches the current upstream Web Interface Guidelines, reads the file or pattern you supplied, applies the fetched rules, and reports concise findings grouped by file in file:line form.

Choose ak:web-design-guidelines for a current audit

Use ak:web-design-guidelines when

• You want to review UI, accessibility, UX, responsive behavior, forms, navigation, motion, content handling, theming, or performance patterns.
• You have a bounded file, directory, or glob to inspect.
• You want findings and locations without starting implementation.

Choose another workflow when

• You want a broader design direction or bundled recommendation. Use ak:ui-ux-pro-max.
• You want the issues fixed in code. Review first, then authorize a separate implementation workflow such as ak:frontend-design.
• You need token architecture or component specs. Use ak:design-system.

Prepare the audit scope and runtime

Provide an exact file or pattern, the relevant framework and browser targets, and any approved exception. Confirm network access is permitted because the workflow fetches https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md before each review. If no scope is supplied, the Skill asks for one.

Complete Onboarding and review Runtime adapters.

Run the Skill

/ak:web-design-guidelines app/launch/**/*.tsx Review only these files. Fetch the current guidelines, report file:line findings, and do not edit code, install packages, or access live accounts

/ak:web-design-guidelines app/launch/**/*.tsx Review only these files. Fetch the current guidelines, report file:line findings, and do not edit code, install packages, or access live accounts

$ak:web-design-guidelines app/launch/**/*.tsx Review only these files. Fetch the current guidelines, report file:line findings, and do not edit code, install packages, or access live accounts

The canonical argument is [file-or-pattern]. The Skill defines no mode or fix flags.

Understand the stages

1. Confirm the scope. The workflow resolves the supplied file or pattern and avoids unrelated code.
2. Fetch the current rules. It retrieves the upstream command.md at run time rather than using a release-pinned copy.
3. Read the selected files. It gathers only the code needed for the audit.
4. Apply every fetched rule. Current categories include accessibility, focus, forms, animation, typography, content, images, performance, navigation, touch, safe areas, theming, locale, hydration, and interaction.
5. Report findings. Output is grouped by file, uses file:line, states the issue tersely, and marks a file as passing when no issue is found.

Keep the review read-only

Fetching the public rule file does not authorize uploading local source, browsing other sites, changing code, installing a checker, opening a pull request, publishing, or deploying. Fixes require a separate request and normal project verification.

Verify the findings and evidence

A complete audit should identify the reviewed scope, upstream URL and retrieval evidence, every finding with a valid local line, and pass markers where appropriate. Spot-check the cited code and confirm the rule applies in the project's framework and runtime context.

The report is static source review, not proof from a browser, assistive technology, user test, performance trace, or formal accessibility assessment.

Troubleshoot or continue

Continue with the Marketing Kit overview or Projects, artifacts, and checkpoints.

Know the current limits

• Stable and beta contain byte-identical ak:web-design-guidelines content in the inspected releases.
• The guideline body is network-dependent and not bundled or version-pinned.
• Upstream rules are broad heuristics. Some findings need framework, product, browser, locale, or assistive-technology context.
• A clean report does not guarantee accessibility, usability, responsiveness, performance, security, conversion, or standards compliance.