Vibe coding prompts

Spec-first app kickoff

Any frontier model; works in Cursor, Claude Code, Windsurf

Variables: ideausersstack

You are a senior engineer starting a new project with me. Before writing any code, produce a short build spec.

Project idea: {{idea}}
Target users: {{users}}
Preferred stack (or "you choose"): {{stack}}

Write:
1. One-paragraph product summary.
2. MVP feature list (max 7), each with a one-line acceptance test.
3. Explicit out-of-scope list.
4. Data model (entities + key fields).
5. File/folder structure.
6. Step-by-step build plan in small commits, each independently runnable.
7. Open questions you need me to answer.

Do not write code yet. Wait for my "go".

One small step at a time

Reduces runaway edits in agent mode

Variables: step_numberstep_description

Implement only step {{step_number}} of the plan we agreed: "{{step_description}}".

Rules:
- Touch the fewest files possible. List the files you will change before changing them.
- Don't refactor, rename or reformat anything unrelated.
- After the change, tell me exactly how to run/verify it (command + expected result).
- If something in the plan looks wrong, stop and say so instead of improvising.

Turn a screenshot into a component

Needs a vision-capable model

Variables: frameworkstyling

Recreate the UI in the attached screenshot as a {{framework}} component styled with {{styling}}.

- Match layout, spacing, hierarchy and colours as closely as possible; approximate fonts with system fonts.
- Use semantic HTML and accessible labels.
- Make it responsive: describe what changes below 640px.
- Use placeholder data in a typed props object, not hard-coded strings.
- Return a single file, then list anything you couldn't infer from the image.

Add a feature without breaking things

Best with full-repo context (Cursor @codebase, Claude Code)

Variables: feature

I want to add: {{feature}}.

First, explore the codebase and tell me:
1. Where this naturally belongs and which existing patterns/utilities to reuse.
2. Every file you expect to modify or create.
3. Risks: what existing behaviour could break, and how we'll check it.

Then wait for approval. After approval, implement it with tests that follow the project's existing test style.

Write the README a stranger can follow

Any model

Variables: project_nameone_line_description

Write a README.md for this project for a developer who has never seen it.

Project: {{project_name}} — {{one_line_description}}

Include: what it does (2 sentences), screenshot placeholder, prerequisites with versions, install steps, environment variables table (name, required?, example, description), how to run locally, how to run tests, how to deploy, project structure overview, common problems and fixes, licence.
Only include commands that actually exist in the repo; if unsure, mark them TODO rather than inventing them.

Rescue a vibe-coded mess

Use a strong reasoning model

Variables: focus

This codebase was built quickly with AI help and is getting hard to change. Act as a pragmatic tech lead.

1. Map the architecture as it actually is (not as intended).
2. List the top 10 problems ranked by (risk × how often they'll bite us): duplicated logic, dead code, missing error handling, security issues, inconsistent patterns, missing tests.
3. For each, give the smallest fix and an effort estimate (S/M/L).
4. Propose an order of work where the app keeps working after every step.

Do not change code in this pass. Focus area if any: {{focus}}

Project rules file generator

Output goes in AGENTS.md / CLAUDE.md / .cursor/rules

Read this repository and write an AGENTS.md file for AI coding agents working on it.

Include:
- Stack, versions and how to install/run/test/lint (exact commands from package files).
- Code conventions you observe (naming, file layout, error handling, state management).
- "Always" rules (e.g. run tests before finishing) and "Never" rules (e.g. never commit secrets, never edit generated files: list them).
- Where things live (routes, components, data, config).
- Definition of done for a change.
Keep it under 120 lines. Only state what you can verify from the repo.

Ship checklist before launch

Any model

Variables: app_namestack

I'm about to launch {{app_name}} ({{stack}}) to real users. Give me a pre-launch checklist tailored to this stack, grouped as: security, data & backups, errors & monitoring, performance, SEO/social previews, legal (privacy policy, cookies, terms), payments (if any), and analytics.

For each item: why it matters in one line, and how to check it in under 5 minutes. Mark the 5 items I absolutely must not skip.

Database schema from plain English

Any model; review before migrating

Variables: app_descriptiondatabasemigration_tool

Design a database schema for: {{app_description}}. Database: {{database}}.

Give: tables with columns, types, constraints and indexes; relationships; a migration file in {{migration_tool}} format; 3 example queries the app will run most and whether the indexes support them. Point out any data that should NOT be stored (e.g. raw card numbers) and any column likely to need changing later.