Lovable Prompts: 151 Free Prompt Templates and Examples

# Context
Build an internal metrics dashboard for a small product team: a fixed set of company metrics, each computed by one saved query against the production database replica, displayed with current value, trend, and week-over-week delta.

## Core Features (Priority Order)
1. Metric cards: current value, 7-day sparkline, week-over-week delta with direction
2. One saved query per metric, stored w

# Context
Build a single-purpose landing page: capture an email address before a product launches. The visitor arrives from one known traffic source, so the page carries one offer and one action, and nothing that competes with them.

## Core Features (Priority Order)
1. Hero: the offer in one sentence, the form visible without scrolling
2. Email capture writing to Supabase with UTM parameters stor

# Context
Build an internal prompt library: team members store prompts with named variables, copy them with variables filled from a form, track versions as prompts improve, and see which prompts the team actually uses.

## Core Features (Priority Order)
1. Prompt entries: title, body with {variable} placeholders, category, usage notes, owner
2. Copy flow: clicking copy opens a variable form, outpu

# Context
Build file upload with tagging: users drag files in, watch true per-file progress, and organize with tags that are managed values rather than free text. The unhappy paths are the feature; a demo-quality uploader breaks on the first flaky connection.

## Core Features (Priority Order)
1. Drag-drop zone with click-to-browse fallback and visible file-type and size rules
2. Per-file progress

# Context
Build a request explorer for your own API: users compose requests from your actual endpoint catalog, send them with their own credentials, inspect responses, and save named examples for reuse.

## Core Features (Priority Order)
1. Endpoint picker from your API catalog: method, path, described parameters
2. Request composer: path params, query params, headers, JSON body with validation ag

# Context
Set up this repository for repeated Claude Code sessions. The goal is that a session started tomorrow by someone else, or by you after a week, holds the same facts and runs the same checks without re-explaining anything. Read the repository first; do not guess the stack.

## Core Features (Priority Order)
1. A CLAUDE.md at the root, under 200 lines: stack with versions, the commands to b

# Context
Set up this repository for repeated Cursor Agent sessions. Read the repository first: package manifests, config, existing rules or AGENTS.md. The goal is that any later chat starts with the same conventions attached and ends by running the same checks.

## Core Features (Priority Order)
1. .cursor/rules/project.mdc with alwaysApply: true, under 60 lines: stack with versions, build and te

# Context
Build the public landing page for [product], for [who it is for]. One offer in plain words, one primary action: join the waitlist. The app's visibility is Public; the waitlist data is not.

## Entities
- Lead: email (required, email format), created_at, source, utm_source, utm_medium, utm_campaign, consent (boolean, default false)
- Rules: anyone may create a Lead; only admins may read, 

# Context
Build the contact and company layer of a lightweight CRM for [a founder or a team of up to ten doing their own sales]. Speed of entry matters more than field completeness: a contact should take ten seconds to add. The database already exists: companies, contacts and notes tables with row-level security, from the Lightweight CRM kit. Do not recreate them.

## Data Rules
- owner_id is set 

# Context
Build the access layer of an internal admin dashboard for [the team running the product]. The database already exists from the Internal Admin Dashboard kit: a user_roles table with admin and member roles and no insert policy, and an append-only events table. Do not recreate them. The rule of the whole dashboard: the role is read from the database on every request, never from client state

# Context
Add paid subscriptions to an existing app using Stripe Checkout. Entitlements per plan are already defined in the app; this prompt wires purchase, verification and lifecycle. Trust the webhook, not the redirect.

## Core Features (Priority Order)
1. Plan selection UI reading plan definitions from one config object
2. Stripe Checkout session creation on the server, never exposing the secr

# Context
Build an internal user management dashboard: support and admins find any account in seconds, see its state, and take the five common actions safely, with every action logged.

## Core Features (Priority Order)
1. Search by email, name, or account id, with results in under a second
2. User detail: plan, status, signup date, last active, recent key events
3. Actions: change plan, suspend, 

# Context
Build a landing page for a dated event: a countdown to one canonical moment, email capture for reminders, and a defined transformation of the page when the countdown reaches zero.

## Core Features (Priority Order)
1. Countdown from a single UTC timestamp, rendered in the visitor's local time zone with the zone named
2. Email capture: 'remind me', storing the address with UTM parameters

# Context
Build a lightweight CRM: contacts and companies with duplicate prevention, a definable pipeline, fast activity logging, and a today view that surfaces due follow-ups before deals cool.

## Core Features (Priority Order)
1. Contacts: name, email, company, tags, owner, with company pages aggregating their contacts
2. Pipeline: definable stages, deals with value and expected close, drag bet

# Context
Build an analytics dashboard for operators: headline metrics, one trend, one breakdown table, readable in five seconds and honest under failure. Every number answers 'compared to what, over when'.

## Core Features (Priority Order)
1. Four metric tiles, each stating its time window on the tile, with delta versus previous period
2. One time-series chart with range selector (7, 30, 90 days

# Context
Build a weather dashboard consuming a third-party weather API: current conditions and forecast for saved locations, with response caching, a visible data age, request budget tracking and honest failure states.

## Core Features (Priority Order)
1. Saved locations: add by search, reorder, remove, with current conditions per card
2. Detail view: hourly next 24h, daily next 7 days, sensible

# Context
This repository is a Lovable export synced two ways with GitHub. Lovable keeps its own copy of the synced branch and will overwrite or lose edits if that branch's history is rewritten. Your job is to make the repository safe for agent edits without breaking the sync.

## Core Features (Priority Order)
1. Identify the generated files (the Supabase client and types under src/integrations, 

# Context
This repository is a Lovable export synced two ways with GitHub. Lovable keeps its own copy of the synced branch and can lose edits if that branch's history is rewritten. Make the repository safe for Agent edits without breaking the sync. Read @vite.config.ts, @src/integrations and @supabase first.

## Core Features (Priority Order)
1. A rule file naming the generated files as never-edit

# Context
Build the foundation of a team product: a user signs up, gets a workspace, and invites teammates who arrive in the same workspace with a role. Visibility: Private, sign-in required. Use Base44's built-in auth; do not build a second login.

## Entities
- Workspace: name, owner_user_id, created_at
- Membership: workspace_id, user_id, role (owner | admin | member), joined_at
- Invite: works

# Context
Add a deal pipeline to the CRM. Stages come from the kit's pipeline stage enum; the team can rename labels but the enum is the source of truth. A deal belongs to a company, has a value in integer cents, a stage, an owner set by the database, and an expected close date.

## Data Rules
- Stage changes are written by a server function that also appends a row to a stage_history table with fr

# Context
Build the metrics overview of the admin dashboard. Every metric has a window (today, 7 days, 30 days) and is computed in the database by a view or a function that respects the caller's role, like the kit's event_counts_by_day(). A metric that cannot be computed shows "unknown", never zero.

## Data Rules
- Aggregates are views or functions with a window parameter; no client-side arithmet

# Context
Build a roadmap planner for a product team: cards move across stage columns, order within a column matters, and shipped work becomes a changelog entry without retyping. Decide visibility per board: internal or public read-only.

## Core Features (Priority Order)
1. Board with four columns: Ideas, Planned, In Progress, Shipped
2. Cards: title, one-paragraph description, tags, target quart

# Context
Build an API key manager for a developer-facing product: users create named keys, see them once, and manage their lifecycle; the server stores only hashes and records usage.

## Core Features (Priority Order)
1. Create key: name, optional expiry, shown in full exactly once with a copy button
2. Key list: name, prefix (first 8 chars), created, expires, last used
3. Revoke immediately; rot

# Context
An existing landing page converts at a known baseline. Build variant testing: serve visitors one of two versions differing in exactly one element, keep the assignment stable per visitor, and measure conversion per variant from the first impression.

## Core Features (Priority Order)
1. Variant definition: one changed block (hero promise, CTA wording, or proof section), everything else sh

# Context
Build a survey tool: compose surveys from a small set of well-made question types, share by link, protect response integrity, and read results in views that answer the question the survey asked.

## Core Features (Priority Order)
1. Builder: single choice, multiple choice, scale (1-5, 1-10), short text, long text, reorderable
2. Share: public link per survey, open and close dates, respon

# Context
Build a multi-step onboarding flow: a handful of screens that configure the product for a new user, with progress that survives interruption and questions that earn their place by visibly changing what comes next.

## Core Features (Priority Order)
1. Stepper UI: current position, step names, and back navigation that never loses answers
2. Progress persisted server-side per user; resume 

# Context
Build an AI PDF summarizer: upload a PDF, extract its text, produce a structured summary shown beside the source, with limits and failures stated plainly and costs controlled per account.

## Core Features (Priority Order)
1. Upload with page and size limits stated up front, progress shown
2. Extraction with per-page status; scanned or image pages reported as unextractable, not silently 

# Context
Build the foundation of a multi-tenant app in this repository: users sign up, get a workspace, and invite teammates who arrive with the right role. Read CLAUDE.md and the existing schema first. The invite must work before anything is polished.

## Core Features (Priority Order)
1. Email and password auth with session persistence across refresh
2. Workspace created on first sign-in, creat

# Context
Build the foundation of a multi-tenant app in this repository: users sign up, get a workspace, invite teammates who arrive with the right role. Read @.cursor/rules/database.mdc and the existing schema under @supabase/migrations first. Create a checkpoint before the first migration.

## Core Features (Priority Order)
1. Email and password auth with session persistence across refresh
2. Wo

# Context
Build a public directory of [entities] for [audience]. Every record is a page with its own URL and enough unique text to be worth indexing. Visibility: Public for the directory; editing is admin-only.

## Entities
- Item: slug (unique), name, summary (one sentence), body (sections), category, related_slugs (list), updated_at, published (boolean)
- Rules: anyone reads published Items; onl

# Context
Build the activity timeline for the CRM on the kit's notes table. Notes are append-only: no edits, no deletes from the client, ever. The point is that logging a call takes less time than the call's last ten seconds.

## Data Rules
- A note has a type (call, email, meeting, note), a body, a contact or a company, an author set by the database, and a timestamp
- Anyone on the team can read 

# Context
Build the event log viewer of the admin dashboard on the kit's events table. Events are append-only: there is no update or delete policy, and this brief adds none. An admin sees every event; a member sees their own, because the policies say so, and the viewer must not pretend otherwise.

## Data Rules
- Reads go through the existing policies; the viewer adds no function that bypasses the

# Context
Build the customer billing area for an app that already has Stripe subscriptions. Users need to see what they paid, change their card, and change their plan without emailing support. Stripe is the source of truth; this page displays it.

## Core Features (Priority Order)
1. Invoice history list: date, amount, status, hosted invoice link
2. Current plan card with change-plan and cancel ac

# Context
Build an in-app notification system: events generate notifications, delivered live to online users and waiting for offline ones, with an accurate unread count and per-type user preferences.

## Core Features (Priority Order)
1. Notification feed: newest first, unread visually distinct, mark-one and mark-all read
2. Live delivery to online sessions; queued rows for offline users, no loss 

# Context
Add first-party analytics to a landing page: enough to know traffic, source, device, conversion and drop-off, collected by your own endpoint, readable on one internal dashboard. No external analytics script.

## Core Features (Priority Order)
1. Pageview capture: path, referrer, UTM parameters, device class, timestamp
2. Conversion event tied to the page's one goal (form submit)
3. A dai

# Context
Build a support ticketing tool: requests arrive by form and forwarded email, become tickets with status and owner, agents reply from the tool with internal notes alongside, and response times are visible.

## Core Features (Priority Order)
1. Intake: a support form and an inbound email address both creating tickets with requester identity
2. Ticket lifecycle: new, open, waiting-on-custom

# Context
Build a poll tool: create a single-question poll, share a link, collect one vote per person, and show results that are honest about how many voted. Instant to answer, hard to stuff.

## Core Features (Priority Order)
1. Poll creation: question, 2-6 options, open or scheduled close
2. A public voting page: tap an option, see results immediately after
3. One-vote enforcement per visitor, s

# Context
Build an AI insights layer over an existing analytics dataset: on schedule or on demand, it queries defined metrics, detects changes worth words, and writes a short narrative where every claim cites the number behind it.

## Core Features (Priority Order)
1. Metric bindings: each insight source is a defined query with owner and description, reused from your metrics layer
2. Change detect

# Context
Add a set of public pages to this app that a search engine can index without running JavaScript. The pages come from one data file or table, one URL per entity, and each must carry enough unique text to be worth indexing. Read CLAUDE.md and the routing conventions first.

## Core Features (Priority Order)
1. A data source with one record per page: slug, title, description, body sections,

# Context
Add public pages a search engine can index without JavaScript: one data source, one URL per record, each with enough unique text to be worth indexing. Read @.cursor/rules/marketing.mdc, the routing conventions and @app/sitemap (or its equivalent) first.

## Core Features (Priority Order)
1. A data source with one record per page: slug, title, description, body sections, related slugs
2. 

# Context
Build [a tool that produces a result the user is proud of], for [audience]. Visibility: Public. The result is saved so it can be shared, and the share page must not expose anything personal.

## Entities
- Result: public_id (random, unguessable), inputs (object), output (object), created_at, user_id (optional)
- Rules: anyone creates a Result; anyone reads a Result by public_id; only the

# Context
Add follow-ups to the CRM. A follow-up is a dated next step on a contact or a deal, owned by the person who created it. The daily job is: open the app, see what is due, do it, log it, set the next one.

## Data Rules
- follow_ups: contact or deal, due date, body, owner set by the database, done_at, snoozed_until
- Shared team reads; only the owner completes, snoozes or deletes their own

# Context
Build user management for the admin dashboard. Admins can find a user, see their role and recent events, change their role through a server function that records the change, and disable an account. The kit's user_roles table has no insert policy; role changes go through a function that updates an existing row or is refused.

## Data Rules
- change_role(user, new_role, reason): admin only

# Context
Inbound leads arrive from forms and product signups. Build transparent lead scoring: named rules award points on attributes and behavior, every score is explainable, and sales works from a ranked queue instead of a chronological inbox.

## Core Features (Priority Order)
1. Rules table: condition, points, active toggle (e.g. company email +10, pricing page visit +15)
2. Score per lead com

# Context
Build a file manager: users upload by drag or picker, organize with tags, find by search and filter, and preview without downloading, with storage quotas enforced on the server.

## Core Features (Priority Order)
1. Upload: multiple files, per-file progress, cancel, clear failure states with retry
2. Tags: create, assign multiple per file, filter by tag combinations
3. Search by filename

# Context
A generated site has public pages that should rank. Build the indexability layer: sitemap.xml, per-page canonicals and titles, robots.txt, and basic structured data, all derived from the route list so nothing can drift.

## Core Features (Priority Order)
1. One route registry: path, title, description, indexable flag, content date
2. sitemap.xml generated from the registry, indexable rou

# Context
Build multi-user chat: channels and direct messages with live delivery, dependable history, correct unread counts, presence, and moderation controls, built to survive reconnects and growth.

## Core Features (Priority Order)
1. Channels: create, join, leave, member list; DMs as private two-person channels on the same model
2. Messages: send, edit with marker, delete with tombstone, live 

# Context
Build a location directory: browse and filter places on a paired map and list, with every place and every city owning a server-rendered, indexable URL. The interactive layer enhances pages; it must never replace them.

## Core Features (Priority Order)
1. A detail page per location at a stable URL: name, address, attributes, description
2. City index pages listing that city's locations, 

# Context
Build a translation tool on an AI model: text in, translation out across your supported language pairs, with a glossary that locks your product terms, tone presets, and honest handling of ambiguity.

## Core Features (Priority Order)
1. Translate: source text, target language, output beside input with copy
2. Glossary: your terms with required translations per language, injected into eve

# Context
Build the public landing page for this app in this repository: one offer, one primary action, email capture. It must render fully on the server, load fast, and store leads in a table the client can insert into but never read. Read CLAUDE.md and the existing routes first.

## Core Features (Priority Order)
1. A hero that states what the product does in plain words, with the email form abo

# Context
Build the public landing page: one offer, one primary action, email capture. It renders fully on the server and stores leads in a table the client can write but never read. Read @.cursor/rules/marketing.mdc and the existing routes first.

## Core Features (Priority Order)
1. A hero stating what the product does in plain words, with the email form above the fold
2. An insert-only leads ta

# Context
Build a newsletter app: subscribe with double opt-in, an archive where each issue is a public page, and sending from a backend function through the connected email integration, with every send logged. Visibility: Public for the archive; sending is admin-only.

## Entities
- Subscriber: email (unique), confirmed (boolean), confirm_token, unsubscribed_at, created_at
- Issue: slug, title, b

# Context
Add a public lead form that writes into the CRM. The form lives on a public page; the data goes into a leads table that the browser can insert into and never read, and an owner triages each lead into a contact and company or discards it.

## Data Rules
- leads: name, email, company name, message, source, utm_source, utm_medium, utm_campaign, referrer, created_at, triaged_at, triaged_to (

# Context
Build a moderation queue for the admin dashboard. Items enter the queue by a flag from users or a rule; a moderator with the admin role takes an item, decides, and the decision is recorded as an event. Nothing in the queue is deleted; rejected items are hidden by a status the app respects.

## Data Rules
- flags: item, reason, by, created_at; moderation_decisions: item, decision, by, rea

# Context
An app with workspaces and basic roles exists. Build the management layer: changing roles, removing members, and transferring ownership, with the rules enforced in the database and every change recorded.

## Core Features (Priority Order)
1. Member table: name, email, role, last active, joined date
2. Role changes via inline select, owner and admin only
3. Member removal with confirmatio

# Context
Build an API error tracker: failed requests are captured with context, grouped into issues by signature, counted, and worked through a simple status flow, with noise controls so the list stays meaningful.

## Core Features (Priority Order)
1. Capture: endpoint, method, status, error message, stack hash, timestamp, request id
2. Grouping: same signature (endpoint + error type + stack hash

# Context
Build a press and media page: everything a journalist needs to write about the company accurately without waiting for a reply. Facts, quotes, assets, contact, all current and all downloadable.

## Core Features (Priority Order)
1. Fact block: what the product is in one sentence, founded date, founder names, location, one-line traction statement with its as-of date
2. Approved quotes: two

# Context
Build a habit tracker: users define habits with schedules, check them off in one tap, build streaks computed against their own timezone and declared schedule, and read their history as patterns.

## Core Features (Priority Order)
1. Habits: name, schedule (daily, specific weekdays, N-times-per-week), optional reminder time
2. Check-off: one tap from the main screen, undo within the day, 

# Context
Add sharing to content that is individually worth sharing: each shareable URL gets correct social metadata, mobile gets the native share sheet, desktop gets platform links and copy-link, and the whole thing weighs nearly nothing.

## Core Features (Priority Order)
1. Per-URL Open Graph and Twitter card metadata: title, description, image, rendered server-side
2. Native share sheet via th

# Context
Build an in-product chat assistant: users ask questions, answers ground in your documentation and their account context, sources are cited, unanswerable questions escalate to a human channel gracefully.

## Core Features (Priority Order)
1. Chat UI: streaming responses, message history within the conversation, typing and error states
2. Grounding: retrieval over your docs corpus; answers

# Context
The app has auth, workspaces and roles. Add the loop that turns one user into a team: an invite link anyone in the workspace can share, attribution of who brought whom, and the confirmation that closes the loop. Read CLAUDE.md and the invite code first.

## Core Features (Priority Order)
1. A shareable invite link per workspace, copyable from the member list, with an expiry and a revoke 

# Context
The app has auth, workspaces and roles. Add the loop that turns one user into a team: a shareable invite link, attribution of who brought whom, and the confirmation that closes the loop. Read @.cursor/rules/database.mdc and the invite code first; create a checkpoint before the schema change.

## Core Features (Priority Order)
1. A shareable invite link per workspace, copyable from the me

# Context
Build landing page variants for paid traffic: one page per ad group, sharing every component, differing only in copy stored on an entity. Visibility: Public.

## Entities
- Variant: slug, ad_group, headline (must contain core_phrase), core_phrase, subline, cta_label, published
- Lead: add campaign, ad_group, click_id (gclid or fbclid), variant_slug to the existing Lead entity
- Rules: an

# Context
Add CSV import to the CRM. The user has a spreadsheet of contacts with inconsistent columns. The import must show exactly what it will do before it does it, and must be undoable as a batch.

## Data Rules
- imports: id, owner set by the database, filename, row_count, created, matched, skipped, undone_at
- Every created record carries import_id so an undo can delete exactly that batch
- I

# Context
Add a read-only view-as-user mode to the admin dashboard. An admin starts a session for one user with a reason; for 15 minutes the app renders that user's data through a server-side context, every write is blocked, a banner is visible on every screen, and the start and end are events.

## Data Rules
- view_sessions: admin, target user, reason, started_at, ended_at; created by a function,

# Context
A SaaS stores logins, feature usage, billing events and support tickets. Build a churn-risk view: a 0-100 risk score per account from weighted named signals, always shown with its reasons, plus a weekly view of who moved.

## Core Features (Priority Order)
1. Signals config: recency of login, 30-day usage trend, failed payments, seat shrinkage, ticket sentiment flag
2. Risk score per acc

# Context
Build user-visible session management: a settings page listing active sessions with device, approximate location and last activity, per-session and all-other revocation, backed by server-side session state that makes revocation take effect on the next request.

## Core Features (Priority Order)
1. Active sessions list: device summary, browser, approximate location, created, last active
2

# Context
Build a landing page targeting one search query. The searcher's intent defines the structure; the page answers it thoroughly enough to deserve the ranking, then converts attention it has earned. Server-rendered throughout.

## Core Features (Priority Order)
1. An H1 and title matched to the query's actual intent, not just its words
2. The direct answer within the first 150 words, before 

# Context
Build a task list with an AI suggestion layer: fast capture, then per-task proposals (breakdown into subtasks, priority, estimate) rendered as suggestions the user accepts, edits or dismisses, with every acceptance marked.

## Core Features (Priority Order)
1. Capture: one input, enter to add, no required fields at capture time
2. Task basics: done state, due date, notes, manual ordering

# Context
Build an internal SEO metadata editor: every page listed with its title and description, edited inline against a realistic search-result preview, validated for the errors that actually cost clicks, exportable to where the site reads it.

## Core Features (Priority Order)
1. A page list: URL, current title, current description, status flags
2. Inline editing with a live SERP-style preview

# Context
Build an API documentation generator: parse the OpenAPI spec, render per-endpoint pages with parameters, schemas, responses and runnable examples, rebuilt on spec change so drift is impossible.

## Core Features (Priority Order)
1. Spec parsing: endpoints, parameters, request/response schemas, auth requirements, with a validation report of spec gaps
2. Per-endpoint pages: description, pa

# Context
Add lifecycle email to this app: a short sequence that starts from a stored event, sent from server code through the provider named in CLAUDE.md, with every send logged. Read the leads or users table and the existing email code first.

## Core Features (Priority Order)
1. Three templates as versioned files: welcome, the one thing to do next, and a nudge if it was not done, each with a pl

# Context
Add lifecycle email: a short sequence starting from a stored event, sent through the provider named in the project rule, with every send logged. Read the leads or users table and any existing email code first; reference them with @.

## Core Features (Priority Order)
1. Three versioned template files with a plain-text part: welcome, the one thing to do next, a nudge if it was not done
2.

# Context
Add two public pages to this app: a feedback board where signed-in users post and vote, and a changelog with one entry per release. Visibility stays as it is; the two pages are readable by anyone allowed into the app.

## Entities
- Feedback: title, body, author_user_id, status (open | planned | shipped), vote_count, created_at, changelog_id (optional)
- Vote: feedback_id, user_id (uniqu

# Context
Add roles and reassignment to the CRM. Today every record is owned by its creator and only the owner can write it. A team needs an admin who can reassign records when someone leaves, and a record of every reassignment.

## Data Rules
- team_members: user, role (owner, admin, member), read from the database per request
- Reassignment is a server function callable by admins only, writing a

# Context
Add saved reports to the admin dashboard. A report is a named definition: which view or function, which window, which filters. It renders on demand, exports on a schedule, and every change to the definition is versioned so a report from March can be re-run as it was.

## Data Rules
- reports: name, definition (JSON), owner, created_at; report_versions: report, definition, saved_at, by
- 

# Context
Build a feature flag system for a multi-tenant SaaS: flags gate features by plan tier, percentage rollout, or explicit account list, evaluated server-side through one function, with an admin UI and a change log.

## Core Features (Priority Order)
1. Flags: key, description, on/off, targeting (all, plan tiers, percentage, account list)
2. One server-side evaluation function used by every 

# Context
Build a redirect manager: create short slugs on your domain pointing to destination URLs, count clicks, edit destinations without changing the public link, and keep the whole table auditable.

## Core Features (Priority Order)
1. Create redirect: slug (custom or generated), destination URL, optional note
2. The redirect itself: fast 302 by default with a per-link 301 option, explained in

# Context
Build a gated download page for one asset (guide, checklist, template pack): the visitor sees what they get, trades an email, receives it instantly, and knows exactly what follows. The gate is a fair trade, not a trap.

## Core Features (Priority Order)
1. Asset preview: table of contents or sample pages, page count, format, last-updated date
2. Capture form: email only, with a disclosur

# Context
Build a booking system: visitors pick a service, see genuinely available slots in their timezone, book with an atomic hold that makes double-booking impossible, and manage their booking through links that respect your notice rules.

## Core Features (Priority Order)
1. Services: name, duration, buffer before/after, active hours per weekday
2. Slot display: available times computed from h

# Context
Build the site navigation shell: a responsive navbar that collapses to a menu on small screens, communicates location, and behaves perfectly for keyboard and screen-reader users. Every page inherits this; build it like it is load-bearing, because it is.

## Core Features (Priority Order)
1. Desktop bar: logo home link, five or fewer items, one primary action visually distinct
2. Mobile c

# Context
Build an image captioning tool: upload images singly or in batch, generate alt text and longer descriptions to defined style rules, flag low-confidence results for review, and export in useful formats.

## Core Features (Priority Order)
1. Upload: single and batch with per-image progress and format validation
2. Two outputs per image: alt text (under 125 characters, subject-first) and a 

# Context
Add analytics to this app that you own: a fixed list of named events, a server-side sink that writes them to a table, and a page that turns them into a funnel. Third-party tools can be added later; the table is the source of truth. Read CLAUDE.md and the routes first.

## Core Features (Priority Order)
1. An events data file: name, required properties, and the step of the funnel it belon

# Context
Add analytics this repository owns: a fixed list of named events, a server-side sink writing to a table, and a page turning them into a funnel. Third-party tools come later; the table is the source of truth. Read the routes and @.cursor/rules/database.mdc first.

## Core Features (Priority Order)
1. An events data file: name, required properties, and the funnel step it belongs to (visit,

# Context
Add analytics this app owns: one Event entity, a fixed list of event names, a backend function that records them, and an admin funnel page. Third-party tools can come later; the entity is the source of truth.

## Entities
- Event: name (enum: page_view, signup, activate, invite_sent, invite_accepted, purchase), user_id, session_id, source, properties (object), created_at
- Rollup: date, 

# Context
Add reports to the CRM, computed in the database from stage_history, deals, notes and follow_ups. Every number must be reproducible from the rows; no client-side arithmetic on partial data.

## Data Rules
- Aggregates are database views or functions with a date range parameter
- Reports respect the same read policies as the underlying tables
- Money is integer cents summed in the databas

# Context
Add alerts to the admin dashboard. An alert rule names an allow-listed metric, a comparison (above, below, change over a window) and a threshold; a scheduled function evaluates every rule, writes an alert_fired event when one crosses, and shows it in-app until acknowledged.

## Data Rules
- alert_rules: name, metric (allow-listed), comparison, threshold, window, owner, enabled
- alert_fi

# Context
An app with paid plans needs promo codes: created by an admin, redeemed at checkout, honest about expiry, and resistant to the usual abuse. Codes influence price only at the moment of payment, server-side.

## Core Features (Priority Order)
1. Admin creation: code, type (percent or fixed), applicable plans, max redemptions, expiry
2. Redemption field at checkout with instant server valid

# Context
Build an inventory tracker where current stock is the sum of movements: receipts, sales, adjustments and transfers are recorded events with actor and reason, and totals are derived, never edited directly.

## Core Features (Priority Order)
1. Item catalog: SKU, name, unit, location, reorder threshold
2. Movements: receive, remove, adjust, transfer between locations, each with actor, time

# Context
Build a pricing page for two or three plans: what each costs, what genuinely differs, which one fits whom, and answers to the questions that stall purchases. Every number on it must match what the product enforces.

## Core Features (Priority Order)
1. Plan cards: price, billing unit, the three differences that matter, one CTA each
2. A recommendation with a reason ('most solo builders s

# Context
Build a member directory: members complete profiles with per-field visibility choices, browse and search each other by skills, location and interests, and connect through the directory without exposing contact details until they choose to.

## Core Features (Priority Order)
1. Profiles: name, photo, headline, skills tags, location, links, about, each field with a visibility toggle (membe

# Context
Build the site's error surfaces: a 404 that recovers the visit, a generic error boundary that protects user work, and an offline state. These pages meet users at the worst moment; their quality is disproportionately remembered.

## Core Features (Priority Order)
1. 404 page: what happened in one line, search box, and links to the three most useful sections
2. Correct status codes: true 4

# Context
Build a research assistant: a question spawns a research run that gathers from configured sources, extracts relevant passages, and composes an answer where every claim links to its supporting quote.

## Core Features (Priority Order)
1. Research runs: question in, status through gathering, extraction and composition, answer out
2. Source panel: every document consulted, with the exact pa

# Context
Add two public pages to this app: a changelog written from merged pull requests, and a feedback board where signed-in users post and vote. Both render on the server and both are part of the sitemap. Read CLAUDE.md and the public routes first.

## Core Features (Priority Order)
1. A changelog data file appended by a skill that reads merged PRs since the last entry and drafts one entry per

# Context
Add two public pages: a changelog written from merged pull requests and a feedback board where signed-in users post and vote. Both render on the server and both are in the sitemap. Read the public routes and @.cursor/rules/marketing.mdc first.

## Core Features (Priority Order)
1. A changelog data file, appended by a manually applied rule that reads merged PRs since the last entry and dr

# Context
Build companion pages for videos: each video promises an artifact (a checklist, a template, a calculator) and this app delivers it at a short URL. Visibility: Public.

## Entities
- Companion: slug (short, lowercase, no dashes), video_title, platform, artifact_type, artifact (object or file), gated (boolean), next_step_label, next_step_url, published
- Lead: add companion_slug to the exi

# Context
Add stage playbooks to the CRM. When a deal enters a stage, a template creates the tasks that stage requires; the deal page shows the checklist; a stage cannot be marked complete with required tasks open, though it can always be moved back.

## Data Rules
- stage_templates: stage, task title, required (boolean), days_offset, editable by admins
- deal_tasks: deal, title, required, due dat

# Context
Add a table editor to the admin dashboard for a named list of tables. Each table in the config declares its editable columns, read-only columns, and whether soft delete is allowed. Every edit is written as an event with the row id, the column, the old value and the new value.

## Data Rules
- The config is code: table name, columns, editability, soft-delete column; nothing is discovered 

# Context
An app with a catalog and user behavior events (views, saves, purchases) needs recommendations: a personal shelf per user, similar-item rows on detail pages, and an explicit fallback ladder so no surface is ever empty.

## Core Features (Priority Order)
1. Event capture: view, save, purchase per user per item, timestamped
2. A 'For you' shelf: recency-weighted category and attribute affi

# Context
Build API rate limiting with an admin dashboard: per-key request limits over sliding windows, standard limit headers on every response, correct 429 behavior, and a view showing consumption and violations per key.

## Core Features (Priority Order)
1. Limit enforcement: requests per window per API key, sliding window counting
2. Response headers on every request: limit, remaining, reset t

# Context
Build a social-proof page assembling verifiable customer evidence: quotes, results and logos, each with provenance. This page's entire value is credibility, so its design constraint is verifiability, not volume.

## Core Features (Priority Order)
1. Featured quotes: full name, role, company, photo where permitted, each with permission on record
2. Result statements with context: what cha

# Context
Build a simple blog CMS: write in markdown with live preview, manage drafts and scheduled publishing, and serve posts as fast server-rendered pages with the metadata, feed and sitemap that make content findable.

## Core Features (Priority Order)
1. Editor: markdown with preview, title, slug (editable before first publish, locked after), excerpt, cover image
2. States: draft, scheduled w

# Context
Build the page frame: one header component and one footer component used by every page, with clearly defined slots for the few things that vary. The footer is a working surface, not a copyright afterthought.

## Core Features (Priority Order)
1. Header: brand, primary nav slot, action slot, consistent height, server-rendered
2. Footer: grouped link columns (product, resources, company, l

# Context
Add social login to an app: two OAuth providers with correct flows, account creation and linking rules by verified email, coexisting with email/password, with every edge case given a decided behavior.

## Core Features (Priority Order)
1. Sign in with Google and one more provider fitting your audience, standard OAuth authorization-code flow
2. Account rules: new social sign-in with an em

# Context
Add sales signals to this app: a score per workspace from activity and growth, a summary page per account that a maintainer can read before a call, and a weekly digest. Read CLAUDE.md, the analytics rollup and the workspace schema first.

## Core Features (Priority Order)
1. A score per workspace computed nightly from the rollup: active members in 7 and 30 days, seats added in 30 days, k

# Context
Add sales signals: a score per workspace from activity and growth, a summary page per account a maintainer reads before a call, and a weekly digest. Read the analytics rollup, the workspace schema and @.cursor/rules/database.mdc first.

## Core Features (Priority Order)
1. A nightly score per workspace: active members in 7 and 30 days, seats added in 30 days, key actions per member, days

# Context
Add sales signals: a score per Workspace from activity and growth, an admin page sorted by it, a summary per account, and a weekly digest. Everything here is admin-only.

## Entities
- AccountScore: workspace_id, date, active_7d, active_30d, seats_added_30d, actions_per_member, days_since_activity, score
- Rules: only admins read AccountScores; only the scoring function creates them

## 

# Context
Add win-loss capture to the CRM. Closing a deal, won or lost, requires a reason from a short list plus free text; lost deals record who or what they were lost to. A review page groups the last quarter's closes so the team can read the pattern.

## Data Rules
- close_reasons: a small admin-editable list with a type (won or lost)
- deals gain reason_id, lost_to (text), close_notes; set onl

# Context
Add an activation funnel to the admin dashboard. The funnel is an ordered list of event names, defined by an admin, with sign-up as the first step and the activation event as the last. A function computes, per sign-up cohort week, how many users reached each step, respecting the caller's role.

## Data Rules
- funnels: name, steps (ordered event names), owner; computed by a function with

# Context
An app knows which three actions predict whether a new user sticks. Build an onboarding checklist that drives those actions, verifies them from live events, and gets out of the way when done.

## Core Features (Priority Order)
1. A checklist of 3 to 5 steps, each mapped to a verifiable product event
2. Auto-completion: doing the thing checks the step, wherever it was done
3. Progress per

# Context
Build a background job monitor: jobs report state transitions to a registry, the dashboard shows queues, running jobs, durations and failures, and dead jobs sit in a queue where a human can inspect, retry or discard them.

## Core Features (Priority Order)
1. Job registry: type, payload summary, state (queued, running, succeeded, failed, dead), timestamps, duration
2. Queue view: depth a

# Context
Build a waitlist page for a pre-launch product: explain what is coming and when, capture emails with source attribution, confirm honestly, and keep the list unreadable from the client. Clarity converts here; vagueness reads as vapor.

## Core Features (Priority Order)
1. Hero: what the product is in one concrete sentence, and the expected launch window
2. What joining gets you: early acc

# Context
Build a reusable file upload component: drag-drop and picker input, instant local previews, per-file progress with cancel and retry, validation before and after transfer, and an interface other features consume.

## Core Features (Priority Order)
1. Input: drag-drop zone with keyboard-accessible picker fallback, multi-file
2. Local previews immediately on selection: image thumbnails, PDF

# Context
Build the settings area: profile, preferences, notifications and account sections, navigable and predictable, where every change communicates its save state and destructive actions cannot be stumbled into.

## Core Features (Priority Order)
1. Sectioned layout: sidebar navigation on desktop, collapsible sections on mobile
2. Auto-save per control with visible saved-state confirmation, no