메뉴
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.
SOC 직업 분류 기준
| name | frontend-code-review |
| description | 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. |
Use 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.
Supported modes:
Do not use this skill for backend-only code under api/; use backend-code-review instead.
Before reviewing, read the relevant local contracts:
web/AGENTS.md for Dify frontend workflow, overlays, design tokens, state, and tests.packages/dify-ui/README.md and packages/dify-ui/AGENTS.md when code uses or changes @langgenius/dify-ui/*.web/docs/overlay.md when reviewing dialogs, drawers, popovers, tooltips, menus, selects, comboboxes, or other floating UI.web/docs/test.md and the frontend-testing skill when reviewing tests or testability.karpathy-guidelines for scope control and focused, verifiable changes.how-to-write-component when reviewing React component structure, ownership, effects, query/mutation contracts, or memoization.For 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:
https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
If 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.
Apply every relevant rule pack:
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.Lead with findings, ordered by severity. Use this structure:
## Findings
- [P1] Short issue title
File: `path/to/file.tsx:123`
Why it matters and how to reproduce or reason about it.
Suggested fix: concrete fix direction.
## Open Questions
- Question or assumption, if any.
## Summary
Brief secondary context. Mention tests not run or residual risk.
Rules:
No issues found. and mention any test gaps or residual risk.React/TypeScript component style guide. Use when writing, refactoring, or reviewing React components, especially around abstraction choices, props typing, state boundaries, shared local state with Jotai atoms, API types, query/mutation contracts, navigation, memoization, wrappers, and empty-state handling.
Lightweight coding guardrails for making focused, simple, and verifiable changes in this repo. Use for all coding work.
Generate Vitest + React Testing Library tests for Dify frontend components, hooks, and utilities. Triggers on testing, spec files, coverage, Vitest, RTL, unit tests, integration tests, or write/review test requests.
Write, update, or review Dify end-to-end tests under `e2e/` that use Cucumber, Gherkin, and Playwright. Use when the task involves `.feature` files, `features/step-definitions/`, `features/support/`, `DifyWorld`, scenario tags, locator/assertion choices, or E2E testing best practices for this repository.
Review backend code for quality, security, maintainability, and best practices based on established checklist rules. Use when the user requests a review, analysis, or improvement of backend files (e.g., `.py`) under the `api/` directory. Do NOT use for frontend files (e.g., `.tsx`, `.ts`, `.js`). Supports pending-change review, code snippets review, and file-focused review.