Code and Logic Review

🟢 CUSTOM GENERIC SKILL

Constraints

• Security, stability, maintainability take precedence over all other concerns.
• Do not modify generated files, lock files, or externally managed configs.
• Do not infer business requirements without evidence; avoid assumptions.
• Do not report issues already covered by linters, type-checkers, or automated tools.
• Do not bloat files; place new code where it belongs architecturally.
• Ask before changing anything related to security, RLS, dependencies, or ambiguous/unclear behaviour.
• Focus on intent, data flow, architecture, and semantics over stylistic preferences.

Analysis

React

• Execute React Guidelines

Backend

• TanStack Query: Prefer useSuspenseQuery over useQuery
• Implement stateful guards for data fetching and errors (apply existing components)
• TypeScript types: Simple types preferred over heavy abstractions, generics, interfaces
• SonarQube Mark the props of the component as read-only. (TS2741) must be fully ignored.
• Imports: Hint at varying imports referring to a common base (need to combine these)
• Near-duplicated code that could be combined or co-located at least

Frontend

#### Components

• Rendering components should have thin JSX (HTML markup) and logic. Complex, verbose statements must be outsourced, abstracted, and co-located if possible (existing architecture)
• Hardcoded constants and texts are to be avoided
• At least const shall be used and moved up in function/file, where it makes sense
• Backend/server error messages can be hardcoded strings (English only)

#### Tailwind CSS

• Unused CSS classes in JSX (hint only)
• CSS class ordering (Refactor) ⭐
• Group in categories (layout, display, spacing, typography, colors, animations)
• Co-locate responsive and stateful classes (e.g., hover) to their specific categories (after the base classes)
• Dark mode classes are ordered in the same categories, but always come after all other classes
• Ignore/skip uncertainties and dynamic or concatenated classes

General

• Logical clarity and stability (e.g., filters might whitelist for certainty)
• Naming convention mismatch (esp. properties, functions, file names)
• e.g., available vs isAvailable, getUserData vs fetchUserData, …
• Clarity (e.g., pending might not be the same as loading)
• Filenames consistent with existing files and folders
• Edge cases, if any missing (even if covered by types and tests)
• Conditionals: Suspicious, unclear, ambiguous, overly complex (even if valid)
• Proper nesting, bracketing, ternary operators, early return applied
• Cache invalidation: Queries performed not invalidating or updating UI properly
• Non-standard decisions and architectures must be consistent and ideally documented

Guidelines

• No exception must harm security, stability, or maintainability of the project – These come above all else
• Do not infer business requirements without evidence (no assumptions or intent invention without clarity)
• Do not report personal stylistic preferences as findings (e.g., code formatting) – Separate from bugs
• Do not report findings that are already covered by linters, type-checkers, or other automated tools
• Do not bloat existing files with new code that would be better suited in another place
• Ignore anything linters or type-checkers would cover – Unless explicitly asked with help about specific topics

Stop + Ask for Feedback

Before implementing any changes, always ask for feedback if any of these are found:

• Security concerns — exposed secrets, missing RLS, auth bypasses, XSS sinks
• Database, Postgres RLS — mutations without or with conflicting Row Level Security policies
• 3rd party libraries, packages — updates, additions, removals, or replacements
• Syntax/compile errors — Anything obviously broken that likely breaks or harms application stability
• Uncertainty — Unclear, confusing, ambiguous; might work or not – Needs documentation at least
• Lovable specific code — Files handled externally should not be modified by users.

Final Report Format

After all steps, produce a condensed, structured summary. Assess for each finding:

• Severity: Critical | High | Medium | Low
• Own confidence: High | Medium | Low

Only report low-confidence findings when the potential impact is significant. Otherwise omit them, unless explicitly requested by the user.

Process

ALWAYS DO:

Follow a multi-step process:

1. Analyze the project (conventions, documentation, …)
2. Ask clarifying questions for urgent/ambiguous matters before starting the review

• It is OK to _not_ ask if it's trivial, obvious, non-critical

1. Review the codebase and other related files
2. Produce the final report

Legend

• ⭐ = With explicit user request only; never run/modify code without user request.