Spec-first vibe coding: PRD → tickets → code

Costs last verified: 2026-10-15 (public pricing pages only; not yet run end-to-end by us). By The Agent Ledger.

Spec-first vibe coding: PRD → tickets → code

Short answer: Before you open your coding agent, write a one-page PRD. Have the agent split it into small tickets, each with acceptance criteria. Then work one ticket per session: the agent writes the code plus a test for that ticket, and you review and merge. Small scope per session means less lost context and fewer bugs that cascade. Cost is one coding-agent plan, roughly $20–200/month by tier (estimate to verify).

The problem

"Build me an app" prompts tend to produce large, tangled changes. The agent loses track of earlier decisions, fixes one thing and breaks another, and you can't tell what changed. A written spec and small tickets give both you and the agent a fixed reference point.

What you'll get

• docs/PRD.md: one page, written by you
• docs/tickets/: small numbered tickets with acceptance criteria
• A repeatable session loop: load context → do one ticket → test → review → merge
• Git history where each commit maps to one ticket

Tools

• One coding agent (e.g., Claude Code, Cursor, Codex). Pick one and stick with it for the whole project.
• Git + GitHub (the free plan includes private repos and 2,000 Actions minutes/month per https://github.com/pricing)
• A test runner for your stack (e.g., Vitest/Jest, pytest)

Setup steps

1. Write the PRD yourself (30–60 min), one page max: markdown # PRD: <name> ## Problem (2–3 sentences) ## Users (who, one line each) ## Must-have features (max 5, each one sentence) ## Out of scope (explicit list) ## Data (what's stored, where, who can read it) ## Done means (3–5 checks a stranger could verify)
2. Create the repo and a context file. Add docs/PRD.md and a short CONTEXT.md (or your tool's rules file) covering stack, commands to run tests, folder layout, and "never do" rules (e.g., never commit .env).
3. Ask the agent to split the PRD into tickets, and don't let it write code yet: text Read docs/PRD.md. Do not write code. Split it into tickets small enough to finish and test in one session. Write each to docs/tickets/NNN-short-name.md with: Goal, Files likely touched, Acceptance criteria (testable), Test to add, Depends on. Flag anything in the PRD that is ambiguous instead of guessing.
4. Review the tickets yourself. Merge any that are too small, split any that are too big, answer the ambiguity flags, and update the PRD with what you decided.
5. One ticket per session. Start each new session with: text Read CONTEXT.md, docs/PRD.md, and docs/tickets/NNN-*.md. Work on ticket NNN only. First write a failing test for the acceptance criteria, then make it pass. Do not modify files unrelated to this ticket. Stop and ask if the ticket is unclear. When done, list the files changed and how to verify manually.
6. Work on a branch and open a PR per ticket. Run the tests locally, and add CI later (see Play #4).
7. Review the diff before merging. Read every changed file, or at least skim it. If the diff touches files the ticket didn't mention, ask why.
8. End-of-session update. Ask the agent to add any new decisions to CONTEXT.md (see Play #6). Then you check that update before you commit it.

The bill (monthly, USD)

⚠️ All figures are estimates to verify. Pricing pages checked 2026-10-15. Taxes excluded. "Usage" on these plans is limited by the vendor's own rules (rolling windows, weekly caps, or usage pools), not by a fixed message count.

Notes to verify before publishing: - Cursor's pricing page (as fetched 2026-10-15) lists a shared Cursor + Grok usage pool. On Premium and above, third-party models are billed separately at API list price, so your bill can go above the plan price if you pick non-included models. - Claude Pro/Max limits reset on a rolling 5-hour window plus weekly limits on paid plans. On paid plans you can turn on usage credits at API rates, which is another way to go over the plan price.

Where it could go over: turning on pay-as-you-go/usage credits or third-party models in the middle of a session. Set a spending cap before you start a big refactor.

✋ What stays manual

• Writing the PRD. The agent can ask questions, but the decisions are yours.
• Accepting or rejecting tickets, including deciding what's out of scope.
• Every merge. You read the diff and press merge.
• Defining "done." Acceptance criteria and manual checks come from you.

Security notes

• Put "data" in the PRD on purpose. Writing down what's stored and who can read it forces the auth/permissions question early.
• Secrets never go in tickets, prompts, or the context file. Use .env (gitignored) and an .env.example with placeholders.
• Review dependency additions. If a ticket adds a package, check that it's the real, maintained package and not a look-alike name.
• Don't auto-approve shell commands the agent proposes until you've read them, especially anything that deletes, deploys, or touches credentials.
• Turn on GitHub's free secret scanning/push protection for public repos (listed for public repositories on https://github.com/pricing) and Dependabot alerts.
• For a full pass before launch, see Play #5 (Security pass for vibe-coded apps).

Common bugs & fixes

FAQ

Isn't writing a PRD slow? One page, 30–60 minutes. It's meant to be short. Which coding agent is best for this? The method doesn't depend on the tool. We'll publish what we used and what it cost once we've actually built something with it. Do I need CI? Not for day one. Running tests locally per ticket is the minimum. Play #4 adds CI.