/fec-code-review

name: fec-code-review
description: Use when the user asks for general frontend code review, PR review, merge-readiness assessment, architecture maintainability, type-safety, rendering/state risks, style consistency, testability gaps, or a cross-cutting review summary. Delegate deep security, accessibility, E2E, or performance investigations to their specialized skills; Chinese triggers include code review, code review, review.

Front-end code review

Review modes and coverage

User-specified scope takes precedence over the default. Use the following three review modes:

• **Change review**: only when recent changes, current edits, staged changes, a PR or a commit are explicitly requested or clearly established by the active task, review those changes and necessary context. For local changes, inspect staged and unstaged diffs and relevant untracked project files within the requested scope; a staged-only request reviews only staged changes. If there are no changes, report that there is nothing to review; do not switch to recent commits or expand scope automatically.
• **Targeted review**: when files or directories are specified, inventory and review existing code in that scope, including unchanged code; no Git diff is required.
• **Project review (default)**: when no scope or change context is specified, or when the entire project is requested, inventory project-owned frontend code, related tests, configuration and dependency declarations, then review in module batches, including unchanged code; no Git diff is required.

Select scope before collecting diffs. A file/directory alone means full review of that scope; a path combined with an explicit change request restricts incremental review to that path. An unqualified invocation defaults to project review even if Git changes exist. At review start, state the selected mode and target scope. When automatically delegating review after edits, pass the current change scope explicitly; do not trigger project review merely because the reviewer was called.

Exclude dependency directories, build outputs, caches, generated files and third-party code by default, and record exclusions. Keep the frontend responsibility boundary; this is not a backend audit. A nonexistent target or a scope with no relevant files must be reported explicitly, not replaced with another scope.

Merge findings with the same root cause across batches. Report **review mode, target scope, reviewed files/modules, exclusions, unreviewed files/modules, completion status and verification commands/results**. If context or execution limits prevent completion, mark the review partial and list remaining modules; never claim complete project coverage. Reading callers for context or running project-wide lint/typecheck does not count as manual review of those files.

Change reviews retain merge recommendations. Targeted and project reviews use a risk assessment (Low / Medium / High, with blocking findings), not a claim of merge readiness. Preserve severity levels, evidence requirements and report filenames. Output reports only unless repairs are explicitly requested.

Purpose

Review the front-end code quality from 8 dimensions including architecture, type safety, accessibility, style consistency, performance and testability, and output a graded review report.

Procedure

1. Read the project facts first: package scripts, frameworks, directory conventions, recent diffs, existing tests and related rules. 2. Find problems based on risk, rather than picking styles based on personal preference; each finding must be able to point to specific files, line numbers, and user impacts. 3. Use five axes to converge conclusions: correctness, maintainability, type/interface, user experience, and verification coverage. 4. Only preliminary screening will be done for deep water areas such as safety, accessibility, E2E, and performance; diversion will be clearly defined when special investigation is needed. 5. During multi-dimensional review, first split according to responsibilities, and then merge similar findings; only one main finding for the same root cause of the same file is retained to avoid repeated noise. 6. List blocking issues first in the report, then recommendations; do not write firm conclusions on issues without evidence.

Multi-dimensional review arrangement

When changes span multiple quality dimensions, organize them according to "main review + special diversion" instead of having all dimensions repeatedly check the same code.

| Dimension | Trigger condition | Diversion boundary | | ------------------- | ---------------------------------------------------- | ------------------------------------ | | TypeScript Projects and Type Contracts | DTOs, generics, public types, type guards, `any`, assertions, tsconfig | In-depth type modeling and TS configuration handed over to the TypeScript process | | State management | State attribution, global store, URL state, derived state, cross-page synchronization | State selection and migration are handed over to the state management special process | | Security | User input, HTML rendering, token, upload, third-party script | Vulnerability level analysis is handed over to the security-specific process | | Accessibility | Pop-up windows, menus, forms, keyboard operations, focus management | WCAG scrutinizes the special accessibility process | | Performance | Large lists, heavy dependencies, repeated requests, long tasks, package sizes | Handle performance evidence and budget to the performance-specific process | | E2E | Key user path, login status, payment, cross-page process | Browser use cases and traces are handed over to E2E special process |

Discover merge rules:

• When the same root cause appears in multiple dimensions, only the highest severity level is retained and the related dimensions are listed in `Dimension`.
• Repeated patterns in multiple places in the same file are merged into one pattern-level discovery, and repre