| name | frontend-code-review |
| description | Review frontend code (.tsx, .ts, .js files) for quality, performance, and correctness against Langflow's frontend conventions. Supports pending-change reviews and file-targeted reviews. |
Frontend Code Review
When to use this skill
Use this skill whenever the user asks to review, analyze, or improve frontend code (.tsx, .ts, .js files) under the src/frontend/ directory. Supports the following review modes:
- Pending-change review -- inspect staged or working-tree files slated for commit and flag checklist violations before submission.
- File-targeted review -- review the specific file(s) the user names and report the relevant checklist findings.
Do NOT use this skill when:
- The request is about backend code (
.py files under src/backend/).
- The user is not asking for a review/analysis/improvement of frontend code.
- The scope is outside
src/frontend/ (unless the user explicitly asks to review frontend-related changes elsewhere).
How to use this skill
Follow these steps when using this skill:
- Identify the review mode (pending-change vs file-targeted) based on the user's input. Keep the scope tight: review only what the user provided or explicitly referenced.
- Follow the rules defined in the Checklist to perform the review. If no checklist rule matches, apply General Review Rules as a fallback.
- Compose the final output strictly following the Required Output Format.
Notes when using this skill:
- Always include actionable fixes or suggestions (including possible code snippets).
- Use
File:Line references when a file path and line numbers are available; otherwise, use the most specific identifier you can.
- The Langflow frontend uses React 19, TypeScript 5.4, Vite 7 with SWC, Zustand for state management, TanStack React Query for server state, @xyflow/react v12 for graph visualization, Radix UI + shadcn-ui components, Tailwind CSS v3, and Biome for linting/formatting.
Checklist
- Code quality: For any reviewed file, follow references/code-quality.md to check styling conventions, TypeScript usage, Biome compliance, and component patterns.
- Performance: If the review scope involves React components, hooks, Zustand stores, React Query usage, or @xyflow/react node rendering, follow references/performance.md to check for re-render issues, memoization, and data flow patterns.
- Business logic: If the review scope involves custom nodes (GenericNode), flow state, API calls, the component system, global variables, or the inspection panel, follow references/business-logic.md to check for Langflow-specific correctness.
General Review Rules
1. Security Review
Check for:
- XSS vulnerabilities (dangerouslySetInnerHTML, unescaped user input)
- Sensitive data exposure in client-side code
- Insecure direct object references in API calls
- Hardcoded secrets, tokens, or API keys
2. Accessibility Review
Check for:
- Missing aria labels on interactive elements
- Keyboard navigation support
- Proper use of semantic HTML elements
- Color contrast issues in custom styling
3. Code Quality Review
Check for:
- Code duplication (DRY violations — extract at 3+ identical usages)
- Functions/components doing too much (SRP violations — if you need "and" to describe it, split it)
- Deep nesting or complex conditionals (prefer early returns and guard clauses)
- Magic numbers/strings without named constants
- Poor naming: generic names (
data, result, temp), missing verb prefixes on functions, missing is/has/can/should prefixes on booleans
- Missing error handling or error boundaries
- Incomplete TypeScript type coverage (no
any, no as any casts)
- Comments that explain WHAT instead of WHY
- Commented-out code (use version control)
- Boolean parameters that switch component behavior (use two components instead)
- Mutable patterns where
const or immutable alternatives exist
- Production files exceeding ~500 lines (red flag at 600+)
console.log in production code (Biome flags this)
4. Testing Impact Review
Check for:
- Changes to data-testid attributes that may break E2E tests
- Modified component interfaces that require test updates
- New interactive elements missing data-testid attributes
5. Pre-Commit Verification
For pending-change reviews, verify:
npm run format (Biome formatter) — zero diffsnpm run lint (Biome linter) — zero errorsnpm test (Jest) — zero failures
Required Output Format
When this skill is invoked, the response must exactly follow one of the two templates:
Template A (any findings)
# Code Review
Found <N> urgent issues that need to be fixed:
## 1. <brief description of issue>
FilePath: <path> line <line>
<relevant code snippet or pointer>
### Suggested fix
<brief description of suggested fix with code example>
---
... (repeat for each urgent issue) ...
Found <M> suggestions for improvement:
## 1. <brief description of suggestion>
FilePath: <path> line <line>
<relevant code snippet or pointer>
### Suggested fix
<brief description of suggested fix with code example>
---
... (repeat for each suggestion) ...
- If there are no urgent issues, omit that section. If there are no suggestions, omit that section.
- If the issue count exceeds 10, summarize as "10+ urgent issues" or "10+ suggestions" and output only the first 10 items.
- Do not compress the blank lines between sections; keep them as-is for readability.
- If Template A is used (there are issues to fix) and at least one issue requires code changes, append a brief follow-up question after the structured output asking whether the user wants the suggested fixes applied. For example: "Would you like me to apply the suggested fixes to address these issues?"
Template B (no issues)
## Code Review
No issues found.
