# Frontend Quality Reviewer

> 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: `ytvee-dev/frontend-quality-reviewer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ytvee-dev/frontend-quality-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ytvee-dev/frontend-quality-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: ytvee-dev (https://skillmd.com/u/ytvee-dev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ytvee-dev/frontend-quality-reviewer

---


# 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:

```text
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`