Can it be vibe coded?
Prompt library

Vibe coding prompts

995 prompts for building software with an AI coding agent, each written as a full build brief rather than a one-line idea. Filter them by category and verdict, preview the opening, and copy the whole brief in one click.

Every brief comes from a buildability report, so it is scoped to what an agent can actually deliver. 137 have been reviewed line by line by a person.

Why they work

What the best vibe coding prompts have in common

The prompting guide ↗

  • One workflow, stated first

    Each brief opens with the single job the software has to do end to end, before any feature list, so the agent builds a working journey instead of a screen.

  • A pinned stack

    728 of the 995 briefs name an exact stack and rule out substitutions, which stops the agent from swapping frameworks halfway through.

  • A delivery standard

    The same 8 rules close every brief: real persistence and validation, real error states, no mock integrations or hard-coded success screens.

  • Checks and non-goals

    6 acceptance criteria you can run yourself, plus a written list of what the build will not replace, so nobody pretends otherwise.

The library

Browse and copy the briefs

Loading all 995 briefs…

Not in the index?

A vibe coding prompt template

The same structure as every brief above, with the app-specific parts left for you to fill in. The delivery standard, acceptance criteria, and ownership list are the real ones, unchanged.

build-brief-template.md
# Build brief — a focused alternative to [the product you are replacing]

## Context

[What the product does, who uses it, and what it costs you. One honest sentence on how much of it you expect to reproduce, and what you will keep paying for.]

This brief describes a focused, single-operator replacement for the part of [the product] that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing.

## What you are building

[The one workflow that has to work end to end, in a sentence: capture what, do what with it, and export it where.]

## Requirements

### Functional

- [Each screen or action the core workflow needs, one per line.]

### Data and integrations

- [Where the data comes from, and every documented API, account, or credential it needs. Mark the optional ones as optional.]

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

[The stack, with no substitutions; where data lives on disk or in the database; and the one command that starts it locally.]

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- [Each feature of the paid product you are deliberately leaving out.]

## What you still own after launch

- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.

## Risk

[What happens when this breaks, and who notices. For security, money, legal, health, or payroll work, keep a qualified human and an established provider in the loop.]
Choose what to build

Start from an idea that holds up

A good prompt cannot rescue software whose value is a network, a dataset, or a licence. Start from the strong builds, or check the numbers across all 1,093 reports.

Browse vibe coding ideasSee the statistics

Reports on AI models, assistants, and AI coding tools are not listed here. Their briefs stay on their own reports.