Audit web UI with ak:web-design-guidelines

Use ak:web-design-guidelines for a focused review of existing UI files. The Skill fetches the current Web Interface Guidelines at run time, applies every fetched rule to the selected files, and reports terse file:line findings.

Choose it for a current, file-level audit

Use it when

• You want to review UI, UX, accessibility, or web design best practices in specific files or a bounded file pattern.
• You need findings tied to exact source locations rather than a redesign.
• You want the latest upstream guideline text instead of packaged design advice.

Choose another workflow when

• You need a product design system, style recommendation, or broader UX strategy. Use ak:ui-ux-pro-max.
• You want the assistant to implement shadcn/ui or Tailwind changes. Use ak:ui-styling after reviewing findings.
• You need a full browser or assistive-technology test. This Skill reviews code; it does not by itself prove rendered behavior.

Prepare the review boundary

• Provide one or more exact files or a narrow pattern. If you omit them, the Skill must ask which files to review.
• Include generated source only when you intend to act on it; prefer the owning source file over derived output.
• Make network access available to the upstream raw guideline source. The Skill does not bundle a fallback ruleset.
• Preserve the fetched source identity and retrieval time in the review evidence when reproducibility matters.

Run the Skill

/ak:web-design-guidelines "Review src/components/account-dialog.tsx and src/styles/theme.css; report only file:line findings with the violated rule and no code changes"

/ak:web-design-guidelines "Review src/components/account-dialog.tsx and src/styles/theme.css; report only file:line findings with the violated rule and no code changes"

$ak:web-design-guidelines "Review src/components/account-dialog.tsx and src/styles/theme.css; report only file:line findings with the violated rule and no code changes"

The Skill has no documented mode flags. Its input is the file or pattern to review. The observable workflow is:

1. Fetch the latest guideline document from its declared upstream source.
2. Read only the selected files and resolve line numbers against their current contents.
3. Apply every rule and the output instructions contained in the fetched text.
4. Return terse file:line findings. A clean review should say no finding was found rather than inventing advice.

Keep external authority visible

• Fetching the source contacts an external service and reveals the requested URL to that service. It should not transmit project files.
• Do not send private source code to a search provider when local file reading is sufficient; fetch the public rules, then review files locally.
• A finding is advisory until you confirm project context and rendered behavior. Do not modify code, install packages, or publish a report unless requested.
• A missing network capability is a blocker for a current-rules audit. Do not silently substitute remembered or bundled guidance.

Verify findings and limits

A useful report identifies the reviewed files, the fetched guideline source and time, each file:line finding, the relevant rule, and any file that could not be read. Before fixing, inspect component composition, design tokens, browser behavior, keyboard flow, focus order, contrast, zoom, reduced motion, and screen reader output as relevant. Static source review cannot prove these runtime facts.

Stable and beta contain the same ak:web-design-guidelines instructions in the documented releases, but the fetched upstream rules can still differ by run. Continue with Runtime adapters or the Engineer Kit overview.