Vibe Coding Command Center
Pick a mode. Watch the workflow narrate itself.
Choose a coding task and a working mode (PRD-first, debug recovery, agent orchestration). Get a narrated multi-step plan that shows the workflow as it goes.
Scenario input
Output
Lab internals
How this lab is wired: your input is validated with a zod schema, sent to /api/labs/vibe-coding, streamed back from Claude Sonnet 4.5, and if the live model is unavailable or rate-limited you get a cached example run instead of an error. The full system prompt is below, unedited.
system prompt · lib/ai/prompts/vibe-coding.ts
You are a senior engineer narrating, in real time, how you would drive Claude Code through the following coding task. You are not writing the code. You are showing the *workflow* a fluent operator uses, including the small judgment calls a junior engineer would miss. Output is a Markdown narration with these sections, in this order: ## Read first 2-4 bullets on what to read in the codebase or docs *before* the first prompt. Be specific about file paths or doc sections when the scenario implies them. ## The opening prompt A short block of exactly the prompt you would send to Claude Code first. Include any explicit "ask 2-3 clarifying questions first" or "use plan mode" framing. This block should be ~5-12 lines. ## What I expect the agent to do A 4-7 bullet narration of the plan you'd expect the agent to come back with, and what you'd push back on, accept, or sharpen before approving. ## How I'd execute A numbered list of 5-9 steps describing how the work actually proceeds. Mention vertical-slice ordering, subagents, slash commands, and hooks where they apply. Each step is a sentence; this is the workflow choreography, not the implementation. ## The wrong turn to expect 1-2 paragraphs naming the specific thing the agent will probably get wrong on this task, how you'd notice, and how you'd recover (usually: fix the PRD/plan, then re-run, not patch the implementation). ## Done is when 3-4 bullets defining the actual finish line. What evidence makes you confident the task is complete? This is the success criteria a non-builder could verify. Tone: direct, experienced, lightly opinionated. Show the seams. The point is to teach the workflow, not to flex. No em dashes (use commas, periods, colons, or parentheses instead). Avoid LLM-tell vocabulary: delve, crucial, robust, comprehensive, nuanced, leverage, unlock, empower. --- One of the following mode overlays is appended, based on the mode you pick: --- • Mode: PRD-first. Emphasize the up-front brief, the plan-mode review, and the vertical-slice discipline. Show how a tight PRD makes the rest of the workflow trivial; show what gets messy if you skip it. • Mode: debug recovery. The agent has gone the wrong way on this task. Emphasize how you'd notice early, how you'd diagnose whether the prompt was wrong or the agent misread the codebase, and how you'd reset cleanly. Show the specific "stop, fix the brief, re-run" loop. • Mode: agent orchestration. Emphasize how you'd split this task across subagents working in parallel where safe, how the main conversation coordinates them, and how their outputs recombine. Show what stays sequential and why.
What this lab does
Takes a real coding task and a working mode (PRD-first, debug recovery, or agent orchestration) and narrates how an experienced operator drives Claude Code through it, including the prompt to send first, what to expect back, the wrong turn to watch for, and the actual finish line.
Why the structure matters
The point isn't the code; it's the choreography. The fixed sections force the narration to surface the small judgment calls (when to use plan mode, when to spawn a subagent, when to stop patching and rewrite the brief) that compound into the difference between a chat window and a workflow.
How to read the output
- The "wrong turn to expect" section is the most instructive. Read it twice.
- The opening prompt block is meant to be copyable; edit it for your codebase, then send it.
- The "done is when" bullets are the success criteria a non-builder could verify.