Claude Code prompts

Create a new SaaS starter in {{language}} in an empty directory: auth, billing scaffolding, and a protected app shell. Include email-plus-password signup with verification tokens stored in {{database}}, session handling via httpOnly cookies, an organizations table with a member role column (owner, admin, member), and route guards that redirect unauthenticated users to /login. Stub billing with a plans table and a checkout redirect placeholder so a payment provider can slot in later. Add {{addon}} as an optional integration behind a feature flag read from env. Ship a seed script that creates a demo org and two users, plus a README section documenting env vars. Cover the auth flow with tests: signup, duplicate email rejection, expired verification token, and role-gated access. Initialize git, run the seed and the tests, and finish with a tree of the directories you created.

Scaffold a to-do app in {{language}} in the current directory. Data model: tasks with id, title, notes, due_date, done, created_at, persisted in {{database}}. Build a small API layer plus a minimal web UI: list view grouped by Today, Upcoming, and Done, inline add, toggle, and delete. Edge cases: empty title rejected with a validation message, due dates in the past flagged, toggling done sets a completed_at timestamp. Write the schema migration first and run it. Add tests for create, toggle, and delete, then run the full suite and show me the output. For the persistence check, start the dev server in the background, add a task with curl, kill the server, restart it in the background, and curl the list endpoint to show the task survived. Then kill the server and print a summary of every file you created.

Build a blog in this repo with a git-based CMS: posts live as Markdown files with frontmatter in content/posts, no external service. Frontmatter fields: title, slug, date, tags, draft. Build the pipeline in {{language}}: parse frontmatter, render Markdown with code-block syntax highlighting, generate an index page sorted by date, tag pages, an RSS feed at /feed.xml, and per-post OpenGraph meta tags. Drafts must be excluded from the production build but visible in dev. Add two valid sample posts, one draft and one published. Do not commit broken posts: the tests should write their own fixtures into a temp directory, two posts sharing a slug and one with malformed frontmatter, and assert the pipeline rejects each with a clear error. Also cover a valid post with no tags. Run the production build, list every generated route, and confirm the draft appears nowhere in the output directory by grepping the build folder for its slug.

Build an internal admin panel in this repo for managing {{resource}} records. Generate it from the existing schema: read the models or migrations first and list the entities and fields you found before writing UI. Features: table views with server-side pagination, sorting, and a filter bar; a detail view with inline edit; soft delete with a restore action; and an audit log table recording who changed what, written on every mutation. Guard the whole thing behind the app's existing auth with an admin role check at the route level, not per component. No new UI framework; use what the repo already renders with. Seed a dev admin user in a script I can run. Write tests for the role check, one paginated list, and the audit write, run them, then start the app and print the admin URL and the seeded login so I can click through.

You are a terminal agent, so investigate before coding: list the repo tree and read any router or error-handling modules already present. Then build CRUD for {{resource}} in {{language}} on top of {{database}}. Routes: POST returning 201, GET by id returning 404 when absent, PATCH, DELETE returning 204, and a collection route driven by cursor and limit parameters for keyset paging. Reject malformed bodies with a 400 that itemizes each failing field; answer 409 when a unique column would collide. Also deliver a table migration, a pooled connection module, and GET /healthz that round-trips {{database}}. Place new code under src/ using conventions the project already follows, or establish sensible ones. Apply the migration, write integration coverage for a full create-read-update-delete cycle, a rejected payload, a missing id, and a cursor fetch of page two, then run everything from the shell and keep iterating until green. Close with a summary of files touched.

Add a GraphQL API to this repo in {{language}}. Define the schema first in schema.graphql: a Query type with paginated lists, a Mutation type for create and update, and one connection-style type for {{resource}} with cursor pagination. Wire resolvers to {{database}} with a dataloader per parent-child relation so nested queries do not N+1. Reject queries deeper than 6 levels and add a 30-second timeout per operation. Before writing resolvers, run the schema through the linter or validation step and fix any errors. Then write resolver tests covering pagination cursors, a nested query, and a mutation with invalid input. Run the tests. Finally start the server, POST an introspection query with curl, and paste the type names returned so I can confirm the schema is actually being served.

Add JWT authentication to the existing API in this repo. Read the current route structure first and tell me which routes you will protect before touching code. Implement: a login endpoint that verifies credentials against {{database}} and returns a short-lived access token plus a rotating refresh token stored server-side, middleware that validates signature, expiry, and audience on protected routes, and a logout that revokes the refresh token. Sign with an algorithm read from config, key from an environment variable; refuse to start if the variable is missing. Never log tokens. Write tests for: expired token rejected, tampered signature rejected, refresh rotation invalidates the old refresh token, and logout blocks reuse. Run the suite, then hit a protected route with curl three ways, no token, bad token, fresh token, and paste all three responses.

Design and apply a Postgres schema for this app's {{resource}} domain. Read the application code first and derive entities from how the code actually uses data, then show me an entity list with relationships before writing SQL. Rules: every table gets a bigint identity or uuid primary key, created_at and updated_at with a trigger for the latter, foreign keys with explicit ON DELETE behavior chosen per relation and justified in a comment, NOT NULL by default, and CHECK constraints for enums instead of raw text. Write it as numbered migration files that apply cleanly to an empty database. Include indexes only for lookups the code performs today, each with a comment naming the query it serves. Apply the migrations to a local database, run \d on each table, and paste the output. Finish with a rollback test: migrate down and up again without errors.

Add search over {{resource}} records to this codebase. Backend: a GET /search endpoint accepting q, page, and a filter param for status, returning ranked matches with a total count. Use {{database}} native text search (an ILIKE fallback is fine below a few thousand rows); note in a comment where to swap in a dedicated index later. Sanitize the query string, cap its length at 200 characters, and return an empty result set for blank input rather than an error. Frontend: a debounced input (about 300ms) in the existing header, a results list with the matched term highlighted, an explicit no-results state, and cancellation of stale in-flight requests so a slow early response cannot overwrite a newer one. Tests: relevance ordering on a seeded fixture, the blank-query case, and a special-characters query such as O'Brien. Run everything, then list changed files grouped by backend and frontend.

Integrate a streaming LLM chatbot into this app. Read the existing code first and list where the chat UI, API route, and provider client should live before writing anything. Requirements: a server-side route that streams tokens to the client over SSE, chat history stored in {{database}} keyed by conversation id, the provider API key read from an environment variable and never bundled client-side. Add a system prompt file at prompts/system.md so it can be edited without a deploy. Handle three failure paths distinctly: provider timeout, rate limit response, and a mid-stream disconnect that keeps the partial transcript. Write an integration test that mocks the provider and asserts the stream terminates cleanly. Run the test suite, then grep the built client bundle for the key variable name to prove no leak, and list every file you touched.

Add transactional email notifications to this app for {{resource}} events. Architecture: an outbox table in {{database}} written in the same transaction as the triggering change, a worker that polls the outbox and sends through the provider SDK, and a sent_at plus attempt count on each row so retries are bounded and idempotent. Templates live in emails/ as plain files with a subject line and text plus HTML parts; no template strings inline in application code. In development, route everything to a local capture that writes the rendered emails to disk instead of sending. Failure handling: provider errors requeue with backoff, permanently failing rows land in a dead-letter state I can query. Write tests that assert exactly one email per event even when the worker runs twice. Run the tests, then trigger one event locally and show me the rendered file on disk.

Build a dashboard page in this codebase's existing frontend stack that surfaces {{resource}} metrics. Layout: a stat row with four summary cards (total, active, created this week, error count), a time-series chart of {{resource}} activity over the last 30 days, and a sortable table of the 20 most recent records with status badges. Fetch data through a typed client module rather than inline fetch calls, and handle three states per widget: loading skeleton, empty dataset with a short explanation, and fetch failure with a retry button. Keep the chart dependency-light; use whatever charting library is already installed before adding one. Make the grid collapse to a single column below tablet width. Add a component test for the table's sort behavior and the empty state. Run the dev build and the tests, then summarize the components you added and where they mount.

Build a single-file-per-section landing page in this repo for {{resource}}. Sections, in order: hero with one headline and one call to action, a three-item feature row, a code or product snippet block, a social proof placeholder, and a footer with real nav links. Constraints: semantic HTML landmarks, no client-side JavaScript unless a section needs it, all images with explicit width and height to prevent layout shift, and a single accent color defined once as a CSS variable. Mobile first; the layout must work at 320px wide. When done, run the production build, report the total CSS and JS payload from the build output, and run any link checker or HTML validator available in the repo. List each section file created and flag any copy you invented as placeholder so I can replace it.

Build a pricing page for {{resource}} in this repo, matching the existing layout conventions; read a current page first and reuse its shell. Content: three tiers with a monthly and annual toggle, annual showing the per-month equivalent, a feature comparison table with row groups, and one FAQ block below the fold. Pricing data lives in a single pricing.ts or equivalent config file, no amounts hardcoded in markup, so a price change is a one-line diff. The toggle must work without layout shift and default to annual. Mark the recommended tier with a data attribute, not just styling, so tests can target it. Add a test that renders each tier from config and fails if a tier is missing a price or call to action. Run the test and the production build, and list the files changed with a one-line reason for each.

Take the largest component in this codebase (or the file I name) and refactor it without changing its observable behavior. First run the test suite and record the baseline; if the component lacks tests, write characterization tests for its current rendering and event behavior before touching it. Then split by responsibility: extract data fetching into a hook or service, pull pure display sections into child components with explicit props, move duplicated conditional logic into named helper functions, and hoist inline styles and magic values to constants. Do not rename public props or exported symbols, and do not alter DOM structure that tests or styles select on. Work in steps small enough that the suite passes after each extraction. When finished, run the full suite and the type checker, then report the component's before-and-after line counts and each new file's responsibility.

Migrate this JavaScript codebase to TypeScript incrementally, keeping the app buildable after every step. First add tsconfig.json with allowJs and checkJs enabled and strict off, run the compiler, and report the baseline error count. Then convert files in dependency order, leaf modules first: rename with git mv so history survives, add explicit types for exported functions, and use unknown instead of any at module boundaries. Do not change runtime behavior; if a bug surfaces during typing, note it in a TODO comment instead of fixing it silently. After each batch of ten files, run tsc and the existing test suite and stop if either fails. Once every file is converted, turn on strict, fix what breaks, and give me the final tsc output plus a list of any remaining any types with file and line.

Find and fix the slowest database queries in this app. Start with evidence, not guesses: enable query logging or the ORM's debug output, run the existing test suite or a local traffic script to generate load, and collect the queries actually executed. Rank them by count times cost and show me the top offenders with their EXPLAIN or EXPLAIN ANALYZE output before changing anything. Typical fixes I expect: N+1 loops collapsed into joins or batched IN queries, missing indexes added through a proper migration file, SELECT star trimmed to needed columns, and pagination converted from OFFSET to keyset where tables are large. One fix per commit with the before and after EXPLAIN in the commit message. Re-run the same workload after each fix and confirm the query count dropped or the plan changed; never claim an improvement without showing the plan.

Write unit tests for the untested modules in this codebase. Start by running the existing test command with coverage to find the gaps, then prioritize pure logic: parsers, formatters, price or date calculations, permission checks. For each target module write cases for the documented behavior, boundary inputs (empty arrays, zero, negative numbers, unicode strings), and the error paths that throw or return early. Mock only true externals like network and filesystem; do not mock the module under test's own collaborators unless construction is impractical. Match the assertion style already used in the repo. Skip snapshot tests unless one already exists for that area. After writing each file, run it in isolation, then run the whole suite to confirm nothing else broke. Finish with a short table: module, cases added, and uncovered branches that still remain with the reason.

Write end-to-end tests for this app's critical paths using the E2E framework already in the repo, or Playwright if none exists. Start by reading the routes and listing the flows you plan to cover; wait for my confirmation before writing tests. Cover at minimum: signup or login, the primary create-and-save flow, and one destructive action with its confirmation dialog. Rules: no fixed sleeps, use web-first assertions or explicit waits; each test seeds its own data through the API or a fixture, never through another test; everything must pass in headless mode from the command line. Add an npm or make target that boots the app, waits for the health endpoint, runs the suite, and tears down. Run it twice back to back and report both results so we know the tests are not order-dependent or flaky on first sight.

Audit this codebase for missing error handling, then fix it in order of blast radius. First produce the audit: grep for empty catch blocks, unhandled promise rejections, fetch or database calls without a failure path, and absent process-level handlers. Show me the list ranked by user impact before changing code. Then apply fixes: every external call gets a typed error or result wrapper, user-facing failures get a message that states what to retry, internal failures get structured logs with enough context to reproduce, and nothing swallows an error silently. Do not wrap everything in one giant try block. For each fix, add a test that forces the failure, network refused, bad JSON, constraint violation, and asserts the handled behavior. Run the suite and paste the failing-then-passing output for at least the three highest-impact fixes.