agentsclimarketplace

Frontend quality reviewer

Skill ytvee-dev/webdev-agent-kit/skills/frontend-quality-reviewer

A cross-platform frontend kit for Codex, Claude Code, Cursor, OpenCode, etc. It helps AI coding agents work predictably and safely with existing frontend projects.

Install
npx -y skills add ytvee-dev/webdev-agent-kit --skill frontend-quality-reviewer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Review frontend quality from evidence across code, UI, architecture, TypeScript, security, performance, verification, decomposition, UX, and anti-slop concerns. Returns pass, concerns, or fail without implementing unrequested fixes.

SKILL.md

10.3 KB, as published. Nobody here has run it

Frontend Quality Reviewer

Purpose

Review frontend work for correctness, maintainability, decomposition, security, performance, TypeScript safety, architecture fit, visual quality, UX gates, verification honesty, and independent loop judgment without turning review findings into an unapproved rewrite.

When a loop contract requires independent review, this skill acts as the judge of acceptance criteria and evidence rather than the implementer.

When To Use

Use this skill when:

  • the user asks for review, audit, critique, or quality check;
  • a significant frontend implementation needs a final quality pass;
  • a bugfix or refactor has broad impact and review is appropriate;
  • a loop contract requires independent review;
  • verification failed and was repaired during a loop;
  • claims about security, performance, architecture, decomposition, visual fidelity, UX, or verification need evidence.

When Not To Use

Do not use this skill for direct implementation, bugfixing, refactoring, design spec writing, visual QA only, test creation, package installation, or broad rewrites.

If review finds required fixes, report them first. Do not apply fixes unless the user asked for a combined review-and-fix task or explicitly approves a follow-up fix.

Required Context

  1. Read AGENTS.md.
  2. Read common/review-severity-model.md.
  3. Read common/independent-review-rules.md when acting as loop judge or independent reviewer.
  4. Read the current Goal Contract, Execution Plan, coverage map, and stable identifiers when the work uses durable planning.
  5. Read common/verification-loop-rules.md when loop attempts or verification evidence are in scope.
  6. Read common/approved-patterns.md and common/anti-patterns.md when reviewing changed components.
  7. Read common/ui-ux-priority-checklist.md when reviewing rendered UI or user interaction.
  8. Read conditional UX rules only when the changed surface includes them:
    • common/css-modules-specificity-rules.md for CSS Modules changes;
    • common/form-feedback-rules.md for forms and feedback states;
    • common/navigation-ux-rules.md for navigation and route flows;
    • common/data-visualization-rules.md for dashboards, charts, tables, metrics, or reports;
    • common/icon-quality-rules.md for icons or visual symbols;
    • common/mobile-responsive-rules.md for responsive surfaces.
  9. Read common/typescript-discipline.md for TypeScript surfaces.
  10. Read common/security-review-rules.md when auth, secrets, unsafe HTML, redirects, external input, or permissions are in scope.
  11. Read common/performance-review-rules.md when performance claims are in scope.
  12. Read common/build-tool-boundary-rules.md and common/lint-verification-rules.md when code changed.
  13. Read affected source files, diffs, project overlays, loop contract, verification output, and rendered evidence needed for the review.

Tool Contract

  • May inspect diffs, affected files, project overlays, loop contracts, and verification output.
  • May run existing lint/build/typecheck commands when code changed and the command is already available.
  • May use Browser or Playwright MCP when rendered UI evidence is necessary and available.
  • May use official docs, context7, or MDN for current framework, security, performance, or platform claims.
  • Activate openai_platform_docs only when current OpenAI API or ChatGPT Apps SDK behavior affects a review finding.
  • Must not install packages, add tests, add UI libraries, modify configs, or perform broad rewrites.
  • Must not implement fixes while acting as independent loop judge unless the user explicitly asks for a combined review-and-fix task.
  • Must not add, remove, reorder, renumber, or mark execution-plan slices or redefine acceptance criteria.

Workflow

  1. Define review scope and changed surfaces.
  2. If acting as loop judge or reviewing durable work, read the active AC-### criteria, mapped S-### slices, and coverage evidence first.
  3. Gather evidence from diffs, files, commands, browser output, or supplied artifacts.
  4. Check correctness, architecture boundaries, component decomposition, TypeScript safety, accessibility, visual quality, UX gates, security, performance, build/workspace fit, and verification honesty only where relevant.
  5. For changed UI, check the UI UX priority order before polish-only concerns.
  6. For changed UI, verify that components are split into clear route/page, section, presentational, list/item, helper, selector, adapter, or approved hook boundaries when complexity requires it.
  7. Flag required fixes when components mix routing, data access, state orchestration, transformations, form logic, repeated markup, large JSX, and side effects in one file.
  8. Flag CSS Modules specificity risks, structural decoration, weak form feedback, confusing navigation, dishonest data visualization, inconsistent icons, and unresolved mobile behavior when those concerns are present.
  9. For durable and loop reviews, judge every in-scope AC-### as passed, failed, deviation, or blocked using its named verification evidence.
  10. Assign severity labels: blocking, high, medium, low, nit, or praise.
  11. Distinguish required fixes from optional improvements.
  12. Produce verdict:
    • pass when no required fixes are found and acceptance criteria passed;
    • pass with concerns when no required fixes remain but risks or documented deviations exist;
    • fail when blocking or unresolved required high issues exist, or loop acceptance criteria did not pass.
  13. Report remaining work as findings. Do not create plan slices; route required remaining work to execution-plan-manager in converge mode.
  14. Check lint result when code changed and a lint command exists.
  15. Report unknowns and blocked checks honestly.

Output Contract

Final response: return only facts that affect the user's understanding, confidence, or next action. Omit empty fields and workflow narration.

Return findings first, ordered by severity:

Verdict:
Loop acceptance:
Criteria reviewed: AC-### -> passed | failed | deviation | blocked
Coverage evidence:
Required fixes:
Optional improvements:
Decomposition review:
UX gates reviewed:
Evidence checked:
Lint/build/visual verification:
Unknowns or blocked checks:
Praise:

Use file and line references for code findings whenever available.

Validation Gates

  • Every blocking or high claim must cite concrete evidence.
  • Independent loop review must evaluate the acceptance criteria and evidence, not merely restate the implementer's summary.
  • Every in-scope durable criterion must have an explicit result tied to coverage or verification evidence.
  • Review must preserve stable identifiers and leave plan mutation to convergence.
  • Review must not trigger broad rewrite by itself.
  • Required fixes and optional improvements must be separate.
  • Component decomposition issues must be reviewed regardless of framework, router, state layer, data layer, or styling system.
  • UX gates must be checked when the changed surface includes forms, navigation, data visualization, icons, or responsive behavior.
  • Lint result must be checked when code changed and an existing command is available.
  • Security and performance claims must be source-backed when behavior is current or ambiguous.
  • No testing workflow, UI library, package install, or framework migration may be introduced by default.

Trigger Evals

Should trigger:

  • "Review this frontend change before I merge it."
  • "Check this implementation for AI slop and quality issues."
  • "Audit the TypeScript, performance, and accessibility risks here."
  • "Give me a pass/fail verdict on this UI implementation."
  • "Check whether this component should be split."
  • "Act as the independent reviewer for this loop contract."

Should not trigger:

  • "Fix this bug."
  • "Refactor this component."
  • "Run visual QA only."
  • "Create tests for this feature."

Reference Map

  • common/review-severity-model.md
  • common/independent-review-rules.md
  • common/planning-rules.md
  • common/convergence-rules.md
  • common/verification-loop-rules.md
  • common/approved-patterns.md
  • common/anti-patterns.md
  • common/ui-ux-priority-checklist.md
  • common/css-modules-specificity-rules.md
  • common/form-feedback-rules.md
  • common/navigation-ux-rules.md
  • common/data-visualization-rules.md
  • common/icon-quality-rules.md
  • common/mobile-responsive-rules.md
  • common/security-review-rules.md
  • common/performance-review-rules.md
  • common/typescript-discipline.md
  • common/build-tool-boundary-rules.md
  • common/lint-verification-rules.md

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.