code-improvement-frameworks

Reviews code using named Fowler, Google, React, Next.js, and TypeScript quality frameworks.

11|Updated Mar 20, 2026
One-click install
npx skills add https://github.com/qa-aman/next-leap-claude-code --skill code-improvement-frameworks-qa-aman
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-improvement-frameworks
Source: https://github.com/qa-aman/next-leap-claude-code/tree/main/.claude/skills/code-improvement-frameworks
Command: npx skills add https://github.com/qa-aman/next-leap-claude-code --skill code-improvement-frameworks-qa-aman

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Vague code review feedback like "this feels messy" gives authors nothing to act on or look up. This Skill turns subjective impressions into named, citable findings by mapping observations to Martin Fowler's code smells and refactoring catalog, Google's code review standard, and official React, Next.js, and TypeScript guidance. ## Core Features & Use Cases - Named diagnoses and fixes: Maps observations to exact smell names (Long Function, Feature Envy) paired with catalog refactorings (Extract Function, Introduce Parameter Object) so every finding is traceable to a first-party source. - Bounded severity discipline: Applies Google's Major/Minor/Nit scale with the Nit: prefix convention, so reviews distinguish blocking issues from polish and avoid noise. - Framework-specific checks: Covers the thirteen React useEffect anti-patterns, Next.js Server/Client Component boundary rules, and TypeScript do's and don'ts for App Router codebases. - Use Case: When reviewing a Next.js pull request, load this Skill to produce structured findings with file locations, current and suggested code, and citations like "Fowler, Long Parameter List -> Introduce Parameter Object" that authors can verify independently. ## Quick Start Review the code in 15-prototype and produce a findings report using named code smells, refactorings, and severity levels.

Frequently Asked Questions about code-improvement-frameworks

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write actionable code review comments?▼

Name the code smell, then the refactoring that fixes it, then cite the source, for example "Fowler, Long Function -> Extract Function". Include the file location, the current code, the suggested code, and a one-line rationale so the author can act without follow-up questions.

What code smells should I look for when reviewing React code?▼

The most common real defects are unnecessary useEffect hooks, such as transforming data during render or updating state from props. Also check whether 'use client' boundaries pull large import graphs into the browser bundle instead of being pushed down to specific interactive components.

How does Google's code review standard decide what feedback matters?▼

Google's bar is code health, not perfection: approve changes that improve maintainability even if not flawless. Findings are ranked Major for design and correctness issues, Minor for real but non-blocking improvements, and Nit for style preferences marked with the Nit: prefix.

When should I not flag a performance issue in a code review?▼

Only state a performance finding when you can point at a concrete mechanism, such as a large client bundle, an Effect chain causing extra renders, or an expensive unmemoized computation. Restructuring code for speed without measurement is treated as a guess, not a finding.

Does this review approach cover security vulnerabilities?▼

No, security and correctness bug hunting is deliberately out of scope and belongs to a separate review using sources like OWASP. If a bug is spotted incidentally it should be flagged and handed off rather than half-addressed in a code quality review.