frontend-code-review Skill

1---2name: frontend-code-review3description: "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."4---5 6# Frontend Code Review7 8## When to use this skill9 10Use 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:11 121. **Pending-change review** -- inspect staged or working-tree files slated for commit and flag checklist violations before submission.132. **File-targeted review** -- review the specific file(s) the user names and report the relevant checklist findings.14 15Do NOT use this skill when:16 17- The request is about backend code (`.py` files under `src/backend/`).18- The user is not asking for a review/analysis/improvement of frontend code.19- The scope is outside `src/frontend/` (unless the user explicitly asks to review frontend-related changes elsewhere).20 21## How to use this skill22 23Follow these steps when using this skill:24 251. **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.262. Follow the rules defined in the **Checklist** to perform the review. If no checklist rule matches, apply **General Review Rules** as a fallback.273. Compose the final output strictly following the **Required Output Format**.28 29Notes when using this skill:30 31- Always include actionable fixes or suggestions (including possible code snippets).32- Use `File:Line` references when a file path and line numbers are available; otherwise, use the most specific identifier you can.33- 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.34 35## Checklist36 37- **Code quality**: For any reviewed file, follow [references/code-quality.md](references/code-quality.md) to check styling conventions, TypeScript usage, Biome compliance, and component patterns.38- **Performance**: If the review scope involves React components, hooks, Zustand stores, React Query usage, or @xyflow/react node rendering, follow [references/performance.md](references/performance.md) to check for re-render issues, memoization, and data flow patterns.39- **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](references/business-logic.md) to check for Langflow-specific correctness.40- **i18n**: If the diff adds or changes user-facing text (labels, buttons, tooltips, modals, toasts, errors, placeholders, aria-labels), follow the [frontend-i18n skill](../frontend-i18n/SKILL.md): no hardcoded UI strings — everything through `t(...)` — and every new key present in **all** locale files (`src/frontend/src/locales/*.json`).41 42## General Review Rules43 44### 1. Security Review45 46Check for:47- XSS vulnerabilities (dangerouslySetInnerHTML, unescaped user input)48- Sensitive data exposure in client-side code49- Insecure direct object references in API calls50- Hardcoded secrets, tokens, or API keys51 52### 2. Accessibility Review53 54Check for:55- Missing aria labels on interactive elements56- Keyboard navigation support57- Proper use of semantic HTML elements58- Color contrast issues in custom styling59 60### 3. Code Quality Review61 62Check for:63- Code duplication (DRY violations — extract at 3+ identical usages)64- Functions/components doing too much (SRP violations — if you need "and" to describe it, split it)65- Deep nesting or complex conditionals (prefer early returns and guard clauses)66- Magic numbers/strings without named constants67- Poor naming: generic names (`data`, `result`, `temp`), missing verb prefixes on functions, missing `is`/`has`/`can`/`should` prefixes on booleans68- Missing error handling or error boundaries69- Incomplete TypeScript type coverage (no `any`, no `as any` casts)70- Comments that explain WHAT instead of WHY71- Commented-out code (use version control)72- Boolean parameters that switch component behavior (use two components instead)73- Mutable patterns where `const` or immutable alternatives exist74- Production files exceeding ~500 lines (red flag at 600+)75- `console.log` in production code (Biome flags this)76 77### 4. Testing Impact Review78 79Check for:80- Changes to data-testid attributes that may break E2E tests81- Modified component interfaces that require test updates82- New interactive elements missing data-testid attributes83 84### 5. Pre-Commit Verification85 86For pending-change reviews, verify:87- `npm run format` (Biome formatter) — zero diffs88- `npm run lint` (Biome linter) — zero errors89- `npm test` (Jest) — zero failures90 91## Required Output Format92 93When this skill is invoked, the response must exactly follow one of the two templates:94 95### Template A (any findings)96 97```markdown98# Code Review99 100Found <N> urgent issues that need to be fixed:101 102## 1. <brief description of issue>103 104FilePath: <path> line <line>105<relevant code snippet or pointer>106 107 108### Suggested fix109 110<brief description of suggested fix with code example>111 112---113 114... (repeat for each urgent issue) ...115 116Found <M> suggestions for improvement:117 118## 1. <brief description of suggestion>119 120FilePath: <path> line <line>121<relevant code snippet or pointer>122 123 124### Suggested fix125 126<brief description of suggested fix with code example>127 128---129 130... (repeat for each suggestion) ...131```132 133- If there are no urgent issues, omit that section. If there are no suggestions, omit that section.134- If the issue count exceeds 10, summarize as "10+ urgent issues" or "10+ suggestions" and output only the first 10 items.135- Do not compress the blank lines between sections; keep them as-is for readability.136- 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?"137 138### Template B (no issues)139 140```markdown141## Code Review142 143No issues found.144```145