Build a working first version of [FEATURE OR APP] using [TECH STACK]. It will be used by [USER] to accomplish [USER GOAL]. Requirements: - Core user flow: [CORE FLOW] - Data and integrations: [DATA OR INTEGRATIONS] - Design direction: [DESIGN DIRECTION] - Constraints: [CONSTRAINTS] - Existing code or files to preserve: [EXISTING CONTEXT]
Work in this order: 1. Restate the proposed scope in 5–8 bullets, identifying what is explicitly out of scope for this version. 2. List assumptions, dependencies, secrets or environment variables needed, and any security or privacy concerns. Never put secrets in client code or sample commits. 3. Propose a file-by-file implementation plan before code. Prefer the smallest architecture that satisfies the core flow. 4. Generate complete, runnable code for the changed or new files, with filenames clearly labeled. Do not use pseudocode, omitted functions, fake API calls, or unexplained placeholder logic. 5. Provide setup commands, a manual test checklist, and automated tests for the most important logic if the stack supports them. 6. Cover loading, empty, error, invalid-input, and mobile-layout states where relevant. Use accessible semantic HTML, keyboard-operable controls, descriptive labels, and visible error messages. Validate all inputs on the server as well as the client when a server exists. Before answering, self-check that imports, routes, types, and data shapes match across files, and flag any part that cannot be implemented without a missing API contract or repository file. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [FEATURE OR APP] | Describe the feature or small app you want to build. | A personal reading queue that lets users save articles and mark them finished |
| [TECH STACK] | Name the framework, language, database, and deployment context if known. | Next.js 15, TypeScript, Tailwind, Prisma, SQLite, and Vitest |
| [USER] | Describe the person who will use the feature. | A busy knowledge worker who saves articles from a weekly newsletter |
| [USER GOAL] | State the task the user should be able to complete. | Add a link, see unread items, and mark an item finished without leaving the list |
| [CORE FLOW] | List the main steps from entry to successful completion. | Open queue, submit URL and title, see newest unread item at top, mark it finished, filter finished items |
| [DATA OR INTEGRATIONS] | Describe data fields, APIs, authentication, or write “none.” | Authenticated local user ID; Article fields: id, title, url, status, createdAt; no third-party APIs |
| [DESIGN DIRECTION] | Describe the desired layout, visual references, and responsive behavior. | Calm desktop-first list with a compact mobile layout, clear status chips, and no decorative illustrations |
| [CONSTRAINTS] | List limits such as deadline, supported browsers, libraries, privacy, or performance. | No external authentication provider; validate URLs; support keyboard navigation; no drag-and-drop |
| [EXISTING CONTEXT] | Paste relevant file paths, code, conventions, or write “greenfield project.” | Greenfield project with the standard Next.js app router |
How to use
- Describe one complete user flow that can be tested, rather than asking for an entire product at once.
- Paste existing routes, schemas, and component conventions when working in a repository so the code can fit them.
- Read the file plan before applying code, then run the provided tests and manually exercise invalid input and empty states.
- Follow up with: “Now implement only the data model and API route, including tests, and wait for my result before building the UI.”
Variations
Bug fix
Use this when an existing feature behaves incorrectly.
Diagnose and fix this bug in a [TECH STACK] project: [BUG DESCRIPTION]. Expected behavior is [EXPECTED BEHAVIOR]; actual behavior is [ACTUAL BEHAVIOR]. Relevant code and error output are [CODE AND LOGS]. First identify the most likely cause and alternatives, then propose the smallest safe patch. Provide changed files in full or as precise diffs, plus a regression test. Do not rewrite unrelated code or guess missing files. Check that the fix covers [EDGE CASE] and explain how to verify it locally.
UI prototype
Use this for a front-end-only prototype.
Create a responsive front-end prototype for [SCREEN OR FLOW] in [FRAMEWORK]. The user needs to [USER TASK]. Include these states: [STATES]. Visual direction: [DESIGN NOTES]. Build with semantic HTML and accessible controls, using local mock data from [MOCK DATA]. Return a component file, styles, and brief setup instructions. Do not add a backend, real authentication, or fake network requests. Check mobile layout at 375px and keyboard navigation before answering.
API integration
Use this when connecting an existing app to a documented API.
Add [API NAME] integration to my [TECH STACK] application for [USER OUTCOME]. API documentation or contract: [API CONTRACT]. Existing relevant code: [CODE CONTEXT]. Specify environment variables, server-side request flow, validation, error handling, rate-limit behavior, and the minimal UI changes. Generate complete changed files and tests with mocked API responses. Never expose tokens to the browser or fabricate endpoints, fields, or response shapes. Flag any contract ambiguity that needs confirmation.
Tips
- Keep the first build to one happy-path outcome plus the few failure states that could corrupt data or leave users stuck.
- Ask the coding model to state its file plan before it writes code; this catches stack mismatches and accidental architectural sprawl early.
- Give it the actual API response shape, schema, or error trace rather than describing them from memory.
- Treat generated code as untrusted until you run it, inspect permissions and secrets handling, and test validation at the boundary where data enters the system.
FAQ
What does vibe coding work well for?
It is useful for prototypes, internal tools, focused features, and learning builds. It is less reliable for vague product requests or systems with complex security, compliance, or operational requirements.
Should I paste an entire repository?
Usually no. Start with the files that define the relevant route, component, schema, and error output, then add more context only when the model identifies a dependency.
Can AI-generated code go straight to production?
Not without engineering review and testing. Production code needs verification for correctness, security, performance, observability, and failure recovery.