Prompt Vault

Before continuing, summarize everything completed so far in a CHECKPOINT.md file (architecture decisions, file paths touched, remaining TODOs). From now on, re-read CHECKPOINT.md at the start of every new task and update it after every meaningful change. Never rely on conversation memory alone for state that matters.

Only modify what is strictly necessary to complete this task. Do not refactor, rename, reformat, or 'improve' unrelated code. If you believe a broader change is needed, stop and explain why before touching any files outside the immediate scope.

Before we finish, write a HANDOFF section at the top of CHECKPOINT.md for the next session: (1) exact state of the current task — done, in progress, or broken, (2) the next single action to take, (3) any gotcha you discovered that isn't obvious from the code, (4) commands to run to verify the project still works. Keep it under 15 lines.

Do not assume the contents of any file, database schema, or API you have not read in this session. If you need to know how something works, read the actual file first. If you cannot access it, say so and ask — never write code against an imagined version of my project.

Break this feature into the smallest set of independently working increments. After each increment, run the build/tests, confirm it passes, then create a git commit with a clear message before moving to the next increment. Never let more than one increment of uncommitted, unverified work accumulate.

Before writing any code, give me a short plan: (1) the files you will create or change, (2) the data model if any, (3) the one decision you're least sure about. Wait for my approval before implementing. If during implementation the plan turns out to be wrong, stop and revise the plan rather than improvising.

A task is not complete until you have run it and observed it working — build passing, page rendering, request returning the right data. 'The code looks correct' does not count as verification. If you cannot run something, say exactly what you could not verify so I can check it manually.

Before starting, ask me the single most important question that would change how you build this — the one where guessing wrong wastes the most work. Just one. Make reasonable assumptions on everything else and list those assumptions in one line each.

Build a production-ready full-stack web app using React + TypeScript + Tailwind on the frontend and Supabase for auth, database, and storage. Use Stripe for billing. Set up Row Level Security policies for every table from the start. Deploy-ready means: typed environment variables, no hardcoded secrets, and a working build command.

Build [one-sentence purpose of the app].

Users: [who uses it and whether they log in].

Core data: a [entity] has [list the fields, including types where it matters — dates, numbers, status enums].

Screens: (1) [main screen and what it shows], (2) [create/edit screen], (3) [any other screen].

Rules: each user only sees their own data. Keep the design clean and minimal — no placeholder content, no features I didn't list.

Before building any UI, propose the complete database schema for this app: every table, every column with its type, and the relationships between tables. Flag any place where you had to make a judgment call. I will approve the schema before you build anything on top of it.

Do not patch the symptom. First reproduce the bug, then trace it to its root cause and explain that cause in one sentence before writing any fix. If the fix requires a workaround instead of a real fix, say so explicitly and explain the tradeoff.

After fixing this, identify the three features most likely to be affected by your change and verify each one still works. List what you checked and what you observed. A fix that breaks something else is not a fix.

Before changing any code, explain back to me in plain language: what is happening, what should be happening, and why the difference occurs. If you cannot explain the 'why' from evidence you've actually gathered, gather more evidence first — add logging, reproduce it, read the relevant code. No speculative fixes.

Stop. The last attempts failed for the same underlying reason. Do not try another variation of the same approach. Instead: (1) list every assumption the failing approach depends on, (2) test the assumption most likely to be false, (3) propose one approach that does not share that assumption. If you need information you don't have, tell me what it is.

Review the current UI for visual fidelity against top-tier SaaS products (Linear, Lovable, Stripe). Specifically check: spacing consistency, color contrast, hover/focus states, loading and empty states, and responsive breakpoints. Fix any issue found without changing the underlying functionality.

For every screen that displays data, implement all three missing states: (1) loading — a skeleton or spinner, never a blank flash, (2) empty — a helpful message with the action that creates the first item, never a bare zero-results table, (3) error — a human-readable message with a retry option, never a raw error string. Do not change anything else.

Audit every page at 375px width. Fix: horizontal overflow, tap targets smaller than 44px, text below 14px, tables that should collapse to cards, and any hover-only interaction that has no touch equivalent. Show me the list of what you found and fixed.

Do an accessibility pass focused on the highest-impact issues: every image has meaningful alt text or is marked decorative, every form input has a label, interactive elements are reachable by keyboard with a visible focus state, color contrast meets WCAG AA, and heading levels don't skip. Fix what you find; list anything you couldn't fix and why.

Audit every database table for per-user data isolation. For each table: confirm Row Level Security is enabled, list the policies that exist, and identify any table where one authenticated user could read or modify another user's rows. Then describe exactly how I can verify this myself with two test accounts. Do not mark this done based on the code alone — check the actual policies.

Search the entire codebase for secrets that could reach the browser: service-role keys, secret API keys, database credentials, or tokens in frontend code, committed .env files, or client-side network calls. The only keys allowed client-side are explicitly publishable/anon keys. Report every finding with file and line, then move each violation to server-side environment configuration.

Harden every user input in the app: validate on the server (not just the client), enforce sensible length and format limits, sanitize anything rendered back into the page, and confirm that IDs in URLs or requests are authorized against the logged-in user — not just used as given. List each input you hardened and what it now rejects.

Run a pre-launch check and report pass/fail on each item with evidence: (1) auth required server-side on every data endpoint, (2) RLS verified with two test accounts, (3) no secret keys in client code, (4) payments webhook updates the database on a test transaction, (5) all three UI states (loading/empty/error) exist on data screens, (6) the production build completes clean. Do not soften failures — I need the true list.

Give every page a unique, accurate <title> under 60 characters and meta description under 160. Add exactly one H1 per page with logical H2/H3 structure below it. Generate a sitemap.xml and robots.txt. Add Open Graph tags with a real preview image. If the site is client-rendered, tell me honestly what crawlers will and won't see, and what my options are.