audit

Overview of audit skill

What the audit skill does

The audit skill runs a structured technical UX audit of a page, feature, or component. It checks implementation quality across accessibility, performance, theming, responsive behavior, and front-end anti-patterns, then returns a scored report with severity levels from P0 to P3 plus an action plan.

Who should use audit

This audit skill is best for front-end teams, design engineers, product designers reviewing shipped UI, and AI users who need a repeatable technical review instead of a loose “please critique this UI” prompt. It is especially useful for UX Audit work where the goal is to identify concrete defects and risks in implementation.

Best-fit job to be done

Use audit when you need to answer questions like:

• “What is technically wrong with this page?”
• “Which issues are severe enough to prioritize now?”
• “Is this component accessible and responsive in practice?”
• “Where are the implementation anti-patterns before we start fixing?”

This is not a redesign tool. It is a diagnostic skill that documents issues so other commands or humans can fix them.

What makes this audit skill different

The main differentiator is structure. Instead of giving an unranked list of observations, audit is designed to:

• inspect multiple quality dimensions in one pass
• score each dimension consistently
• separate technical defects from subjective design taste
• produce prioritized findings, not just commentary

Important constraints before you install

The repository makes one dependency explicit: audit should be used with /frontend-design, and if design context does not exist yet, you are expected to run /teach-impeccable first. That matters because the audit relies on prior context gathering rather than guessing product intent from a screenshot or isolated code snippet.

How to Use audit skill

Install context and invocation

The repository does not expose its own package-specific audit install command inside SKILL.md, so installation depends on the skill runner you use. In a skills-enabled setup, you invoke the audit skill by name and pass an area such as a page, feature, or component. The declared argument hint is:

[area (feature, page, component...)]

A practical invocation looks like:

• audit checkout page
• audit pricing table component
• audit onboarding flow

Run the required prerequisite first

Before using this audit skill, follow the repo’s mandatory preparation:

1. Invoke /frontend-design
2. Follow its context gathering protocol
3. If no design context exists yet, run /teach-impeccable first

This is not optional repo fluff. If you skip it, the audit may misread product intent, misclassify anti-patterns, or give low-value findings based on incomplete context.

What input the audit skill needs

audit works best when you provide more than a vague target name. Strong inputs usually include:

• the exact surface to inspect
• links, screenshots, or code paths
• expected user flows
• target devices or breakpoints
• known problem areas
• constraints such as design system rules or performance budgets

A weak input:

• “Audit my app”

A stronger input:

• “Audit the mobile checkout page in the signed-in flow. Focus on accessibility, responsive issues, and performance regressions affecting form completion. Primary files are app/checkout/page.tsx and components/PaymentForm.tsx.”

Turn a rough goal into a good audit prompt

For better audit usage, include the scope, evidence, and output expectation in one request. A strong prompt pattern is:

• target: page, feature, or component
• context: who uses it and on what devices
• evidence: URL, screenshots, or code files
• focus: dimensions you care about most
• output: ask for scores, severity, and action plan

Example:
“Run the audit skill on the account settings page. Review accessibility, keyboard navigation, semantic structure, responsive behavior, and theming consistency. Use the attached screenshots and inspect SettingsPanel.tsx. Return a scored report by dimension, list issues with P0-P3 severity, and end with the top fixes to schedule first.”

What the skill evaluates in practice

Based on the repository, the audit covers five technical dimensions:

• accessibility
• performance
• theming
• responsive design
• front-end anti-patterns

This makes it a good fit for technical UX Audit work where problems cross code quality and user experience, but still need to remain verifiable.

What output to expect

A useful audit run should produce:

• dimension-by-dimension scores, typically 0-4
• concrete findings tied to observable implementation issues
• severity ratings from P0 to P3
• an actionable plan for follow-up work

That structure is valuable because it helps teams decide what to fix first instead of treating every finding as equally urgent.

Best workflow for first-time users

A low-friction workflow is:

1. prepare design and product context via /frontend-design
2. define one narrow audit target
3. provide code paths or screenshots
4. run audit
5. review the scored report
6. convert the top P0 and P1 issues into tickets
7. rerun the audit after fixes

Start with one page or component, not the whole product. The skill is more useful when scope is tight enough to support detailed, defensible findings.

Repository reading path before adoption

If you want to assess fit before relying on the skill, read in this order:

1. SKILL.md for invocation rules and required preparation
2. the “MANDATORY PREPARATION” section for dependencies
3. the “Diagnostic Scan” section for evaluation categories
4. the dimension scoring criteria and severity logic

Because this skill ships as a single SKILL.md, the main adoption question is not hidden tooling; it is whether you accept its process and scoring model.

When audit is better than a generic prompt

A generic prompt can list obvious UI flaws, but this audit skill is stronger when you need:

• consistent scoring across reviews
• technical rather than stylistic evaluation
• severity-based prioritization
• repeatable checks for multiple surfaces

If your team needs comparable audits across several pages, the structure alone is a practical advantage.

Common setup mistake

The most common misuse is treating audit like a freeform design critique. The repository is clear that this is a code-level audit, not a general design review. If you ask for brand, layout taste, or visual direction without implementation evidence, you are using the wrong tool or an incomplete workflow.

audit skill FAQ

Is this audit skill only for accessibility?

No. Accessibility is one major dimension, but the skill also checks performance, theming, responsive design, and anti-patterns. If you need a broader technical UX Audit rather than an accessibility-only review, audit is a better fit.

Is audit suitable for beginners?

Yes, if you can clearly identify what surface should be reviewed. The scoring and severity model help beginners turn “something feels off” into a more actionable defect list. The main beginner trap is skipping the prerequisite context step.

Do I need code access to use audit?

Not always, but code access improves output quality. You can start with screenshots or a live page, yet the skill is fundamentally implementation-oriented. If you want reliable findings on semantics, ARIA, structure, or anti-patterns, giving code paths helps a lot.

When should I not use audit?

Do not use audit when you want:

• a creative redesign
• copywriting feedback
• product strategy advice
• purely visual brand critique
• direct code fixes in the same step

The skill is for diagnosis and prioritization, not solution implementation.

How is audit different from asking an AI to “review this UI”?

Ordinary prompts often produce mixed-quality feedback with no scoring logic and weak prioritization. The audit skill is better when you need a stable review format, clearer severity levels, and a technical lens grounded in measurable checks.

Can I use audit for a whole app?

You can, but adoption is smoother if you start smaller. Audit one page, flow, or component first. Large-scope requests often produce shallow findings unless you provide clear boundaries and representative evidence.

How to Improve audit skill

Give narrower scope for better audit results

The easiest way to improve audit output is to reduce scope. “Audit the dashboard” is usually too broad. “Audit the table filtering experience on the dashboard at mobile width” gives the skill a better chance to inspect deeply and prioritize correctly.

Provide evidence the skill can verify

Stronger inputs improve trustworthiness. Good evidence includes:

• URL or route
• screenshots at key breakpoints
• affected components
• relevant code files
• reproduction steps
• known accessibility or performance complaints

The skill is strongest when it can verify, not infer.

Ask for the exact report shape you need

If you need a usable deliverable, say so. For example:

• “Score each dimension 0-4”
• “Use P0-P3 severity”
• “Group findings by page section”
• “End with the top five fixes by user impact”

This keeps the audit aligned with your delivery workflow.

Separate diagnosis from fixing

The repository explicitly positions audit as a documentation step. Do not overload the first run by asking for diagnosis, redesign, implementation, and code patching all at once. First get a clean audit report. Then use follow-up skills or prompts to address the highest-priority findings.

Improve weak first outputs with targeted follow-ups

If the first audit guide output feels generic, do not rerun the same prompt unchanged. Instead add:

• missing context
• narrower scope
• concrete files
• target device sizes
• user flow details
• the dimensions you care about most

A better second prompt is usually more effective than asking for “more detail.”

Watch for common failure modes

Typical low-quality audit results come from:

• missing prerequisite context
• too-broad scope
• no screenshots or code references
• asking for subjective design feedback instead of technical review
• combining unrelated surfaces in one request

These issues make the report less actionable and less defensible.

Use audit as a recurring QA checkpoint

For teams, the best long-term use of this audit skill is as a repeatable checkpoint:

• before release
• after a major UI refactor
• after design system migration
• when accessibility bugs accumulate
• when responsive regressions appear

That repeatability is where the scoring model becomes more valuable than a one-off review.

Improve prioritization after the first pass

After the initial audit, ask follow-up questions such as:

• “Which P0 and P1 issues block release?”
• “Which findings are fastest to fix for the most user benefit?”
• “Which issues likely stem from shared components?”
• “Which problems should be solved in the design system rather than locally?”

That turns the audit from a report into a roadmap.

Pair audit with the right upstream context

Because the repo requires /frontend-design, treat audit for UX Audit as one step in a larger review flow:

1. gather product and design context
2. run audit
3. prioritize findings
4. hand off fixes to implementation-focused workflows
5. rerun the audit to confirm improvement

This sequence produces better outcomes than using the audit skill in isolation.