Prompt library 💬

I'm starting a new project called QueueLess: a pre-order and loyalty web app for cafés. It starts with one café and becomes a multi-café SaaS where each café pays a monthly plan.

Stack: Next.js (App Router, TypeScript) + Tailwind + shadcn/ui, Supabase (Postgres, Auth, RLS, Storage, Realtime), Stripe, Resend for email, hosted on Vercel.

The repo is empty. Before doing anything, give me a short numbered plan for:
1. Creating the Next.js app with Tailwind and TypeScript
2. Setting up shadcn/ui
3. Installing the Supabase client libraries for server and browser use
4. A .env.local.example file listing every environment variable we'll need, marked "server only" or "safe for browser"
5. A CLAUDE.md file with project rules
Don't run anything yet. Wait for my OK.

Create CLAUDE.md for QueueLess with these rules, in short bullet points:

- Stack: Next.js App Router, TypeScript, Tailwind, shadcn/ui, Supabase, Stripe, Resend, Vercel.
- Every table has Row Level Security turned on, with policies, in the same migration that creates it.
- All database changes go in Supabase migration files. Never edit the database by hand.
- Secret keys (service role, Stripe secret, Stripe webhook secret, Resend) are only used in server code and never get a NEXT_PUBLIC_ prefix.
- Prices, order totals, loyalty points and plan limits are calculated on the server, never trusted from the browser.
- Every screen has empty, loading, error and success states.
- Before any change bigger than one file, show a plan and wait for approval.
- Specs live in docs/spec.md and docs/design.md. Read them before building a feature.

Keep it under 40 lines.

Using the notes from my interviews with Meera (in this project), help me write a spec for QueueLess v1.

QueueLess is a pre-order and loyalty web app. Each café signs up, adds its menu, and pays a monthly plan. Customers order ahead, pay online or at the counter, and earn loyalty points per café.

Roles: café owner, café staff, customer. A person can be a customer at many cafés. Staff belong to one or more cafés.

Write the spec with:
1. Problem and who it's for (3 sentences)
2. User stories per role, each with acceptance criteria
3. Permissions table: role × action (view, create, update, delete) for each kind of data
4. Plans: Free (one café, up to 100 orders a month), Starter, Pro, with the limits each enforces
5. Edge cases (sold-out item mid-order, payment fails, staff removed, café cancels plan)
6. Non-goals for v1

Before writing it, ask me up to five questions about anything unclear.

Using docs/spec.md, create a small design system for QueueLess: a warm chai palette (deep orange, cream, a dark ink colour), a type scale, spacing, border radius, and button, card and input styles. Every text colour must have at least 4.5:1 contrast with its background. Output it as CSS variables that work with Tailwind and shadcn/ui.

Then mock up three screens as one artifact, phone-first:
1. A café's public menu with a cart
2. The customer's order status screen
3. The staff kitchen board with columns: New, Preparing, Ready
Use the design system. No grey buttons.

Read docs/spec.md. Plan the Supabase database for QueueLess as migration files.

Tables: cafes, staff, customers, menu_items, orders, order_items, loyalty_ledger.
Rules:
- Every table except cafes has a cafe_id (order_items can reach it through orders, but include cafe_id anyway for simpler policies).
- Money as integer paise. Order items copy the unit price at the time of ordering.
- Loyalty is an append-only ledger; the balance is a sum, not a stored number.
- Order status is one of: placed, preparing, ready, collected, cancelled.
- Foreign keys with sensible on-delete behaviour.
- Indexes on the columns we'll filter and sort by, including cafe_id plus created_at on orders.
- Turn on Row Level Security for every table in the same migration. Leave policies for the next milestone but make sure nothing is readable without one.

Show me the plan and the table definitions in plain English first. No files yet.

Read docs/spec.md. Plan authentication for QueueLess with Supabase Auth and @supabase/ssr in the Next.js App Router.

I need:
1. Sign in with magic link (email) and with Google
2. A server-side session check helper used by every protected page and server action
3. Onboarding: after first sign-in, a person can create a café (name, slug). Creating a café makes them its owner in the staff table, in one server-side transaction.
4. Staff invites: an owner enters an email; the invited person gets an email (via Resend) with a link; when they sign in through it, they're added to that café's staff with role "staff".
5. Customers sign in from a café's public menu page and get a customers row for that café.

Rules: invites expire after 7 days, can be used once, and only an owner of that café can create them. All of this runs on the server.

Plan first, with the files you'll touch. No code yet.

Read docs/spec.md, especially the permissions table. Write a plan for Row Level Security policies for every table in QueueLess.

Requirements:
- Create a helper function is_cafe_staff(cafe_id) and is_cafe_owner(cafe_id) that check the staff table for the signed-in user. Make them safe (fixed search_path, only readable by authenticated users).
- For each table, list each policy as: table, action (select/insert/update/delete), who, condition. Present it as a table.
- Staff can only see and change data for cafés they belong to.
- Customers can read their own orders and order items, and their own ledger rows, only.
- The public can read cafés and available menu items (for public menus), nothing else.
- Nobody can insert or update loyalty_ledger from the browser. Points are added by a server-side function when an order is paid.
- Nobody can set orders.paid or orders.total_paise from the browser.

Then write a test plan: SQL I can run as two different staff members of two different cafés, and as a customer, to prove isolation. Plan only; no migration yet.

Read docs/spec.md and docs/design.md. Plan the menu management slice for café staff.

- A /dashboard/[cafe]/menu page listing items with name, price, photo and an available toggle
- Add and edit item forms (shadcn/ui), with validation on the server
- Photo upload to a Supabase Storage bucket "menu-photos", in a folder per café; only that café's staff can upload or replace photos there; anyone can view them
- Use the design system tokens
- Empty state: "No items yet. Add your first chai."

Plan first: pages, server actions, storage policies. Wait for my OK.

Plan the customer ordering slice.

- Public menu at /c/[slug] showing available items
- Cart kept in the browser (that's fine, it's just a wish list)
- "Place order" calls a server action that receives only item ids and quantities
- The server looks up current prices and availability, rejects sold-out or unknown items, calculates the total in paise, and creates the order and order items in one transaction
- The customer lands on /orders/[id] showing status: placed, preparing, ready, collected
- Staff can move an order to the next status from the dashboard, only for their café
- Limit each order to 20 items and each quantity to 10

Plan first. Tell me exactly which values come from the browser and which the server decides.

Plan a live kitchen board at /dashboard/[cafe]/kitchen using Supabase Realtime.

- Three columns: New (placed), Preparing, Ready. Collected orders drop off.
- Subscribe only to orders for this café. Realtime must respect our RLS policies, so staff of another café receive nothing.
- Show item names and quantities on each card, loaded efficiently (no query per card).
- One tap moves an order to the next column, using the existing server action.
- A soft chime and a highlight when a new order arrives. A visible "Reconnecting..." banner if the connection drops.
- The customer status page also updates live.

Plan first, including how you'll avoid an N+1 query for order items.

Plan an "Your order is ready" email using Resend.

- Sent from the server when staff move an order to "ready", never from the browser
- Simple, branded with the café's name, plain-text version included
- Only sent once per order, even if the status is toggled back and forth
- If sending fails, log it and don't block the status change
- The Resend API key is server-only

Plan first.

Read docs/spec.md, the plans section. Plan café subscriptions with Stripe.

- Products and prices for Starter and Pro created in the Stripe dashboard (test mode); their price ids go in server-only env vars
- An owner-only "Upgrade" button that creates a Stripe Checkout session in subscription mode on the server
- A "Manage billing" button that opens the Stripe customer portal
- A webhook route at /api/stripe/webhook that verifies the Stripe signature using the raw request body and the webhook secret, then handles checkout completed, subscription updated and subscription deleted by updating cafes.plan
- Webhook handling must be idempotent: store processed event ids and skip repeats
- Plan limits (orders per month, number of staff, number of cafés) are checked in server actions, using the plan stored in our database, never a value from the browser

Plan first. Show me the order of events from button click to cafes.plan changing.

Plan online payment for customer orders.

- After the server creates an order (status placed, paid false), it creates a Stripe Checkout session for that order's total, which the server calculates from order items. The browser never sends an amount.
- For cafés connected through Stripe Connect, route the payment to that café's account. Otherwise, show "Pay at counter" only.
- The order is marked paid only by the verified webhook, never by the success page.
- When the webhook marks an order paid, it calls the server-side function that adds loyalty points to the ledger, once per order.
- Handle payment failure and abandoned checkouts: the order stays unpaid and staff see it as such.

Plan first.

Go through every page and component in the app. For each one, make a table with four columns: empty, loading, error, success. Mark which states exist and which are missing.

Don't change anything yet. Show me the table, then propose the missing states using our design system and friendly copy ("No orders yet. Your first chai is on its way." rather than "No data").

Plan three polish tasks:

1. SEO for public menus at /c/[slug]: page titles and descriptions from the café's name and city, an Open Graph image, a sitemap listing every active café's menu, and structured data for a local café. Dashboard pages must not be indexed.
2. Analytics: privacy-friendly page and event tracking for: menu viewed, item added to cart, order placed, order paid, café upgraded. No personal data in events.
3. Accessibility: keyboard navigation through the menu and cart, visible focus states, labels on every input and icon button, 4.5:1 contrast, and order status changes announced to screen readers.

Plan each as a separate slice.

Act as a careful security reviewer for my own app, QueueLess. Review this codebase for:
- Tables or storage buckets without RLS or with policies looser than docs/spec.md allows
- Server actions and API routes that trust values from the browser (prices, totals, roles, cafe ids, plan names)
- Secret keys reachable from client code
- Missing rate limits on sign-in, invites and order placement
- Webhooks without signature verification or idempotency
- Error responses that leak internal details

Report findings as a table: file, issue, severity, suggested fix. Don't change any code yet.

Write a seed script for a separate staging Supabase project (never production) that creates 5 cafés, 2,000 customers and 100,000 orders with 1 to 4 order items each, spread over 90 days.

Then list the five queries the app runs most (kitchen board, customer order history, owner's daily sales, public menu, loyalty balance). For each, show me how to run EXPLAIN ANALYZE on it in the SQL editor, and what to look for. Suggest indexes only where the plan shows a sequential scan on a large table.

Help me write launch posts for QueueLess, a pre-order and loyalty app for small cafés.

Facts (use only these):
- Built for Meera's Corner, a chai café in Ludhiana, after a delivery app's commission reached 30%
- [number] pre-orders in the first week at Meera's Corner
- Morning queue time went from about [x] minutes to [y] minutes
- Free plan for one café; paid plans from ₹[price]/month

Write: one LinkedIn post (story-first, under 200 words), one X post (under 280 characters), and one WhatsApp message for local café owners (friendly, in plain English, under 80 words). No hype words. End each with the link.

Write a one-page onboarding checklist for a café owner joining QueueLess, and turn it into an in-app checklist on the owner's dashboard:
1. Create your café
2. Add at least five menu items with photos
3. Invite one staff member
4. Print your QR code for the counter
5. Place a test order and move it to Ready
6. Choose a plan (optional)
Each step is ticked automatically when it's done, based on data in our database.

I want to add [stretch goal] to QueueLess. Read docs/spec.md and CLAUDE.md.

First, help me write a short spec section for it: user stories with acceptance criteria, permissions, edge cases and non-goals. Then give me a plan as small slices, each ending in something I can test and commit. Call out any new table that needs RLS and any secret that must stay on the server. Wait for my OK before writing code.

Don't change any code yet.
Find every place in this project where a price, cart total, discount or loyalty points are calculated or read.
For each one, tell me the file, the line, and whether that code runs in the browser or on the server.
Then list any secret keys or environment variables and say whether each could end up in browser code.

Plan how to move all order pricing to the server.

Rules:
- The browser sends only menu item ids and quantities. Never a price or total.
- A server action (or a route handler) looks up prices from our own menu data on the server, calculates the total, and saves the order.
- Ignore any price, total or discount the client sends.
- Validate the input on the server: known item ids only, quantities between 1 and 20, at most 30 lines per order.
- Return clear errors for bad input.
Show me the plan and the files you'll touch. Wait for my OK.

Add a "Recommend a snack" button to the order page.
- The button calls a route handler at app/api/recommend/route.ts.
- Only that route handler calls the AI API, using ANTHROPIC_API_KEY from the environment. Add import "server-only" to any file that reads the key.
- Send the AI only the item names in the current cart and our real menu, and ask it to pick one real menu item.
- Check the reply is a real menu item before returning it.
- Limit each visitor to 5 recommendations per hour; return status 429 after that.
Plan first, then build.

Review the feature you just built.
List every call to an outside service (payments, email, AI, database admin) and every calculation of prices, credits, limits or permissions.
For each, say whether it runs in the browser or on the server. Anything involving secrets, money or permissions must run on the server: propose the change and wait for my OK.

Do a pre-launch secret sweep of this project.
1. List every environment variable and where it is read.
2. Flag any secret (API keys, Stripe secret key, database service or secret keys) that is prefixed NEXT_PUBLIC_, imported by a "use client" file, or hard-coded anywhere.
3. Check .env files are in .gitignore and search the git history for committed keys.
Report findings and fixes. Don't print any secret values.

Check every server action and route handler in this project.
For each, list the inputs it reads from the request. Flag any that it trusts without checking, especially prices, totals, user ids, roles or quantities.
Suggest server-side validation for each, and show me the plan before changing code.

Using the Supabase MCP server (read-only), describe my database schema in plain English.

For each table in the public schema, tell me:
- what it stores, in one sentence
- its columns and their types
- how it links to other tables (foreign keys)
- whether RLS is enabled, and what each policy allows, in one sentence

Then list anything that looks risky: tables with RLS off, policies using true, missing policies, or columns that look like they hold personal data. Don't change anything.

I'm building QueueLess, a pre-order app for a chai café, on Supabase (Postgres).

Propose the database schema as Supabase migration files in supabase/migrations/. Don't apply anything.

For each table include: columns with types, a primary key, foreign keys with sensible ON DELETE behaviour, created_at, and an owner column where rows belong to a user.
In the same migration, enable RLS on every table and add policies so users only see and change their own rows. Use (select auth.uid()) in policies.

After the files, give me a one-line plain-English summary of every policy, so I can check them.

Review this project for database security mistakes. Check:
1. Is the Supabase secret key used anywhere that could reach the browser (client components, NEXT_PUBLIC_ variables, committed files)?
2. Does every table have RLS enabled?
3. Is any policy effectively open to everyone (using true, or no check on the user)?
4. Are there insert or update policies without a with check?

List each problem with the file and line, explain why it matters in one sentence, and propose the fix. Don't change code until I say so.

I'm completely new to coding. In plain English, tell me what you can do in this folder: can you create files, run commands, read my code? What will you always ask my permission for? Keep it under 150 words.

This is a fresh Next.js app (App Router, TypeScript, Tailwind). Replace the starter home page with the menu for Meera's Corner, a chai café in Ludhiana.

Real menu (use exactly these, don't add items):
- Masala chai ₹40
- Cutting chai ₹25
- Ginger chai ₹45
- Bun maska ₹50
- Veg sandwich ₹90

Requirements:
- Keep the menu data in its own file (src/data/menu.ts) so we can reuse it later.
- Phone-first layout, warm orange and cream colours, prices right-aligned.
- Heading "Meera's Corner" and the line "Order ahead, skip the queue."

Before you write code, show me a short plan with the files you'll create or change. Wait for my OK.

Something broke. Here's what I did just before: [describe the last thing you did or asked for].

Here's the full error from [the terminal / the browser console / the Vercel build log]:

[paste the entire error, every line]

Explain in plain English what went wrong, then propose the smallest fix. Don't change anything else.

You suggested installing the package [package-name]. Before I install it:
1. What does it do, in one sentence?
2. Is it widely used and actively maintained? Point me to its npmjs.com page.
3. Is there a more popular alternative, or can we do this without a new package?

Explain the changes you just made, file by file, in plain English. For each file: what changed and why. Then tell me how I can check in the browser that it works.

Add sign-in to this Next.js App Router app using Supabase Auth with the @supabase/ssr package.

- Sign-in page at /login with: email magic link, and "Continue with Google"
- Use cookie-based sessions that work in server components, route handlers and middleware
- A sign-out button in the header
- Do NOT build any custom password storage. Use Supabase Auth only.
- Never use the service role key in any file that runs in the browser.

Plan first, list the files you'll create or change, and wait for my OK.

Create a Supabase SQL migration that adds:
- a profiles table (id references auth.users, display_name)
- a cafes table (id, name)
- a cafe_staff table (cafe_id, user_id, role) where role is 'barista' or 'owner'
- a trigger that creates a profiles row when a new user signs up
Everyone is a customer by default. Staff are people listed in cafe_staff.
Add a cafe_id column to orders if it doesn't exist.
Turn on row level security for every new table in the same migration.
Show me the SQL before running anything.

Write a Supabase migration with RLS policies for: menu_items, orders, order_items, profiles, cafes, cafe_staff.

Rules:
- Every table has row level security enabled.
- Customers can read and insert only their own orders and order_items. They cannot update prices or totals.
- Baristas and owners can read and update orders only where orders.cafe_id is a cafe they are listed for in cafe_staff.
- Only owners can insert, update or delete menu_items for their cafe. Anyone can read menu_items.
- Users can read and update only their own profile row.
- No policy may use "using (true)" except public reads of menu_items and cafes.
- Use (select auth.uid()) rather than auth.uid() for performance.

For each policy, add a one-line SQL comment explaining it in plain English.

Add rate limiting to the API routes in this app that call the AI model, and to any custom auth-related routes.
Limit per signed-in user (or per IP for signed-out requests): 10 requests per minute for the AI route.
Return HTTP 429 with a friendly message when the limit is hit.
Suggest a simple option that works on Vercel (for example Upstash Redis rate limiting), explain the trade-offs, and wait for my choice before installing anything.

You are a careful security reviewer. You did NOT write this code. Review my own app in this repository for the ten most common flaws in AI-built apps. This is my code and I'm fixing it before launch.

For each item, say PASS, FAIL or UNSURE, and for every FAIL or UNSURE give the file path and line numbers, what's wrong in one sentence, and the smallest fix.

1. Database tables with row level security off, or policies that allow everyone (using (true)) on private data. Check every migration and SQL file.
2. Secret keys (service role key, Stripe secret key, AI API keys) in any file that runs in the browser, in NEXT_PUBLIC_ variables, or committed to the repo.
3. Pages or API routes where access is checked only in the UI (hidden buttons) and not on the server.
4. Any place the server fetches a record by id without checking it belongs to the signed-in user or their cafe.
5. Login, sign-up, password reset or AI routes with no rate limiting.
6. Server code that uses request input without validating type, length and allowed values.
7. Storage buckets that are public but hold private files.
8. Missing CSRF protection on state-changing requests, and missing security headers.
9. Webhook routes that don't verify the sender's signature before acting.
10. Detailed error messages, stack traces, test or debug routes reachable in production.

Before the checklist, list every file you actually read. At the end, give me the FAILs ordered by severity. Don't change any code yet.

Here is a row level security policy from my app:

[paste the policy]

In plain English: who can do what to which rows? Then give me two test cases I can run as two different signed-in users to prove it works, and one case that should be refused.

My app shows this error: [paste the exact error].
It happens when [who] tries to [action] on [table].

Find the narrowest RLS policy change that allows exactly this, and nothing more. Do not use "using (true)" and do not use the service role key in client code. Explain why your fix is still least privilege.

Make a one-page menu for a small chai café called Meera's Corner in Ludhiana.

Real menu (use exactly these, don't add items):
- Masala chai ₹40
- Cutting chai ₹25
- Ginger chai ₹45
- Bun maska ₹50
- Veg sandwich ₹90

Style: warm, friendly, easy to read on a phone. Prices in rupees.
Make it as an artifact I can see next to our chat.

Explain the part of this code that draws the price list, line by line, in plain English. Assume I've never coded. Keep each explanation to one sentence.

I want to add [describe the change] to [the page/app].
Before writing any code, give me a short numbered plan: what you'll change, and anything you need to know from me. Wait for my OK.

Here is everything my café ordering app needs to remember:
[paste your list]

Design a Postgres schema for Supabase:
- One table per kind of thing. Store each fact once.
- A primary key on every table (uuid or bigint identity; explain which and why).
- Foreign keys for every relationship, and a join table for many-to-many.
- Money stored as integer paise, not decimals.
- Proper column types, NOT NULL where a value is required, and created_at timestamps.
- customers.id should reference auth.users(id).

Give me: the tables in a short list with one line each, then an ER diagram in Mermaid syntax, then any questions you have. No SQL yet.

The menu page currently has hard-coded menu items. Replace them with a query to the menu_items table in Supabase.

- Fetch in a server component using the server Supabase client.
- Only show rows where available = true, ordered by name.
- Prices are stored as integer paise; display them as rupees (4000 → ₹40).
- Add a read-only RLS policy so anyone can select from menu_items, and nothing else.
- Include empty, loading and error states.
Show me the plan and the policy SQL before changing anything.

Explain this SQL query line by line in plain English, as if I've never written SQL. Then tell me what rows it would return for a small example, and whether anything in it could be slow or dangerous.

[paste the query]

Review this migration before I apply it to my database. It holds real customer data.

[paste the migration]

Tell me:
1. Exactly what it changes, in plain English.
2. Anything that could delete or lose data (drop, truncate, delete without where, changing a column type).
3. Whether RLS stays enabled on every table.
4. How I would undo it.
Don't rewrite it unless something is dangerous.

Context: [what the app is, where this fits, which docs to read, e.g. docs/spec.md section 4]

Goal: [one sentence, from the user's side, e.g. "Each café has its own menu page at /c/[cafe-slug]."]

Acceptance criteria:
- [observable thing 1, e.g. "/c/meeras-corner shows Meera's menu exactly as today"]
- [observable thing 2, e.g. "A second test café shows only its own items"]
- [observable thing 3, e.g. "No café can read another café's menu items, enforced by RLS"]

Constraints:
- [what not to change, e.g. "Don't rename existing tables. Don't touch login."]
- [limits, e.g. "One slice only. Stop after this and wait for me."]

Before writing code, ask me any questions you need answered, then give me a short plan.

Something's broken. Please investigate before changing anything.

What happened: [what you saw]
What I expected: [what should have happened]
Exact error: [paste the full error message and where it appeared: browser console, terminal, Supabase logs]
Steps to reproduce:
1. [step]
2. [step]
What I've already tried: [anything you or Claude tried, and what happened]

First, explain the most likely cause and how you'd confirm it. Don't edit files until I agree.

Act as a careful senior engineer reviewing this change before it goes to production. Review the current uncommitted diff.

Check for:
1. Security: missing auth or permission checks, data one café could see from another, secrets in code, anything trusting the browser.
2. Data integrity: missing constraints, migrations that could lose or corrupt existing data, race conditions.
3. Edge cases: empty states, a café with no menu, deleted users, very long names.
4. Performance: queries inside loops, missing indexes, fetching more than needed.

List findings by severity (critical, high, medium, low), each with the file, the problem and a suggested fix. Don't change any code.

I want to [describe the change]. Before writing any code, give me two genuinely different ways to do it.

For each: what changes (files, tables), the main risk, and what it would cost to undo later. Then tell me which you'd pick for a small team shipping in two weeks, and why. Don't code until I choose.

We just finished a slice. Look at what went wrong or needed correcting in this session.

Suggest at most three short lines to add to CLAUDE.md that would have prevented those problems. Each line should be a rule or a pointer, not an essay. Show me the lines first; don't edit the file until I approve.

These are screenshots of three ordering apps I like. For each, describe the layout, the main components (buttons, cards, drawers, etc.) and how you get from the menu to paying.

Then list the patterns all three share, and the one thing each does that the others don't.

Finally, suggest which 3–4 patterns suit a small chai café whose customers order one-handed on a phone while standing in a queue.

Make a clickable phone-sized mockup (as an artifact) of an ordering flow for Meera's Corner, a chai café: Menu → Item detail → Cart → Checkout.

Use this real menu only: Masala chai ₹40, Cutting chai ₹25, Ginger chai ₹45, Bun maska ₹50, Veg sandwich ₹90.

Design: deep chai orange (#C2410C) for main buttons, cream background, dark brown text, big rounded buttons in the bottom half of the screen. No gradients, no sparkle icons. Checkout can be fake; no real payments.

In this Next.js app, build the ordering UI for Meera's Corner using shadcn/ui and Tailwind.

1. Set up shadcn/ui if it isn't already, and add the Button, Card, Sheet and Badge components.
2. Menu page: show the items from src/data/menu.ts as cards (name, price, an Add button). One column on phones.
3. A cart bar fixed to the bottom showing item count and total, e.g. "2 items · ₹65 · View cart".
4. Tapping it opens a Sheet (drawer) from the bottom listing cart items with + and – buttons and a Checkout button. Checkout can just show "Coming soon" for now.
5. Keep the cart in React state for now (no database yet).

Design: deep chai orange (#C2410C) for main buttons, cream background, dark brown text, 16px minimum body text, tap targets at least 44px.

Show me your plan and the files you'll touch before writing code.

Add proper states to the menu and the cart drawer:
- Empty cart: a friendly message ("Your cart is empty. The masala chai is very good.") and a button that closes the drawer.
- Loading: skeleton cards while the menu loads. Simulate a 1.5 second delay for now so I can see it.
- Error: if the menu fails to load, show "Couldn't load the menu. Check your connection and try again." with a Try again button. Add a temporary way for me to trigger it (a ?error=1 query parameter).
- Success: a short toast when an item is added ("Masala chai added").

Tell me how to see each state in the browser.

This screen looks like a generic AI-built app. Restyle it with these decisions only:
- Brand colour: deep chai orange #C2410C for main actions only
- Background: warm cream #FFF7ED; text: dark brown #431407
- Font: one family; headings bold, body 16px
- Corners: rounded-xl on cards and buttons
- No gradients, no sparkle or AI icons, no grey buttons

Check every text colour against its background meets a 4.5:1 contrast ratio and tell me any that don't.

We're building QueueLess: pre-orders and loyalty points for chai cafés. It will serve several cafés, each with its own menu, staff and customers.

Before any feature code, propose a Postgres schema for Supabase. For each table give:
- columns with exact types (timestamptz for times, numeric for money, never float)
- the primary key
- foreign keys with ON DELETE behaviour and why
- check constraints or enums for status-like columns
- created_at, updated_at, and an owner or cafe_id column on every table holding user data
- the indexes we'll need, based on the queries the app will run
- who owns each row, and the RLS policy that follows from that

Show it as a table per table first. Ask me questions about anything unclear. Don't write migrations until I approve.

Write a SQL seed script for my QueueLess staging database (Supabase Postgres). Look at the existing schema first.

Create:
- 3 cafés, each with 8 menu items and 2 staff memberships
- 500 test customers
- 100,000 orders spread across the 3 cafés over the last 90 days, more at morning and evening peaks
- 1 to 4 order_items per order, with unit_price copied from the menu
- realistic statuses: most collected, some cancelled, about 200 pending or preparing

Use generate_series and random() so it runs in one go. Put it in supabase/seed-load-test.sql. Add a comment at the top saying it must never be run on production.

Here's an EXPLAIN ANALYZE output from my Supabase database, plus the query and the table definitions.

[paste the plan, the query, and the CREATE TABLE statements]

Explain in plain English:
1. What the database is doing, step by step
2. Which step takes the most time and why
3. What index (exact CREATE INDEX statement) or query change would fix it
4. Any cost to that fix (slower writes, extra space)

Don't suggest disabling RLS or using the secret key.

Search this codebase for N+1 query patterns: anywhere we fetch a list from Supabase and then query once per item (inside a loop, map, or a component that fetches per row).

For each one:
- show the file and lines
- say how many queries it makes for 50 orders
- rewrite it as a single query using a nested select (e.g. order_items(quantity, menu_items(name))) or one batched .in() query

Keep the same data shape for the UI. Show me the diff before applying.

I'm writing a product spec for [product], a [one-line description]. My idea brief is attached.

Interview me to gather everything a detailed spec needs: users and their jobs-to-be-done, user stories, screens and flows, data, roles and permissions, integrations, non-goals, success metrics and open questions.

Rules:
- Ask exactly ONE question at a time and wait for my answer.
- Ask follow-ups when my answer is vague or contradicts something earlier.
- Push me on edge cases: empty states, errors, who is NOT allowed to do something.
- After about 20 questions, or when I say "draft it", stop and tell me what's still unclear.

You are a sceptical senior engineer and product manager. Below is a spec that an AI coding agent will build from, literally.

Find every gap that would force the agent to guess. Look for:
- User stories without testable acceptance criteria
- Missing roles or permissions (who can't do this?)
- Missing states: empty, loading, error, offline, partial data
- Edge cases: two people at once, deleted items, refunds, very long text
- Contradictions between sections
- Data the screens need that the data model doesn't store
- Anything that sounds nice but can't be measured

List gaps by severity, quoting the line each one relates to, and suggest the fix. Don't rewrite the spec.

[paste docs/spec.md]

I'm designing [product] for [target users]. Attached are screenshots of [N] apps these users already use and like: [list them].

Analyse them and give me:
1. Shared patterns users will expect (layout, navigation, where key buttons sit, how status is shown).
2. Information density: how much appears on one phone screen.
3. Colour: how many colours, what they're used for (action, success, warning), light vs dark backgrounds.
4. Typography: number of sizes, weights, how headings and prices are styled.
5. Tone of voice in buttons, empty states and errors.
6. What to COPY because it's a user habit, and where we should DIFFER to feel like [brand personality].

Then propose a starting design system: colour palette with hex values and WCAG contrast ratios for text pairs, a type scale, a spacing scale, border radius, shadows, motion, and a list of core components. Flag any colour pair below 4.5:1.

Using the attached docs/spec.md and docs/design-system.md, create a mobile mockup of the [screen name] screen from the spec's screen list.

Rules:
- Use ONLY the tokens in the design system: colours, type sizes, spacing, radius. No new colours.
- Use realistic content from the spec (real menu items and ₹ prices), never lorem ipsum.
- Show these states side by side: empty, loading, error, success, and a desktop width version.
- Use the voice and tone rules for every button, label and message.
- Make buttons link to the next screen in the flow so I can click through.

After the mockup, list anything in the spec that was unclear while you designed it.

Compare the [screen name] screen as built (run the app at [URL]) with its mockup in docs/mockups/[file].

Check every state in the mockup: empty, loading, error, success, mobile and desktop.
List each difference: layout, spacing, colour, type, copy, missing states. For each, say whether the code or the mockup should change, and why.
Also flag any styles in the code that don't use design tokens. Don't edit anything yet.

Read docs/design-system.md. Add its tokens (colours, type scale, spacing, radius, shadows, motion durations) to our Tailwind config as named theme values.

Don't change any components yet. Show me the config diff and a short list of token names I should use in components. Then add a line to CLAUDE.md: "Use design tokens only; never raw hex colours or ad-hoc pixel values."

Design the API for QueueLess, our chai café pre-order app. Don't write code yet.

Give me a table with these columns:
method | path | who may call it | request body | success response (status + shape) | error responses

Cover: reading the menu, placing an order, getting one order, listing my orders (paginated), Meera marking an order ready, cancelling an order, and the Stripe webhook.

Rules:
- Paths are nouns, methods are verbs.
- The client never sends prices or totals.
- "Who may call it" must be specific, e.g. "signed-in customer who owns this order".
- One consistent error shape for every endpoint.
- Note which endpoints need rate limits.

We're integrating [service name]. Here are the official docs: [link].
Use only endpoints, parameters and options that appear in these docs, for the version in our package.json.
If you're unsure whether something exists, say so instead of guessing.

List every route handler and server action in this project.
For each: the method and path, who should be allowed to call it, and the exact line where the code checks that. Flag any endpoint where a signed-in user could read or change data that isn't theirs, and any endpoint without a rate limit that calls a paid service.