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:

1. Pending-change review -- inspect staged or working-tree files slated for commit and flag checklist violations before submission.
2. 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:

1. 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.
2. Follow the rules defined in the Checklist to perform the review. If no checklist rule matches, apply General Review Rules as a fallback.
3. 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 Ketos 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 Ketos-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 diffs
• npm run lint (Biome linter) — zero errors
• npm 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.