Prompts

These prompts help you review and improve your codebase. Copy them directly or adapt them to your needs.

Simplify Review (Essential)

Use this prompt to identify unnecessary complexity and opportunities for simplification.

Can you please review this codebase?
I want to know:

- Is there anyway that we can simplify / things that are unnecessary?
- Is there any code that sticks out as needing refactored?
  - Does anything need split up into smaller functions?
  - Were there any shortcuts taken or hardcoded assumptions that we never came back to?
  - Can anything be simplified?

Our guiding philosophy is making code as simple as possible, avoiding premature optimization. Some things we don't consider a premature optimization:

- Optimistic updates by using TanstackDB and that data is properly and securely stored to our database.
- Normalized database schemas to make future migrations and iteration cleaner.
- Service / Repository pattern is desired even if its a bit overkill so that it is more natural to implement more complicated features in the future.
- Defense in depth and ensuring that authentication and authorization is happening.

Other patterns we consider acceptable:

- Hard coding llm related info such as models, reasoning effort and prompts is fine.

Don't make any changes, just write a report on the above questions.

Security Review

Review authentication and authorization across all API routes and backend services.

Service/Repository Authorization Pattern

We use defense-in-depth with two layers:

Layer	Responsibility	On Failure
Service	Verify ownership BEFORE mutations	Throw clear error
Repository	Include `userId` in WHERE clauses	Return null/empty (silent)

Services handle authorization and can call multiple repositories. Repositories are pure data access - no auth checks, no cross-repo imports.

This keeps repositories simple and testable while ensuring authorization can’t be accidentally bypassed (the userId in WHERE clauses acts as a safety net).

Review authentication and authorization across all API routes and backend services.

Checklist:

- [ ] Services verify ownership before mutations
- [ ] Repositories include `userId` in WHERE clauses
- [ ] Repositories do NOT import other repositories
- [ ] Server functions extract userId from session (never trust client)
- [ ] No hardcoded secrets or API keys
- [ ] Input validation on user-provided data

Service/Repository Pattern Review

Review adherence to the Service/Repository pattern.

Expected Structure

serverFunctions/ → server/services/ → server/repositories/

Rules

Layer	Must Do	Must NOT Do
Server Functions	Extract userId from session, validate input, call services	Direct DB access, trust client for userId
Services	Verify ownership before mutations, call repositories	Import other services, direct DB access
Repositories	Include userId in WHERE clauses	Import other repositories, auth logic

Review this codebase for adherence to our Service/Repository pattern.

Checklist:

- [ ] 3-layer separation exists for each domain
- [ ] Services verify ownership before mutations
- [ ] Repositories include userId in WHERE clauses
- [ ] Repositories do NOT import other repositories
- [ ] Server functions extract userId from session (never trust client)

Improve UI from Screenshot

Use this prompt when you want to improve your UI based on a screenshot.

Please review this screenshot of my app and suggest UI improvements.

Focus on:

- Visual hierarchy and spacing
- Consistency with the rest of the app
- Mobile responsiveness
- Accessibility concerns
- Any obvious UX issues

Don't make any changes yet, just provide recommendations.

Advanced

TanStack DB Patterns Review

Review proper TanStack DB usage and ensure you’re not using normal react-query or other data fetching patterns when possible.

Documentation

File Structure

Location	Purpose
`client/tanstack-db/*Collection.ts`	One collection per entity
`client/tanstack-db/index.ts`	Re-exports all collections
`client/tanstack-db/queryClient.ts`	QueryClient with gcTime/staleTime
`client/tanstack-db/persister.ts`	localStorage persister for offline
`client/actions/*.ts`	Optimistic actions via `createOptimisticAction`

Anti-Patterns

Don’t	Do Instead
Use `useQuery`/`useMutation` from react-query	Use `useLiveQuery` and collections
Coordinate multiple optimistic mutations in component code	Use `createOptimisticAction`
Store nested entities in collections	Flat data, join at query time
Generate IDs inside `onMutate` or `mutationFn`	Pre-generate IDs in helper function
Skip refetch after `mutationFn`	Always `await collection.utils.refetch()`

Review this codebase for proper TanStack DB usage.

Checklist:

Collections:

- [ ] Wrapped with `lazyInitForWorkers()` so it works on Cloudflare

Optimistic Actions:

- [ ] Use `createOptimisticAction` for complex mutations
- [ ] Pre-generate IDs with `nanoid()` before action - same ID used in `onMutate` and `mutationFn`
- [ ] `onMutate` updates all affected collections synchronously
- [ ] `mutationFn` calls server then refetches via `collection.utils.refetch()`

Non-Optimistic Mutations:

- When the client lacks data needed for optimistic updates (e.g., adding a friend by email where the server looks up the user), call the server function directly then refetch.

Database Schema Review

Review or create database schemas based on normalization principles.

Guiding Principles

Maximal normalization - everything should be normalized as much as possible. This avoids keeping tables in sync or having optional columns that only apply to certain record types. Down the line, this makes migrations easier and prevents bugs due to faulty assumptions.
Database-level enforcement - as many assumptions as possible should be enforced at the database layer via the schema / unique constraints.
Proper Drizzle relations - make sure you properly use drizzle relations.

Documentation

Please review or create the database schema based on the below principles.

Ensure that you're using drizzle as designed:

- https://orm.drizzle.team/docs/relations
- https://orm.drizzle.team/docs/indexes-constraints

Guiding Principles:

- Maximal normalization - everything should be normalized as much as possible to avoid keeping tables in sync or having optional columns that only apply to certain record types.
- As many assumptions as possible should be enforced at the database layer via the schema / unique constraints.
- Make sure you properly use drizzle relations.

Before you design:

- Ask clarifying questions about use cases down the line. We don't want to build out support in the schema for any future features, but we want to make sure our schema is designed intelligently so that it is easy to migrate to support new features later.