1---
2name: frontend-code-review
3description: Review Dify frontend code for correctness, accessibility, component design, dify-ui usage, data/query boundaries, performance, and tests. Trigger for `.tsx`, `.ts`, `.js`, UI, React, Next.js, pending-change, or focused frontend review requests.
4---
5 
6# Frontend Code Review
7 
8## When To Use
9 
10Use this skill when the user asks to review, audit, analyze, or sanity-check frontend code under `web/`, `packages/dify-ui/`, or frontend-adjacent TypeScript files.
11 
12Supported modes:
13 
14- **Pending-change review**: inspect staged and working-tree changes.
15- **File-focused review**: inspect explicitly named files or paths.
16- **Diff/snippet review**: review pasted diffs or snippets using best-effort references.
17 
18Do not use this skill for backend-only code under `api/`; use `backend-code-review` instead.
19 
20## Required Context
21 
22Before reviewing, read the relevant local contracts:
23 
24- `web/AGENTS.md` for Dify frontend workflow, overlays, design tokens, state, and tests.
25- `packages/dify-ui/README.md` and `packages/dify-ui/AGENTS.md` when code uses or changes `@langgenius/dify-ui/*`.
26- `web/docs/overlay.md` when reviewing dialogs, drawers, popovers, tooltips, menus, selects, comboboxes, or other floating UI.
27- `web/docs/test.md` and the `frontend-testing` skill when reviewing tests or testability.
28- `karpathy-guidelines` for scope control and focused, verifiable changes.
29- `how-to-write-component` when reviewing React component structure, ownership, effects, query/mutation contracts, or memoization.
30 
31For any UI, UX, or accessibility review, fetch the latest Web Interface Guidelines before finalizing findings. Treat them as a required baseline, not the complete source of accessibility truth:
32 
33```text
34https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
35```
36 
37If the review depends on a current framework, SDK, browser API, or accessibility behavior and local code does not settle it, check the current official docs first. For browser compatibility, deprecation, or behavior-sensitive frontend APIs, verify MDN or the relevant standard.
38 
39## Rule Packs
40 
41Apply every relevant rule pack:
42 
43- [references/accessibility-ui.md](references/accessibility-ui.md) — accessibility, semantic HTML, focus, forms, keyboard, disabled states, copy, and long-content behavior. Combines Web Interface Guidelines with Dify UI, Base UI, MDN, and local primitive contracts.
44- [references/dify-ui.md](references/dify-ui.md) — Dify UI primitive usage, Base UI semantics, overlays, forms, tokens, radius mapping, and primitive boundaries.
45- [references/component-architecture.md](references/component-architecture.md) — component ownership, props, state, effects, exports, wrappers, and feature organization.
46- [references/data-query-contracts.md](references/data-query-contracts.md) — generated contracts, TanStack Query, mutations, workspace/auth/SSR boundaries, URL/local storage state.
47- [references/performance.md](references/performance.md) — React/Next performance review rules from Vercel guidance, scoped to real risk.
48- [references/testing.md](references/testing.md) — frontend test review rules.
49- [references/dify-invariants.md](references/dify-invariants.md) — stable Dify-specific runtime invariants that generic React/a11y rules will not catch.
50- [references/code-quality.md](references/code-quality.md) — general TypeScript, styling, naming, and maintainability rules.
51 
52## Review Process
53 
541. Identify the review scope. For pending changes, inspect `git diff --stat`, `git diff`, and staged diff if relevant. For file-focused reviews, stay within the named files unless a referenced owner/contract must be read.
552. Read code around the changed lines and the owning module. Do not review by isolated snippets when nearby ownership, labels, query inputs, or overlay structure decide correctness.
563. Check user-visible regressions first: accessibility, broken interaction, auth/permission leaks, query/hydration errors, data loss, navigation mistakes, and impossible states.
574. Then check maintainability and performance: ownership, effects, wrappers, memoization, bundle/waterfall risks, tests, and design-system drift.
585. Report only actionable findings. Do not list speculative risks, style preferences, or broad refactors unless they are directly tied to a reproducible issue in scope.
59 
60## Severity
61 
62- **P0**: security/privacy/auth leak, data loss, production crash, inaccessible critical flow, or broken primary workflow.
63- **P1**: user-visible regression, hydration/SSR failure, invalid API/query contract, broken keyboard/focus behavior, or serious design-system/a11y violation.
64- **P2**: maintainability or performance issue likely to cause bugs, duplicated state, incorrect ownership, missing tests for risky behavior, or non-critical a11y issue.
65- **P3**: minor cleanup with clear value. Omit unless the user asked for a thorough audit.
66 
67## Output Format
68 
69Lead with findings, ordered by severity. Use this structure:
70 
71```markdown
72## Findings
73 
74- [P1] Short issue title
75  File: `path/to/file.tsx:123`
76  Why it matters and how to reproduce or reason about it.
77  Suggested fix: concrete fix direction.
78 
79## Open Questions
80 
81- Question or assumption, if any.
82 
83## Summary
84 
85Brief secondary context. Mention tests not run or residual risk.
86```
87 
88Rules:
89 
90- If there are no findings, say `No issues found.` and mention any test gaps or residual risk.
91- Always include file and line when available.
92- Keep findings concrete and reproducible.
93- Do not include praise sections by default.
94- Do not ask to apply fixes unless the user explicitly wants review plus implementation.
95