Tips & Best Practices

Do NOT use fake paths, unless explicitly asked to do it.

Ensures all file/import paths in generated code actually exist

Do NOT keep legacy or backwards compatibility code, I don't want a mess.

Removes backwards-compat cruft so the codebase stays clean

ALWAYS think like Uncle Bob with a high level of scrutiny for clean code.

Enforces readable, well-structured code following Clean Code principles

ALWAYS check for the YAGNI principal (You Aren't Gonna Need It). Start simple and add complexity only when you have concrete requirements for it. Don't build for imaginary future needs.

Prevents over-engineering by only building what's needed now

Apply Uncle Bob Clean Code: use descriptive names that reveal intent, functions under 20 lines doing one thing, no duplication, Boy Scout Rule to refactor as you go.

Produces small, readable functions with clear names and no copy-paste

Write SOLID-compliant code: Single Responsibility per class/component, Open-Closed for extension, Liskov Substitution, small segregated Interfaces, Dependency Inversion on abstractions.

Makes components easy to extend and swap without breaking others

Follow KISS and DRY: Keep it simple stupid, eliminate repetition, avoid cleverness or deep nesting, prefer clarity over conciseness.

Keeps code simple with no repeated logic or unnecessary complexity

Name everything meaningfully: variables as full sentences (e.g., "shouldSendWelcomeEmail"), booleans as conditions (e.g., "isUserEligibleForDiscount"), no magic numbers—use named constants.

Replaces cryptic variable names and magic numbers with self-documenting code

Structure for readability: small functions with 0-3 args, one level of abstraction per function, error handling separate from happy path, classes under 100 lines.

Limits function size and nesting so code reads top-to-bottom

Make it testable: pure functions where possible, dependency injection, no globals, extract constants, favor composition over inheritance.

Structures code so unit tests are easy to write and maintain

Implement OWASP Top 10 security: validate/sanitize all inputs with strict types, prepared statements for Supabase queries to prevent SQL injection, output encoding against XSS.

Guards against the most common web vulnerabilities like XSS and SQL injection

Apply least privilege: use role-based access (admin/user/guest), never hardcode secrets (use Supabase env vars), JWT auth with short expiry and refresh tokens.

Restricts access so users only see/do what they're allowed to

Secure defaults: HTTPS enforced, CORS restricted to your domains, rate limiting on APIs, secure cookies (HttpOnly, Secure, SameSite=Strict), no client-side secrets.

Locks down cookies, CORS, and transport so nothing leaks by default

Handle errors securely: generic messages only (no stack traces), log details server-side, graceful fallbacks, validate auth on every protected route.

Hides internal details from users while logging them for debugging

Dependency hygiene: scan for vulnerabilities, use latest audited packages, SBOM for third-parties like Stripe/SumUp, no eval/exec.

Catches vulnerable packages before they ship to production

Data protection for EU: GDPR-compliant—minimize stored data, user consent flows, right to delete, encrypt PII at rest (Supabase), audit logs for changes.

Adds consent, data deletion, and encryption for EU compliance

Build a clean, secure [app name]: Uncle Bob principles + OWASP. Single-responsibility components, input validation everywhere, Supabase row-level security, Stripe/SumUp sandbox testing.

Full scaffold combining clean architecture with security best practices

Refactor this to Clean Code standards with high scrutiny: break large functions, descriptive names, SOLID, add input sanitization, auth guards, error boundaries.

Transforms messy code into maintainable, secure modules

Generate a secure loyalty system: meaningful names, small pure functions, validate all user inputs, RBAC for points redemption, encrypted Supabase storage.

Builds a loyalty feature with proper access control and data protection

Design for maintainability and security: YAGNI (no unused features), single source of truth (one DB query per data need), parameterized queries, peer-review style comments.

Keeps the codebase lean, consistent, and injection-proof

Enterprise-grade restaurant menu app: Clean Code (KISS/DRY/SOLID), secure auth (MFA optional), input validation on forms, rate limits, Supabase RLS policies.

Production-ready app template with enterprise security standards

Optimize for SEO and security: semantic HTML, fast load (code splitting), CSP headers, noinline scripts blocked, descriptive alt texts, sanitized URLs.

Boosts search rankings while hardening against common attacks

Do not write new features until you have traced the current bug to the relevant files and explained the root cause.

For debugging — forces root-cause analysis before any code changes

Do not create or rename tables/fields until you confirm the existing data model and all usages of it.

For schema work — prevents breaking changes to the data layer

Do not redesign the full interface when the request only requires editing one flow or component.

For UI work — keeps changes scoped to the specific component being touched

If a refactor is needed, explain why a localized patch is insufficient before proceeding.

For refactors — requires justification before broad code reshaping