vibelisted

Use when the user says "vibe" or gives a short intent like "add X", "build Y", "fix Z". Runs the full disciplined pipeline end-to-end — brainstorm → plan → isolated execution → verification — with minimal user interaction outside the brainstorm phase. The user only has to answer design questions; every other step is autonomous, guardrail-protected, and token-efficient. If the user does not say "vibe" explicitly, do not assume this skill applies.
rizukirr/vibekit · ★ 17 · Code & Development · score 78

Install: claude install-skill rizukirr/vibekit

# vibe ## Overview One entrypoint that takes a short intent from the user and produces a verified, committed feature. The user talks to the model only during brainstorming; after the spec is approved, the rest is automatic. This skill is an **orchestrator**. It does not do the work itself — it invokes other skills in order, passing file-based artifacts between them, and enforces the gates between stages. ## When to invoke - The user types `/vibe <intent>` or says "vibe: <intent>". - The user asks to build a feature in the shortest possible form ("add a dark mode toggle", "scaffold auth") AND has previously opted into vibe mode. Do not invoke when: - The request is a pure question or read-only exploration. - The user has explicitly asked for a different workflow (inline execution, manual planning). - There is already an uncompleted vibe run in flight — resume the existing run instead. - The user wants autonomous bounded re-runs across multiple iterations (verify → fix → re-verify until ready). Use `ralph-loop` instead — it wraps `vibe` with a blocker classifier, thrashing critic, and budgets, and never bypasses review-pack sign-off. ## The pipeline ``` user intent └─ 1. brainstorm-lean (Socratic, user answers questions) └─ spec file: docs/specs/YYYY-MM-DD-<topic>-design.md, user-approved └─ 2. plan-write (no user interaction) └─ plan file: docs/plans/YYYY-MM-DD-<feature>.md, self-reviewed └─ 3. confirm execution (user pi