frontend-code-review
- Repo stars 149,183
- Author updated Live
- Author repo langflow
- Domain
- AI
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @langflow-ai · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- macOS · Linux · Windows
- Runtime requirements
- Node.js
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: frontend-code-review
description: Review frontend code (.tsx, .ts, .js files) for quality, performance, and correctness against La…
category: ai
runtime: Node.js
---
# frontend-code-review output preview
## PART A: Task fit
- Use case: 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..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to use this skill / How to use this skill / Checklist” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “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.”.
- **02** When the source has headings, the agent prioritizes “When to use this skill / How to use this skill / Checklist” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. Choose the trigger
The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Provide inputs and boundaries
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Validate with a small run
Start with a small task and check whether the result follows “When to use this skill / How to use this skill / Checklist”. Inspect diffs, logs, previews, or tests before expanding scope.
Review before delivery
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: frontend-code-review
description: Review frontend code (.tsx, .ts, .js files) for quality, performance, and correctness against La…
category: ai
source: langflow-ai/langflow
---
# frontend-code-review
## When to use
- Review frontend code (.tsx, .ts, .js files) for quality, performance, and correctness against Langflow's frontend conv…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to use this skill / How to use this skill / Checklist” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. Evidence boundary and execution chain
The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "frontend-code-review" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to use this skill / How to use this skill / Checklist
rules -> SKILL.md triggers / order / output contract
runtime -> Node.js | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}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 (
.pyfiles undersrc/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:Linereferences 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, missingis/has/can/shouldprefixes on booleans - Missing error handling or error boundaries
- Incomplete TypeScript type coverage (no
any, noas anycasts) - 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
constor immutable alternatives exist - Production files exceeding ~500 lines (red flag at 600+)
console.login 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.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review