Enforce four quality gates during intent-driven AI coding ("vibe coding") so that code is delivered fast AND to a high standard. Use when the user gives a natural-language intent to write a new feature / change architecture / generate UI / refactor a module; use when you're about to write 100+ lines of code at once; use when you're drawing frontend UI in React/Vue/Svelte; use when you're unsure whether to spec / plan / test first. NOT for one-line edits, comment fixes, Q&A, or debugging existing bugs (use the corresponding specialized skill).
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Enforce four quality gates during intent-driven AI coding ("vibe coding") so that code is delivered fast AND to a high standard. Use when the user gives a natural-language intent to write a new feature / change architecture / generate UI / refactor a module; use when you're about to write 100+ lines of code at once; use when you're drawing frontend UI in React/Vue/Svelte; use when you're unsure whether to spec / plan / test first. NOT for one-line edits, comment fixes, Q&A, or debugging existing bugs (use the corresponding specialized skill).
Vibe Coding Craft
Overview
The common failure mode of "vibe coding": user says one sentence → AI dumps 500 lines at once → it appears to run → naming is sloppy / design has heavy "AI flavor" / edge cases untested / changing one thing breaks three. This skill cuts that path into 4 gates, each with a quantifiable exit condition that cannot be hand-waved past.
Four gates (every change must pass them in order):
Any gate not passing → Stop the line. No advancing to the next gate.
When to Use
User gives a natural-language intent to generate a new feature, component, or module
Change spans ≥ 2 files and is projected to ≥ 100 lines
Touches UI / frontend components / styling
Touches public APIs / exported types / package boundaries
You "feel like" you should write it all at once → must enter DECIDE first
When NOT to Use
Single file, single function, < 30 line change → just do it
Bug fix / chasing a build error → use -style root-cause investigation
debugging-and-error-recovery
Answer / explain code → just answer
Already have a spec + plan → skip DECIDE, start at BUILD
Gate 1 — DECIDE (Decision Hygiene)
Mandatory before writing code. Borrowed from local engineering-lifecycle rule (Decision §A — claim decomposition / evidence anchors / explicit retraction / temporal layering / commitment boundary).
1.1 Claim Decomposition
When the user gives a conclusive directive ("do X / don't do Y"), first list the 3–5 independent dimensions it covers at the implementation layer, then verdict per dimension. Do not generate todos along the conclusion before decomposition.
Example:
User: "Add user login to this project"
❌ One-line dump of OAuth + DB + middleware + UI all at once.
✅ Decompose:
Auth strategy (session / JWT / OAuth provider)
User storage (existing user table? fields sufficient?)
Middleware (route protection, role-based?)
UI (login page, signup page, forgot password?)
Security (password hashing, rate limiting, CSRF)
Verdict each dimension independently; if some need user adjudication, stop and ask first.
1.2 Evidence Anchors
Before any architectural call, you must produce 1–3 concrete anchors:
Code reference: src/auth/handler.ts:42
Config: package.json line N
Current metric: bundle 200 kB / 150 tests
❌ "It looks like the existing hooks are not flexible enough"
✅ "useFetch.ts:12-30 hardcodes retry to 3 with no per-call override → add an optional parameter"
No anchor → you're guessing, not designing.
1.3 Explicit Retraction
When you discover within the same session that a previous suggestion contradicts new evidence, mark explicitly:
Retract <previous-keyword>: <why>. <replacement>.
No silent reversals.
1.4 Temporal Layering (YAGNI Across Time)
Split into now / later:
now: capabilities this PR must land, backed by user demand
later: only a placeholder + one-line trigger condition. Forbidden to ship the negotiation protocol / version matrix / extension point now.
"Maybe needed later" is not a reason to ship — it's a reason to leave a placeholder.
1.5 Commitment Boundary
For any symbol that looks like a public API (exported function, doc example, example folder), the doc comment must explicitly declare stability: @stable / @experimental / @internal.
Gate 1 Exit Checklist
User's conclusion decomposed into ≥ 3 independent dimensions, each verdicted
Change exceeded task scope ("tidied along the way")
Cross-package exports lack doc comments
TODO has no owner / issue
Final Verification (Last Pass Before Delivery)
## DECIDE- [ ] User conclusion decomposed
- [ ] 1–3 evidence anchors
- [ ] Conflicts with prior explicitly retracted
- [ ] now / later boundary clear
- [ ] Public symbols carry stability markers
## BUILD- [ ] Slice commits, each with build/test green
- [ ] File / function / nesting / commit quantitative limits all pass
- [ ] Naming + error handling + single interface + scope discipline all pass
## VERIFY- [ ] 5-axis self-review complete; each axis has a concrete verdict
- [ ] End-to-end real flow has actually run
- [ ] Critical / must-fix cleared
## POLISH- [ ] No AI flavor in visuals
- [ ] All data components have all four states
- [ ] a11y keyboard + contrast pass
- [ ] Cross-module docs + TODO format + three-segment imports
Any unchecked → not done; return to the corresponding gate.
The consuming project's own .cursor/rules/project/<name>.mdc (project-specific bindings; written per-project, see ../examples/project-binding/ for templates)
