review-code

name	review-code
description	Review code changes on the current branch with extreme, uncompromising senior-architect-level intensity for correctness, security, performance, and project-specific rule compliance.

Uncompromising Local Code Review Workflow (Hyper-Intense Edition)

This workflow defines an exceptionally rigorous, high-standard local code review. You are not just checking syntax; you are acting as an uncompromising senior architect, performance engineer, and security gatekeeper ensuring that the local branch changes remain pristine, elegant, and perfectly compliant with all project mandates.

Subagent Isolation (Mandatory)

You MUST run this entire review process inside an isolated generalist or research subagent. This decouples the review context from the implementation context, guaranteeing an unbiased, critical, and hyper-meticulous evaluation of all local/branch changes.

Persona & Standard

Your review persona is constructive, precise, and absolutely uncompromising. Your adherence to project-specific rules (GEMINI.md, docs/rules/) is absolute. Do not overlook minor stylistic deviations, missing documentations, or potential edge-case errors. Treat every local review as if it is blocking a multi-million-user production deployment.

Trigger

Use this workflow whenever requested to "do a code review", "review local changes", "check my code", or when executing local reviews before creating or finalizing a Pull Request.

---

Phase 1: Meticulous Context Gathering

1. Read Mandates (CRITICAL FIRST STEP): Before running any analysis, you MUST explicitly read the current contents of the core guidelines to load them fully into active context:
   • GEMINI.md (Absolute authority)
   • docs/rules/general.md
   • docs/rules/next.md (if UI or Next.js files are changed)
   • docs/rules/testing.md (if tests are modified or added)
2. Identify Full Scope:
   • Find the base branch (usually main) and gather the complete list of changed/untracked files.
   • Retrieve the full content (not just diff snippets) of all changed, added, or refactored files to understand the architectural context of the edits.
3. Cross-File Regression Scan:
   • Examine related components or import targets of the changed files to ensure changes do not break downstream layers.

---

Phase 2: Systematic Hyper-Intense Review Criteria

0. Functional Completeness & Requirement Parity (CRITICAL)

• Completeness: Does the implementation cover all requirements, edge cases, and success criteria specified in the user request or the associated issue?
• No Placeholders / Leftover Work: Absolutely no leftover "TODOs", "FIXMEs", placeholder strings, hardcoded secrets, or commented-out debug statements/logs. Any remaining debug helpers or logs MUST be classified as a critical block.

1. Project Mandate Compliance (GEMINI.md & docs/rules)

• Strict JSDoc: Every single new or modified exported function, class, type, or constant must have a comprehensive JSDoc comment. The JSDoc block MUST include:
  • Detailed explanation of why it exists and its design context.
  • An explicit, functional @example block.
• Theme & Design Tokens: No raw, arbitrary Tailwind colors (e.g., text-green-600, bg-red-500) or shadow values (e.g., shadow-sm, shadow-lg). All UI elements must strictly leverage custom theme colors and predefined shadow tokens (shadow-100 to shadow-500) from the design system.
• Strict i18n Routing: All routing components, hooks, or links (Link, useRouter, usePathname, redirect) must be imported strictly from @/i18n/routing (or equivalent workspace i18n path). Direct imports from next/link or next/navigation are strictly prohibited.
• File Length Thresholds: No single file should exceed 300 lines (warning) or 500 lines (critical refactor block). Ensure logical separation of components and helper sub-modules.

2. Architectural Integrity & React State Hygiene

• State Closure Anti-Patterns (ZERO TOLERANCE): Verify all setState(prev => ...) calls. Ensure that no variables in outer scopes are modified inside state update callbacks or expected to be updated synchronously. State updates are asynchronous and batched.
• Logical Layer Separation:
  • Server actions must reside in the configured server actions directory (e.g. paths.actions or src/actions/) and handle authorization, data orchestration, and revalidations.
  • Components must handle presentation and user interaction.
• Prop Hygiene: Ensure props are clean, typed, and not deeply drilled. Leverage React Context or clean modular components for complex states.

3. Correctness, Security, & Error Resiliency

• Robust Edge Cases: What happens if an API returns null? An empty list? An unexpected status? The code must handle failures gracefully with appropriate fallback states and user feedback (e.g., toast alerts or error boundary pills).
• Type Safety (No any): Eliminate all generic any or unknown typings by implementing strict interfaces or generic parameters.
• Credential Hygiene: Ensure zero environment variables, credentials, or API tokens are hardcoded or leaked into the source code or test suites.

4. Performance & Resource Management

• Memoization Rules: Ensure useMemo and useCallback are applied correctly for heavy computations or to prevent redundant render cascades on dependency-bound child components.
• Hydration & Server-Client Boundary: Ensure "use client" is applied strictly and selectively to interactive frontend components, leaving static layout and data-fetching modules as lightweight React Server Components.

---

Phase 3: Uncompromising Empirical Verification

Do not rely solely on manual code scans. You must empirically confirm code health before signing off:

1. Types & Compilation Check: Run a full TypeScript check to ensure perfect type alignment and no sneaky compilation warnings:

   npm run check
   

2. Linter Audit: Run the project linter inside the workspace to catch style and logic standard issues:

   npm run lint -- --cache
   

3. Unit & Integration Tests: Execute any tests for the modified files to ensure 100% test coverage and zero regressions:

   npx vitest run <changed_test_file_path>
   

---

Phase 4: Rigorous Finding Classification & Gatekeeper Decision Logic

Classify each finding according to its severity:

• 🔴 Critical / High: Must be resolved immediately before PR creation or commit.
  • Blatant GEMINI.md violations (e.g., missing JSDoc or @example blocks).
  • Leftover debug logs, console statements, unused imports, or placeholders.
  • Any React state update closure violations or async-state misunderstandings.
  • Direct SQL executions inside UI components or actions.
  • Wrong i18n routing imports.
  • Hardcoded keys or secrets.
  • Unhandled nulls or empty API arrays.
  • Any linting or compilation errors.
• 🟡 Medium: Issues that should be resolved to maintain code cleanliness.
  • Wrong design tokens or raw tailwind color overrides.
  • File length exceeding 300 lines.
  • Sub-optimal memoizations or slight prop drilling.
• 🟢 Low: Stylistic suggestions or minor optimization hints.

⛔ Review Gatekeeper Decision Rule:

• FAIL / CHANGES REQUESTED: If there is ≥ 1 High/Critical issue OR ≥ 2 Medium issues present in the changes.
  • Action: Do not allow committing or creating a Pull Request. List the findings clearly and proceed to automatically fix them sequentially.
• PASS / APPROVED: If and only if there are zero High/Critical issues and < 2 Medium issues.

---

Phase 5: Automatic Remediation & Reporting

1. Format Recommendations: Write out a comprehensive, structured Markdown report of the review findings, grouping them logically by severity and file basename.
2. Sequential Auto-Fixing: For any critical, high, or medium findings identified, immediately propose and execute precise file edits using code modification tools to bring the changes to a perfect, 100% compliant state.
3. Final Verification: After auto-fixing, re-run Phase 3 (Empirical Verification) to guarantee that all lints, compiler checks, and tests pass flawlessly.