frontend-code-review

Frontend Code Review

Review the requested scope for concrete defects and violations of explicit project contracts. This skill owns review decisions; its references route to canonical rules without activating another skill's implementation workflow.

Evidence First

1. Establish the review scope from the requested files or current diff.
2. Read the changed lines, their behavior owner, and the nearest scoped AGENTS.md.
3. Trace public consumers, generated contracts, primitive APIs, or runtime configuration only when they decide correctness.
4. Report findings tied to an observable failure, violated contract, security boundary, or demonstrated maintenance risk. Explicit team conventions are contracts: establish their scope and exceptions, and do not invent user impact to justify a convention finding.

Rule Routing

Read only the packs matched by the diff:

• DOM semantics, focus, keyboard, forms, disabled state, or visible interaction: references/accessibility-ui.md
• Dify UI imports, Base UI wrappers, overlays, tokens, or primitive contracts: references/dify-ui.md
• Component ownership, props, state, Effects, navigation, or module boundaries: references/component-architecture.md
• Generated clients, Query, mutations, auth, SSR, URL state, or persistence: references/data-query-contracts.md
• Test files or a concrete missing-regression-test finding: references/testing.md
• Bundle, waterfall, rendering, or subscription cost supported by evidence: references/performance.md
• Stable Dify runtime invariants in the named paths: references/dify-invariants.md
• General TypeScript or styling quality not owned above: references/code-quality.md

Read packages/dify-ui/README.md, packages/dify-ui/AGENTS.md, packages/dify-ui/docs/overlays.md, or web/docs/test.md only when the reviewed code falls under that contract. Check current official documentation when local code and bundled references do not settle a framework, browser, or accessibility behavior.

Severity And Output

• P0: security or privacy leak, data loss, production crash, or inaccessible critical workflow.
• P1: user-visible regression, invalid API or authorization contract, hydration failure, or broken primary interaction.
• P2: concrete maintainability, performance, test, or accessibility defect, or a material violation of an explicit project contract.
• P3: minor actionable cleanup; omit unless the user requested a thorough audit.

Lead with findings ordered by severity. Include a tight file and line reference, the observed failure or applicable project rule, and a concrete fix direction. Explain the rule's applicability for convention findings; describe downstream consequences only when supported by evidence. When no findings remain, say so briefly and state any material verification gap. Do not add praise sections, speculative risks, or an unsolicited offer to implement fixes.