Skip to content
cccskills
FreePublished on GitHub

audit-ai-frontend

Audit AI-generated, AI-shaped, or AI-looking frontend code, UI screenshots, and design diffs. Use for prompts like "audit AI frontend", "de-slop UI", "componentize this screen", "parameterize this React/Tailwind/shadcn UI", "make it responsive/accessible", or "review design-system drift"; check component APIs, reusable props/data models, modular composition, shared primitives/tokens, responsive resilience, accessibility, copy quality, hard-coded fixture screens, one-off CSS piles, and generic cards/gradients/fonts.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573 stars(GitHub 573 + cccskills 0)
Works withPlaywright

Run score Not tested

See how to install

Files included (6)

  • SKILL.md5.0 KB
  • agents/openai.yaml317 B
  • references/patterns.md13.9 KB
  • references/rubric.md4.4 KB
  • references/sources.md2.3 KB
  • references/workflows.md8.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

AI Frontend Audit

Use

Audit or repair frontend UI/code that looks generically AI-generated, while preserving existing product structure unless the user asks for a redesign.

Review in this order:

  1. Establish the local contract.

    • Read components, routes/pages, CSS/theme tokens, existing primitives, design-system conventions, copy style, and data/state patterns.
    • If runnable, invoke $playwright or $playwright-interactive and follow that skill's SKILL.md; this skill decides what to inspect, not browser mechanics.
    • If screenshot-only, review visuals but label implementation risks as Inferred.
  2. Inspect data flow and component shape before styling.

    • Check whether repeated UI is parameterized through props/data or hard-coded as a fixture screen.
    • Look for reusable primitives, narrow component APIs, stable variants, shared state/data models, and realistic loading/empty/error/long-content cases.
    • Flag duplicated JSX, one-off CSS piles, brittle utility strings, boolean-mode soup, over-broad components, and visual constants that should be tokens.
  3. Load only the reference you need.

    • references/patterns.md for concrete AI-tell and code-smell fixes.
    • references/rubric.md for broad UX/a11y/component/design audits.
    • references/workflows.md for code-structure, Playwright QA, reference-packet, and brief-lock loops.
  4. Preserve local system intent while removing accidental defaults.

    • Keep copy/order/IA and known product tokens unless the user asks for a redesign.
    • Keep a common-looking font/card/palette only if adjacent screens or documented tokens already use it; replace it when the style exists only in the generated screen.
    • If references are missing, derive one explicit design contract from product domain + user job + existing primitives; do not fabricate named reference sites.
  5. Fix in this order.

    • P0: keyboard, labels, contrast, touch targets, mobile overflow, missing loading/empty/error states.
    • P1: hard-coded fixture screens, weak data models, duplicated markup/styles, brittle component APIs, token drift, boolean-mode soup.
    • P1: generic SaaS layout, card overuse, icon-pill repetition, Inter/Roboto/system defaults, purple/indigo/cyan gradient/glass tropes, vague CTA/copy.
    • P2: spacing rhythm, token consistency, one memorable visual rule, reduced-motion and state polish.
  6. Re-verify in browser after edits whenever possible.

Output

For each finding, include:

  • Issue
  • Evidence
  • Class (P0, P1, P2)
  • Root cause (Component/API, Data/state, Responsive/a11y, Design-system, Copy, Visual default)
  • Why it matters / why it reads as generic
  • Possible non-AI explanation
  • Smallest fix
  • Acceptance check
  • Confidence (High, Medium, Low)
  • File/line when code is available

Return only the top 5-8 findings and merge repeated symptoms under one root cause. End with one line: If I had to change only one thing: ...

For implementation asks, patch the code directly. Prefer the smallest local abstraction that makes the next screen/state easier: typed data, props, variants, slots/children, existing primitives, or tokens. Summarize only meaningful component/design changes and remaining risk.

Guardrails

  • Treat "AI-looking" as a quality smell, not a provenance claim.
  • Prefer objective defects over taste opinions.
  • Prefer local idiom over a new abstraction. Componentize only when it removes duplication, supports real states/data, or matches established primitives.
  • When auditing shadcn/ui projects, preserve semantic component usage and tokens. Use the shadcn skill if component APIs, registry install/update, or shadcn-specific composition rules are part of the fix.
  • Avoid anti-slop overcorrection: no random ornaments, novelty fonts, or one-off visual chaos.
  • Anchor each finding in code, screenshots, DOM/a11y snapshots, or browser behavior, and separate fact from inference.

Resource

  • references/patterns.md: checklist of AI-frontend tells, code smells, and repair patterns.
  • references/rubric.md: compact UX/a11y/component/design-quality rubric for broader audits.
  • references/workflows.md: code-structure audit, Playwright QA, reference-packet, and brief-lock loops; delegates browser mechanics to $playwright and $playwright-interactive.
  • references/sources.md: research basis and links for periodic prompt refreshes.
  • Use $playwright and $playwright-interactive directly for browser execution workflows.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Meet or work with Assistant, the user's relaxed ongoing work support. Use when the user invokes Assistant, starts or resumes an Assistant chat, asks what they should know, wants proactive work awareness, asks for reply drafts, asks to keep an eye on work, or needs follow-up/check-in help. On first contact, start with exactly "Hi, I'm your assistant." then decide whether onboarding is brand new, partial, or already established.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

Audit, de-slop, parameterize, modularize, or safely clean up AI-generated or AI-shaped backend/general code. Use for Python, TypeScript, or other implementation diffs that may contain duplicate helpers, fixture hacks, hard-coded test data, over-defensive control flow, broad exception wrappers, config-bag or boolean-mode soup, speculative scaffolding, hallucinated APIs/dependencies, local-idiom drift, brittle tests, or maintainability/safety/performance gaps after a feature, bugfix, prototype, or agent pass.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

Audit pasted chatbot output, AI-cleanup diffs, wiki drafts, Markdown/MDX/docs, and source-backed articles for generic AI fluff, LLM writing tells, weak audience model, lack of theory of mind, inflated significance, vague attribution, leaked tokens, placeholders, broken markup, fabricated or mismatched citations, and detector false positives. Use for requests like "AI writing audit", "check for AI slop", "find writing fluff", "does this sound like ChatGPT", "cleanup LLM tells", "make this less generic", "verify these citations", "detector flagged this", or text containing turn0search0, oaicite, oai_citation, contentReference, utm_source=chatgpt.com, malformed references, or wrong target-format markup.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

Help address review/issue comments on the open GitHub PR for the current branch using `oai_gh` or `gh`; verify auth first and prompt the user to authenticate if not logged in.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

Review git changes and split them into semantic commits with clear messages. Use when the user asks to commit work, clean up local history, or group a mixed diff into logical commits. Do not commit on main or master unless the user explicitly asks.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `oai_gh` or `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

See all skills by jxnl

Report a problem with this skill