Cursor prompts

Scaffold a SaaS starter in a new project using {{language}} and {{database}}. Set up authentication with email plus password and OAuth, organizations with role-based membership (owner, admin, member), and subscription billing via {{addon}} with a webhook handler that updates the local subscription record idempotently, verifying signatures and handling out-of-order events. Build three areas: a public marketing page, an authenticated app shell with settings and team management (invite by email, revoke, change role), and a minimal admin view of organizations. Enforce authorization at the data layer, not just the UI, so a member cannot hit an owner-only endpoint directly. Write a test that requests an owner-only endpoint with a member's session token and asserts it returns 403. Seed a demo org and user, document required environment variables in .env.example, then run the test suite and the app, exercise signup through checkout in test mode, and list the directory structure you created.

Scaffold a to-do app in this workspace using {{language}} with {{database}} for persistence. Create three parts: a tasks table or collection with id, title, done, and created_at, a data layer in src/lib/tasks with create, toggle, and delete functions, and a single list view at the app root. The list needs an input that adds on Enter, a checkbox that toggles done with an optimistic update, and a delete button that skips confirmation but supports undo for five seconds. Handle the empty state with a short line of copy, not a blank screen. Do not add auth, folders, or tags. Write one test file covering the three data layer functions, nothing UI level. When finished, run that test file from the integrated terminal, start the dev server to confirm a clean compile, then list every file you created or changed so I can review each diff before accepting.

Build a blog where the CMS is the repo: posts live as Markdown files with frontmatter in content/posts, no external CMS service. Frontmatter fields are title, slug, date, draft, and tags. Generate three things: an index page listing published posts newest first, a post page at /blog/[slug] rendering Markdown with syntax highlighting for code blocks, and an RSS feed at /rss.xml. Drafts must be visible in dev and excluded from the production build, and I want a test asserting a draft slug returns 404 in production mode. Validate frontmatter at build time and fail the build with the offending filename when a field is missing. Do not add comments, search, or an admin UI. Verify with a production build in the terminal using two sample posts and one draft, then list the generated routes and every new file.

Build a REST API for managing {{resource}} records in {{language}}, using the framework already in this codebase, or scaffold a minimal new project if none exists. Implement five endpoints: GET /{{resource}} with pagination (limit and offset query params, default limit 20, max 100), GET /{{resource}}/:id, POST, PUT or PATCH, and DELETE. Validate request bodies at the boundary and return 400 with a field-level error list, 404 for unknown ids, and 201 with a Location header on create. Store data in {{database}} behind a small repository layer so handlers stay thin. Add integration tests covering the happy path plus invalid payloads and missing ids, then run the test suite and list every file you created or changed.

Add a GraphQL API to this codebase in {{language}}. Define a schema with a {{resource}} type, queries for a single item by id and a paginated list using cursor-based connections (edges, nodes, pageInfo with hasNextPage and endCursor), and mutations for create, update, and delete that return the affected object plus a userErrors array instead of throwing on validation failures. Back the resolvers with {{database}} and add a dataloader for any nested field that would otherwise trigger N+1 queries. Reject queries deeper than 6 levels and cap the first argument at 100. Enable the playground only outside production. Write resolver tests that assert the batching actually happens by counting executed queries, run them, and summarize the schema and resolver files you touched.

Add JWT authentication to the existing API in this repo. Create POST /auth/register and POST /auth/login endpoints that hash passwords with bcrypt or argon2, never plaintext, then issue a short-lived access token (15 minutes) and a refresh token (7 days) stored as an httpOnly, Secure, SameSite=Strict cookie. Add middleware that verifies the access token signature and expiry, attaches the user to the request, and returns 401 with a WWW-Authenticate header on failure rather than 500. Include POST /auth/refresh with refresh token rotation and a revocation check against {{database}}. Read the signing secret from an environment variable and fail fast at startup if it is missing. Cover expired tokens, tampered signatures, and reuse of a rotated refresh token in tests, run them, and list changed files.

Design a Postgres schema for {{resource}} in this project and write it as versioned migrations using the migration tool already present, or add a lightweight one and note why you chose it. Use bigint identity primary keys, timestamptz created_at and updated_at with a trigger or ORM hook keeping updated_at current, NOT NULL plus CHECK constraints where the domain demands them, and foreign keys with an explicit ON DELETE choice per relationship rather than a blanket CASCADE. Add unique indexes for natural keys and partial indexes for common filtered queries, for example WHERE deleted_at IS NULL if soft deletes are used. Generate both up and down migrations, apply them to a local database, run the rollback once to prove the down path works, then print the final schema for each table.

Add rate limiting to the API in this codebase. Implement a sliding window limiter keyed on authenticated user id when present, falling back to client IP taken from the leftmost trusted X-Forwarded-For entry only when a proxy is configured. Store counters in Redis if the project already runs it; otherwise use an in-memory store and flag in a comment that it will not work across multiple instances. Default to 100 requests per minute per key, overridable per route, with stricter caps on login and password reset endpoints to slow credential stuffing. Return 429 with Retry-After and RateLimit-Remaining headers, and exclude health check routes. Write tests that fire requests past the threshold, assert the 429 and header values, confirm the window resets, then run the full suite.

Build a file upload endpoint in this codebase in {{language}}. Accept multipart/form-data on POST /uploads, stream the file to disk or S3-compatible storage rather than buffering it in memory, and enforce a 10 MB size cap that aborts the stream early instead of reading the whole body first. Validate file type by magic bytes, not extension or client Content-Type, allowing only png, jpeg, and pdf. Generate a random storage key, never trust the original filename, and strip path separators before persisting metadata (original name, mime type, size, storage key) to {{database}}. Return 201 with the file id and an expiring download URL, 413 for oversize, and 415 for disallowed types. Add tests uploading a valid image, an oversized file, and an exe renamed to .png, then run them and report results.

Add role-based access control to the existing API in this repo. Read the current auth middleware first and reuse its session or token parsing, do not build a second auth path. Define three roles, admin, editor, and viewer, in a single roles module, and add a requireRole guard that returns 403 with a JSON error body when the check fails and never reveals whether the {{resource}} exists. Apply the guard so viewers get read-only access, editors can write, and only admins reach delete and user management routes. Store the role on the user record in {{database}} with a migration that defaults existing users to viewer. Write tests covering each role against one read, one write, and one delete route, run the full suite in the terminal, and show me the diff per file before I accept.

Integrate Stripe checkout into this backend for a single paid {{resource}}. Three pieces only: a POST /api/checkout route that creates a Checkout Session server side with the price id from an environment variable, a success and cancel page pair, and a POST /api/webhooks/stripe handler. The webhook must verify the stripe-signature header against the raw request body, watch for framework body parsing that consumes it first, and handle checkout.session.completed idempotently so a replayed event never grants access twice. Record fulfillment in {{database}} keyed by the Stripe event id. Never treat the success page redirect as proof of payment, fulfillment happens only in the webhook. Test with the Stripe CLI: run stripe listen in the integrated terminal, trigger a test event, and show me the log line proving the handler fired exactly once. List every changed file when done.

Add search for {{resource}} to this app end to end. Backend: a GET /search endpoint taking q, limit, and offset that uses {{database}} full-text search (tsvector with a GIN index in Postgres, or the configured engine's equivalent) rather than LIKE '%term%' table scans, escapes user input, and returns ranked results with a total count. Frontend: a search input with a 300ms debounce, cancellation of stale in-flight requests so a fast typist never sees older results overwrite newer ones, a loading indicator, an empty state that echoes the query, and keyboard navigation through results. Enforce a two character minimum on both client and server. Add a test for ranking (exact title match beats body match) and one for the debounce, then run everything and list the endpoints and components you touched.

Integrate an LLM chatbot into this app behind a single POST /api/chat endpoint. Keep the provider API key server side, read it from an environment variable, and fail with a clear message at startup if it is missing rather than at the first request. Stream tokens to the client over server-sent events and render them incrementally in a chat panel component, with a stop button that aborts the fetch. Persist conversation history per session in {{database}} and send only the last ten messages as context. Put the system prompt in its own versioned file, prompts/chat-system.txt, not inline in code. Add one test that mocks the provider and asserts the endpoint streams and stores messages. Run lint and tests in the terminal, then list changed files with a one-line reason for each.

Add transactional email notifications to this app for three events: signup welcome, password reset, and a weekly summary of {{resource}} activity. Build a thin mailer module with one send function so the provider SDK is imported in exactly one file and stays swappable. Templates are code, not strings inside handlers: one file per email under emails/, each exporting a subject and HTML plus a plain text fallback. In development, send nothing, write each rendered email to .dev-mail/ as an HTML file I can open. Sending must be fire-and-forget from request handlers, a failed send may never fail the user's request, log it instead. The weekly summary runs from its own cron entry point script, not inside the web process. Add tests asserting each template renders with sample data. Run the tests, then list new files and every handler you modified.

Build a dashboard page in this codebase using the existing component library and styling approach; check for Tailwind, CSS modules, or styled-components before writing anything. Lay out a header with a date range picker, four stat cards showing {{resource}} metrics with a delta versus the previous period, one line chart, and a recent activity table with client-side sorting. Fetch data through a single typed hook per widget so each region renders independently with its own skeleton state, an error state with a retry button, and an empty state with real copy rather than a blank div. Collapse the grid to one column below 768px. Do not add a charting library if one is already installed. When done, start the dev server, verify there are no console errors, and list the components you added.

Build a single landing page at the site root for {{resource}}. Structure: a hero with one headline, one subline, and one primary call to action, a three-item feature section, a short how-it-works list, and a footer with links. Pull colors and spacing from the existing Tailwind config or CSS variables in this repo, do not introduce a second design system. All copy must be real text I gave you or a clearly marked TODO comment, never lorem ipsum. Make it responsive down to 360px wide with the hero readable without scrolling on a laptop viewport. No carousel, no animation library, no cookie banner. Verify by running the production build in the terminal and confirming it exits with code zero and no errors or warnings in the build output, then show me the component tree you created as a list so I can review the diffs in order.

Build a pricing page at /pricing driven entirely by one config file, src/pricing.config.ts, so plan changes never touch markup. The config defines three tiers with name, monthly and annual prices, a feature list, and a call-to-action href, plus one tier flagged as highlighted. Render tier cards from that config with a monthly and annual toggle that swaps prices without layout shift, reserve width for the longest price string. Below the cards, generate a feature comparison table from the same config, with an accessible caption and proper th scope attributes. The highlighted tier gets its visual treatment from existing theme tokens in this repo, not new colors. No modal, no currency switcher, no fake countdown. Verify by editing one price in the config and confirming both the card and the table update, run the production build, and list the files you created.

Refactor the large component I point you at without changing its observable behavior. Start by listing its responsibilities; anything beyond rendering (data fetching, form state, derived calculations, event wiring) becomes a candidate for extraction. Pull data access into a custom hook, move pure logic into plain functions in a separate file so they are testable without a DOM, and split the JSX into child components only where a chunk has a clear name and owns its props. Keep prop drilling shallow; introduce context only when three or more levels pass the same value. Preserve the public props interface exactly so no call sites change. If tests exist, run them before and after and diff the results; if none exist, write a characterization test for the main render states first. Finish with a summary of extracted files and line counts before and after.

Migrate this repo from JavaScript to TypeScript incrementally, not in one pass. Start by adding tsconfig.json with allowJs true and strict false, wire the build so mixed JS and TS compiles, and commit that as the baseline. Then convert files in dependency order, leaf utilities first, entry points last, renaming to .ts or .tsx and typing exported function signatures fully while letting locals stay inferred. Never use any to silence an error, use unknown plus a narrowing check or a TODO type alias I can grep for. Do not change runtime behavior, if a refactor is tempting, leave a comment instead. After each batch of about ten files, run tsc --noEmit and the test suite in the terminal and stop if either fails. Finish by flipping strict to true and reporting every remaining error grouped by file.

Write unit tests for the module I have open, or ask me which file if nothing is selected. First read the module and its imports to map every branch: happy paths, error paths, boundary values, and early returns. Use the test runner already configured in this repo and match its existing describe and naming conventions. Mock only true externals such as network, clock, and filesystem; do not mock the module under test or pure helpers it calls. Cover at minimum each public function, one edge case per conditional (empty input, null, zero, largest allowed value), and thrown errors asserted by type and message. Avoid snapshot tests for logic. Run the suite with coverage, report uncovered lines, and add cases until every branch of the public API is exercised or you explain why a line is unreachable.

Write end-to-end tests for the critical paths of this app using Playwright. First read the routing and the auth flow, then propose the flows before writing any code. I expect signup, login, the primary create flow for {{resource}}, and logout at minimum. Put specs in e2e/, one file per flow, using data-testid selectors, and add those attributes to components where stable selectors are missing, never select on text or CSS classes. Seed and clean test data through the app's own API in beforeEach, not direct database writes. Each spec must pass headless and leave no residue rows. Add a fixture for an authenticated context so login runs once, not per test. Run the whole suite from the integrated terminal, paste the summary output, and list every component you touched to add test ids so I can check nothing user-visible changed.