Vibe Coding Prompts and Best Practices: Copyable Templates and Workflow Rules

# PRD: <App name>

## One-liner
<App> helps <specific user> <do one job> without <current pain>.

## Users
- Primary: <who, in one sentence>
- Not for: <who we are explicitly ignoring in v1>

## Core flow (the one thing that must work)
1. User lands on <page> and <action>.
2. User signs up with <email magic link / Google>.
3. User <core action>.
4. User sees <result> and can <share / export / come back later>.

## Screens
- / (landing): headline, one screenshot, sign-up button
- /app (dashboard): <what is listed, what can be clicked>
- /app/<item> (detail): <fields shown, actions>
- /settings: email, delete account

## Data
- users: id, email, created_at
- <items>: id, user_id (owner), <field>: <type>, created_at
Rule: a user can only read and write rows where user_id = their id.

## Integrations
- Auth + database: <Supabase / Firebase / built-in>
- Payments: none in v1 (or: Stripe Checkout, one plan, $<x>/mo)
- Email: <Resend / none>
- AI: <model and what it is used for, with a monthly spend cap>

## Out of scope for v1
- Teams, roles, admin panel, mobile app, dark mode, i18n

## Done means
- A new user can complete the core flow on mobile and desktop in under 2 minutes.
- No secrets in client code; every table has row-level security.
- Deployed at <domain> with analytics and error tracking.

# Project rules (AGENTS.md / CLAUDE.md / .cursor/rules)

## Stack
- <Next.js + TypeScript + Tailwind + Supabase>. Do not add new frameworks or libraries without asking.

## How to work
- Read SPEC.md and PROGRESS.md before every task. Update PROGRESS.md when a task is done.
- Plan first: for anything touching more than 2 files, show the plan and wait for "go".
- One task at a time. Do not refactor or "improve" code outside the task.
- After changes, run the type checker, linter and tests, and fix what you broke.

## Code
- Keep files under 300 lines; split by feature.
- Reuse existing components and helpers before writing new ones.
- No placeholder or mock data in production code paths.

## Security (never break these)
- Never put secret keys in client code or commit them. Use environment variables.
- Every new table gets row-level security policies scoped to the owner.
- Every API route and server action checks the session before reading or writing data.
- Validate all user input on the server.
- Only install packages you can confirm exist and are maintained; tell me the package name first.

Read SPEC.md and the existing code. Don't write code yet.

Task: <feature>.
1. Explain how this fits the current structure (which files, which tables).
2. List the changes you would make, file by file.
3. Call out risks: data migrations, security, anything that could break existing features.
4. Ask me any question whose answer would change the plan.

Implement step <n> from the plan: <one sentence>.
Only this step. Keep the existing design system and components.
When done: list the files you changed, how to test it by hand, and anything you were unsure about.

Build the <page> screen.
Layout: <describe sections top to bottom>.
Style: match the existing components; spacing and type from the current pages; mobile first.
Reference: <attach screenshot or describe a site whose layout to borrow>.
States to handle: loading, empty (first-time user), error, and a long list (50+ items).

Bug report.
Expected: <what should happen>
Actual: <what happens>
Steps: <1, 2, 3>
Error (exact): <paste console / server log>
What changed recently: <last prompt or commit>

Before changing anything: explain the most likely cause and how you'd confirm it.
Then fix the cause, not the symptom, and tell me how to verify the fix.

We've tried to fix this 3 times without success. Stop patching.
1. Summarise what we know and what each attempt changed.
2. List 3 different hypotheses for the root cause.
3. Suggest how to test each one cheaply (a log line, a minimal reproduction).
Revert any changes from the failed attempts that are not needed.

Act as a security reviewer for this app. Don't change code yet; produce a report.
Check and list file + line for every finding:
1. Secrets: any API keys, service_role keys or tokens in client code, the repo or logs.
2. Database: every table has row-level security enabled, and policies restrict reads/writes to the owner.
3. Auth: every page, API route and server action that touches private data verifies the session server-side.
4. Input: user input validated server-side; no raw SQL string building; no dangerouslySetInnerHTML with user content.
5. Payments: prices and entitlements decided on the server, webhooks verified with the signing secret.
6. Abuse: rate limits on sign-up, login, AI and email endpoints; spend caps on paid APIs.
7. Dependencies: any package that is unmaintained, has few downloads or that you are not sure exists.
Rank findings by severity and propose the smallest fix for each.

Refactor <file or feature> without changing behaviour.
Goals: smaller files, no duplicated logic, clear names.
First write or list tests that pin the current behaviour, then refactor, then run them.
Do not touch unrelated files.

Write automated tests for the core flow in SPEC.md: sign up, <core action>, see result.
Also cover: a logged-out user can't reach /app, and user A can't read user B's <items>.
Use the project's existing test setup; if there is none, propose one and wait for my OK.