Frontend Code Review

by langgenius2b65f0e89309No license157K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated today

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.

Instructions onlySoftware Development
AI-generated overview

Reviews frontend code under web/ or packages/dify-ui/ for defects and contract violations, reporting severity-ranked findings.

What it does
This skill performs a review or audit of frontend code in the web/ and packages/dify-ui/ paths, covering pending changes, specific files, or pasted diffs. It establishes scope, reads changed lines and relevant AGENTS.md files, and routes to reference packs on accessibility, Dify UI, component architecture, data and query contracts, testing, performance, runtime invariants, and code quality. It produces findings ordered by severity (P0 to P3), each with a file and line reference, the observed failure or project rule, and a concrete fix direction. It is instructions only and ships no scripts.
When to use it
Use it when the user explicitly asks for a review or audit of frontend code under web/ or packages/dify-ui/. It supports pending-change, file-focused, and pasted-diff reviews. It is not intended for implementation-only requests, diagnosis without review intent, or backend-only code.
Requirements
No scripts or packages are required beyond the agent. The skill reads bundled reference files and may consult project files such as packages/dify-ui/README.md, AGENTS.md, docs/overlays.md, and web/docs/test.md, plus current official documentation when local references do not settle a behavior.

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 [blocked]
  • Dify UI imports, Base UI wrappers, overlays, tokens, or primitive contracts: references/dify-ui.md [blocked]
  • Component ownership, props, state, Effects, navigation, or module boundaries: references/component-architecture.md [blocked]
  • Generated clients, Query, mutations, auth, SSR, URL state, or persistence: references/data-query-contracts.md [blocked]
  • Test files or a concrete missing-regression-test finding: references/testing.md [blocked]
  • Bundle, waterfall, rendering, or subscription cost supported by evidence: references/performance.md [blocked]
  • Stable Dify runtime invariants in the named paths: references/dify-invariants.md [blocked]
  • General TypeScript or styling quality not owned above: references/code-quality.md [blocked]

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.

Source and attribution

Source:langgenius/difyin.agents/skills/frontend-code-reviewat commit2b65f0e

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal