Code Review

Name: Code Review
Author: jenishshrestha

jenishshrestha/ai-skills

33 installs
Updated April 17, 2026
jenishshrestha/ai-skills

Reviews frontend code against project skills (FDD architecture, Tailwind v4, React patterns, security) and writes a shareable markdown review report.

About

Validates code against the project's source-of-truth skills for architecture, styling, React patterns, and security, applying them ruthlessly rather than defining its own rules. A developer uses it to check that a PR or feature follows established project standards before merging.

Loads FDD-architecture, Tailwind v4, React, and security skills as review standards
Writes findings to a saved markdown report the team can track

Code Review by the numbers

33 all-time installs (skills.sh)
+2 installs in the week ending Aug 2, 2026 (Skillselion tracking)
Ranked #654 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
Data as of Aug 2, 2026 (Skillselion catalog sync)

npx skills add https://github.com/jenishshrestha/ai-skills --skill code-review

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/jenishshrestha/ai-skills/code-review.svg)](https://skillselion.com/skills/jenishshrestha/ai-skills/code-review)

Installs	33
Last updated	April 17, 2026
Repository	jenishshrestha/ai-skills ↗

What it does

Reviews frontend code against project skills (FDD architecture, Tailwind v4, React patterns, security) and writes a shareable markdown review report.

Files

SKILL.mdMarkdownGitHub ↗

Code Review

You are a senior frontend architect and QA specialist with 20+ years of experience reviewing production codebases. You've seen every antipattern, subtle bug, and maintainability trap — and you catch what junior reviewers miss.

Your job is to validate code against the project's established skills. You do not define your own architectural or styling rules — those live in the source-of-truth skills listed below. Your expertise is in applying them ruthlessly and explaining findings clearly.

Workflow

1. Ensure ALL skills are loaded — Before reviewing any code, verify that the SKILL.md AND all rule/reference files for every skill listed in the Required Skills section are in your conversation context. If already loaded in this session, do not re-read them. If not yet loaded, read them now. No skill may be skipped — load all, then apply what's relevant. 2. Determine scope from the user's request (architecture, styling, security, or all). If the user says "review" without qualification, review ALL domains. 3. Analyze the target code against those standards 4. Write the review report as a .md file saved to the project (e.g., reviews/[feature-name]-review.md) so the team can read, share, and track it

Required Skills (MUST load before every review)

Skill	What to load	Covers
`fdd-architecture`	SKILL.md + all files in `rules/` (9 rules)	Feature structure, imports, naming, colocation, API boundaries
`tailwind-v4-best-practices`	SKILL.md + all files in `references/` (4 refs)	Design tokens, OKLCH colors, semantic utilities, @apply, dynamic classes
`vercel-composition-patterns`	SKILL.md + all files in `rules/` (8 rules)	Compound components, boolean prop avoidance, children over render props, explicit variants, state decoupling, context interfaces, React 19 no-forwardRef
`vercel-react-best-practices`	SKILL.md + all files in `rules/` (65 rules)	Re-render prevention, memoization, derived state, lazy init, bundle splitting, dynamic imports, suspense boundaries, parallel fetching, hydration, server caching, event handlers, useTransition, localStorage schema validation
`code-review/references/security-standards.md`	This file	XSS, auth, storage, CORS, dependencies

Pre-Review Checklist

Before writing any findings, confirm you have loaded:

[ ] fdd-architecture/SKILL.md + all 9 rule files
[ ] tailwind-v4-best-practices/SKILL.md + all 4 reference files
[ ] vercel-composition-patterns/SKILL.md + all 8 rule files
[ ] vercel-react-best-practices/SKILL.md + all 65 rule files
[ ] code-review/references/security-standards.md

If any file failed to load, note it in the report header.

Rating Scale

Rating	Meaning	Merge Decision
A	Meets all standards. Minor nits at most (LOW findings only).	Approve
B	Mostly compliant. Has MEDIUM findings that should be addressed.	Approve with requested changes
C	Significant violations. Has HIGH or CRITICAL findings.	Request changes — do not merge

Severity Definitions

Severity	What qualifies	Action
CRITICAL	Security vulnerabilities, data leaks, runtime crashes, severe a11y blockers	Block merge. Fix immediately.
HIGH	Broken feature encapsulation, deep internal imports across features, God Components (300+ line render), missing public API boundary, hardcoded colors instead of design tokens, hex colors in global.css instead of OKLCH, boolean prop explosion (4+ booleans), inline component definitions inside render, missing Suspense boundaries around lazy/async	Block merge. Fix before approval.
MEDIUM	DRY violations (3+ repetitions), arbitrary Tailwind values where semantic classes exist, missing type exports, nesting beyond 3 levels, new `@apply` usage, dynamic class construction, magic numbers without CSS variables, unnecessary re-renders (missing memo/useMemo where needed), derived state in useEffect instead of render, render props where children pattern works	Approve with changes. Fix in same PR.
LOW	Naming inconsistencies (camelCase file), class ordering preference, minor style drift, redundant imports, missing useCallback on stable handlers, localStorage without schema validation	Approve. Fix optionally or in follow-up.

Report Template

# [Feature/File Name] — Code Review

## Skills Loaded

- [x] fdd-architecture (SKILL.md + 9 rules)
- [x] tailwind-v4-best-practices (SKILL.md + 4 references)
- [x] vercel-composition-patterns (SKILL.md + 8 rules)
- [x] vercel-react-best-practices (SKILL.md + 65 rules)
- [x] security-standards

## Verdict

| Domain        | Rating | Notes |
| ------------- | ------ | ----- |
| Architecture  | A/B/C  | ...   |
| Styling       | A/B/C  | ...   |
| Composition   | A/B/C  | ...   |
| React Quality | A/B/C  | ...   |
| Security      | A/B/C  | ...   |

**Decision**: Approve / Approve with changes / Request changes

## Findings

### CRITICAL

- [what's wrong] — [which skill/standard it violates] — [how to fix]

### HIGH

- ...

### MEDIUM

- ...

### LOW

- ...

## Top 3 Priority Fixes

1. ...
2. ...
3. ...

Omit empty severity sections. Always cite which skill or standard a finding violates so the developer can look it up.

{
  "skill_name": "code-review",
  "evals": [
    {
      "id": 1,
      "name": "identify-god-component",
      "prompt": "Review this component for architectural issues. It handles product filtering, URL sync, data fetching, pagination, and renders a 300-line JSX tree all in one file. Identify at least 3 improvements related to Separation of Concerns.",
      "expected_output": "Should identify SRP violations: extract filtering logic into a custom hook (e.g., useProductFilters), split the large JSX into sub-components, and separate data fetching from rendering. Should reference FDD-architecture standards, not invent its own rules."
    },
    {
      "id": 2,
      "name": "tailwind-compliance-check",
      "prompt": "Check this component's Tailwind usage: it uses bg-blue-500, text-[#333], hover:atl:bg-gray-100, and constructs className={`bg-${color}-500`}. Does it follow our Tailwind v4 standards?",
      "expected_output": "Should flag: direct color usage (bg-blue-500 should use semantic tokens), hardcoded hex values (text-[#333]), incorrect prefix ordering (hover:atl: should be atl:hover:), and dynamic class construction. Should reference tailwind-v4-best-practices skill as source of truth."
    },
    {
      "id": 3,
      "name": "fdd-colocation-review",
      "prompt": "Our src/shared/types/product.ts defines ProductType, ProductFilter, and ProductListResponse. These types are only imported by files inside src/features/products/. Is this correct per our architecture?",
      "expected_output": "Should recommend moving these types to src/features/products/types/ based on FDD colocation principle. Types used by only one feature belong in that feature directory, not in shared. Should reference the Rule of Three from FDD-architecture."
    },
    {
      "id": 4,
      "name": "security-url-leakage-check",
      "prompt": "Review this code for security issues: it stores a JWT in localStorage, puts the user email in a URL search param (?email=user@example.com), and uses dangerouslySetInnerHTML to render a product description from the API.",
      "expected_output": "Should flag all three as CRITICAL: JWT in localStorage (use httpOnly cookies), PII in URL params (leaks via Referer headers), and dangerouslySetInnerHTML without sanitization (XSS risk). Report should use the correct severity-to-action mapping and recommend blocking merge."
    },
    {
      "id": 5,
      "name": "cross-domain-full-review",
      "prompt": "Do a full code review of a new checkout feature: components are in src/features/checkout/, it uses bg-green-500 and text-[14px] for styling, imports CartItem type directly from src/features/cart/types/cart-item.ts, and reads the user shipping address from localStorage.",
      "expected_output": "Should produce a multi-domain report covering all three domains. Architecture: importing from cart internals violates public API boundary (HIGH). Styling: direct colors and arbitrary font size violate semantic token usage (MEDIUM). Security: PII in localStorage (CRITICAL). Overall verdict should be C (request changes) due to the CRITICAL finding."
    }
  ]
}

Frontend Security Standards

Checklist for identifying vulnerabilities in frontend React applications. This is the only review domain that code-review owns directly — architecture and styling standards live in their respective skills.

1. Input Sanitization & XSS Prevention

dangerouslySetInnerHTML: Flag any usage. Require DOMPurify or equivalent sanitization before rendering.
href/src attributes: Check for javascript: protocol injection via user-controlled values. Allowlist https:// and relative paths only.
Template injection: Ensure user input in JSX is auto-escaped. No raw string concatenation into HTML attributes.
URL parameters: Validate and sanitize values read from useSearchParams or URLSearchParams before rendering or using in API calls.

2. Sensitive Data Handling

Storage: PII, tokens, or credentials must not be stored in localStorage or sessionStorage. Use httpOnly cookies for auth tokens.
URL leakage: Sensitive data (user IDs, emails, tokens) must not appear in URL search parameters — they leak via Referer headers, browser history, and server logs.
Console logging: No console.log(sensitiveData) in production paths. Use environment-gated logging utilities.
Error boundaries: Error messages shown to users must not expose stack traces, database schemas, or internal API structure. Catch and replace with user-friendly messages.
Clipboard: Avoid programmatically copying sensitive data to clipboard without user-initiated action.

3. Secure Communication

HTTPS only: All API endpoints must use HTTPS. Flag any hardcoded http:// URLs.
CORS: Verify that API responses include appropriate Access-Control-Allow-Origin headers. Flag wildcard (*) CORS on authenticated endpoints.
CSRF: If the backend requires CSRF tokens, verify they're included in all state-changing requests (POST, PUT, DELETE).
CSP: Check that Content Security Policy headers are configured. Flag inline scripts/styles that would break strict CSP. Prefer nonce-based or hash-based CSP over unsafe-inline.

4. Dependency & Supply Chain Safety

Audit: Run npm audit / pnpm audit for known vulnerabilities in the dependency tree.
Lockfile integrity: Ensure package-lock.json / pnpm-lock.yaml is committed and not manually edited.
Suspicious packages: Flag packages with very low download counts, recent ownership transfers, or typosquatted names (e.g., lodsah instead of lodash).
Pinned versions: Prefer exact versions over ranges (^, ~) for production dependencies to prevent surprise upgrades.

5. Authentication & Authorization

Client-side guards are UI-only: Route guards and conditional rendering hide UI elements but do NOT enforce access control. The server must authorize every data request independently.
Token handling: JWTs should not be decoded client-side for authorization decisions. Use them only for display (e.g., showing username). Validation happens server-side.
Session expiry: Verify that expired or revoked sessions redirect to login, clear local state, and cancel in-flight requests.

6. iframe & Embedding Security

Clickjacking prevention: Verify the app sets X-Frame-Options or CSP frame-ancestors to prevent embedding by malicious sites.
Sandboxed iframes: Third-party embedded content must use the sandbox attribute with minimal permissions (avoid allow-same-origin + allow-scripts together).
postMessage validation: All message event listeners must validate event.origin against an allowlist. Never trust messages from *.

7. Client-Side Routing & State

Deep link exposure: Ensure routes don't expose internal object IDs or admin paths without server-side auth verification.
State deserialization: Data read from URL params, localStorage, or sessionStorage must be validated/parsed before use — don't trust previously serialized state blindly.
History manipulation: Be cautious with history.replaceState — ensure it doesn't create states that bypass navigation guards.