frontend-code-review
bylanggenius· 6 skills
Use only when the user explicitly requests a review or audit of frontend code under web/ or packages/dify-ui/. Supports pending-change, file-focused, and pasted-diff reviews. Do not use for implementation-only requests, diagnosis without review intent, or backend-only code.
How to install frontend-code-review?
langgenius/dify/frontend-code-review
$npx -y skills add langgenius/dify --skill frontend-code-reviewInstalls into the current project.
›Prefer a prompt? Paste this to your agent
Run `npx skills use "https://github.com/langgenius/dify" --skill "langgenius/dify/frontend-code-review"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.
Use the skills in "https://github.com/langgenius/dify" that are relevant to the current task. Run `npx skills add "https://github.com/langgenius/dify"` and select the relevant skills, then follow their instructions.
SKILL.md
| 1 | # Frontend Code Review |
| 2 | |
| 3 | Review the requested scope for concrete, reproducible regressions. This skill owns the review phase and routes directly to its bundled rule packs. For a combined review-and-fix request, establish findings before applying implementation or testing guidance. |
| 4 | |
| 5 | ## Evidence First |
| 6 | |
| 7 | 1. Establish the review scope from the requested files or current diff. |
| 8 | 2. Read the changed lines, their behavior owner, and the nearest scoped `AGENTS.md`. |
| 9 | 3. Trace public consumers, generated contracts, primitive APIs, or runtime configuration only when they decide correctness. |
| 10 | 4. Report only findings tied to an observable failure, violated contract, security boundary, or demonstrated maintenance risk. |
| 11 | |
| 12 | ## Rule Routing |
| 13 | |
| 14 | Read only the packs matched by the diff: |
| 15 | |
| 16 | - DOM semantics, focus, keyboard, forms, disabled state, or visible interaction: [`references/accessibility-ui.md`][accessibility] |
| 17 | - Dify UI imports, Base UI wrappers, overlays, tokens, or primitive contracts: [`references/dify-ui.md`][dify-ui] |
| 18 | - Component ownership, props, state, Effects, navigation, or module boundaries: [`references/component-architecture.md`][component-architecture] |
| 19 | - Generated clients, Query, mutations, auth, SSR, URL state, or persistence: [`references/data-query-contracts.md`][data-query] |
| 20 | - Test files or a concrete missing-regression-test finding: [`references/testing.md`][testing] |
| 21 | - Bundle, waterfall, rendering, or subscription cost supported by evidence: [`references/performance.md`][performance] |
| 22 | - Stable Dify runtime invariants in the named paths: [`references/dify-invariants.md`][dify-invariants] |
| 23 | - General TypeScript or styling quality not owned above: [`references/code-quality.md`][code-quality] |
| 24 | |
| 25 | Read `packages/dify-ui/README.md`, `packages/dify-ui/AGENTS.md`, `web/docs/overlay.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. |
| 26 | |
| 27 | ## Severity And Output |
| 28 | |
| 29 | - **P0**: security or privacy leak, data loss, production crash, or inaccessible critical workflow. |
| 30 | - **P1**: user-visible regression, invalid API or authorization contract, hydration failure, or broken primary interaction. |
| 31 | - **P2**: concrete maintainability, performance, test, or accessibility defect likely to cause incorrect behavior. |
| 32 | - **P3**: minor actionable cleanup; omit unless the user requested a thorough audit. |
| 33 | |
| 34 | Lead with findings ordered by severity. Include a tight file and line reference, the failing contract or reproduction path, impact, and a concrete fix direction. If there are no findings, say `No issues found.` and state any material verification gap. Do not add praise sections, speculative risks, or an unsolicited offer to implement fixes. |
| 35 | |
| 36 | [accessibility]: references/accessibility-ui.md |
| 37 | [code-quality]: references/code-quality.md |
| 38 | [component-architecture]: references/component-architecture.md |
| 39 | [data-query]: references/data-query-contracts.md |
| 40 | [dify-invariants]: references/dify-invariants.md |
| 41 | [dify-ui]: references/dify-ui.md |
| 42 | [performance]: references/performance.md |
| 43 | [testing]: references/testing.md |
Related
6 picksType
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.Jul 2026
- domain-modelingBuild and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision,…Jul 2026
- caveman-reviewUltra-compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix.Jul 2026
- codebase-designShared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a…Jul 2026
- code-reviewReview the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding…Jul 2026
- resolving-merge-conflictsUse when you need to resolve an in-progress git merge/rebase conflict.Jul 2026
