ayi-ai/vibe-coding-playbook
The product-workflow layer on top of AI coding discipline — idea to shipped, without the spaghetti. Builds on Karpathy's
Actual rules from this repo
Path in source repo: .cursor/rules/vibe-coding-playbook.mdc · format: mdc
---
description: Engineering discipline for AI coding (Vibe Coding Playbook)
alwaysApply: true
---
# Engineering discipline (obey before writing any code)
## Tier the task first
- Small change (typo / styling / one-line fix): just do it — no process, no docs — but obey the disciplines below.
- Real product (shipped / maintained / for others): align on the need first; never generate a whole system in one shot.
## Think before coding
- Don't guess on my behalf. When a request is ambiguous, present the interpretations and let me choose.
- If there's a simpler approach, say so. If confused or stuck, stop and name what's unclear.
## Simplicity first
- Write the least code that solves the problem. No unrequested abstraction, configurability, or flexibility.
- No error handling for impossible scenarios. If 200 lines could be 50, rewrite it.
## Surgical changes
- Change only the files and functions I named. No drive-by refactors or dependency upgrades.
- Every changed line must trace to my request. Mention unrelated dead code — don't delete it.
- In existing code: match the current style; only clean up imports/variables your change orphaned, leave pre-existing old code alone.
## One feature at a time
- Don't generate a whole system at once. One feature → smallest working loop → test → commit → next.
## Goal-driven
- Turn "fix the bug" into "write a failing test that reproduces it, then make it pass."
- State explicit pass/fail criteria, then loop on your own until they're met.
## Docs before code (real products only)
- For a real product, no feature code without PRD / architecture / status docs; requirements change → docs change first.
## Communication
- Match my level: terse for engineers, plain explanations for newcomers. No jargon dumps.
- I decide, you implement. Be upfront about limitations and risks.
Why this is listed
This repository appears on Cursor Rules Live because it matches the tracker's GitHub Search criteria (cursor-rules) and was active in the recent indexing window. The tracker refreshes every 15 minutes, so the metadata above reflects the state at the most recent index pass. If the data here looks stale, the source repository may have been archived or moved out of the tracked topic; the next cron tick will reconcile.