vibe-coding

Original source / Raw SKILL.md

---
name: "vibe-coding"
description: "Turn an idea into a functional, demo-ready prototype using AI-assisted “vibe coding” (timeboxed build loop, prompt pack, build plan, demo script, and safety checks). Use for rapid prototyping and proving concepts in AI & Technology."
---

# Vibe Coding

## Scope

**Covers**
- Timeboxed, AI-assisted rapid prototyping (“vibe coding”) to produce a functional demo (not slides)
- Turning a rough idea into a buildable prototype spec + task board + prompt pack
- A tight iteration loop: generate → run → verify → adjust → log decisions
- “Build tools to build the thing” when it meaningfully speeds up the demo (timeboxed)
- Safe use of coding agents: least privilege, no secrets, small diffs, validation, rollback

**When to use**
- “Vibe code a working prototype we can demo in 30–90 minutes.”
- “Replace this Figma concept with a clickable prototype.”
- “I’m not an engineer—help me build a small app/tool with AI and ship a demo.”
- “Turn this AI feature idea into a proof-of-concept with a clear build loop and demo script.”

**When NOT to use**
- You need a production-grade system, hardening, scaling, or security review (use `building-with-llms` + engineering process).
- You need upstream problem framing, strategy, or PRD-level alignment (use `problem-definition`, `writing-prds`).
- The work is high-stakes/irreversible (payments, auth, medical, legal, safety-critical) without human owners and reviews.
- The request is “build anything” with no demo target; do intake first and narrow to one scenario.

## Inputs

**Minimum required**
- Prototype goal: what should a user be able to do in the demo (1–3 “happy path” tasks)
- Target user + context (who uses it, where it fits)
- Timebox (e.g., 30/60/90 minutes) + demo audience (internal, customer, exec)
- Platform preference (web app, mobile, CLI, spreadsheet, etc.) and constraints (privacy, data sensitivity)
- Data/integrations: mock data ok? any APIs needed? (default to mock)

**Missing-info strategy**
- Ask up to 5 questions from [references/INTAKE.md](references/INTAKE.md) (3–5 at a time).
- If details remain missing, proceed with explicit assumptions and offer 2–3 options (e.g., mock vs real data; simple UI vs polished).
- If asked to run commands or write/modify files, request confirmation, keep changes in a dedicated folder, and include rollback guidance.

## Outputs (deliverables)

Produce a **Vibe Coding Prototype Pack** (in chat; or as files if requested), in this order:

1) **Vibe Coding Brief** (goal, demo scenario, non-goals, constraints, timebox)
2) **Prototype Spec** (user flow, screens/components, data model, acceptance criteria, “fake vs real” decisions)
3) **Prompt Pack** (copy/paste prompts to drive the coding agent safely and efficiently)
4) **Build Plan + Task Board** (vertical slices with checks/tests per slice)
5) **Demo Script + Runbook** (how to run, how to demo, what to say, what to avoid)
6) **Risks / Open questions / Next steps** (always included)

Templates: [references/TEMPLATES.md](references/TEMPLATES.md)

## Workflow (7 steps)

### 1) Pick a single demo outcome (kill ambiguity fast)
- **Inputs:** Initial idea, timebox, target audience.
- **Actions:** Write a one-sentence demo promise (“In 60 minutes we will demo…”) + 3–5 non-goals. Choose one “hero” scenario and what can be faked.
- **Outputs:** Draft **Vibe Coding Brief**.
- **Checks:** The demo promise is specific, observable, and fits the timebox.

### 2) Define the prototype’s contract (what exists, what’s mocked)
- **Inputs:** Demo scenario, platform preference, constraints.
- **Actions:** Specify the minimum user flow, screens/components, and data shape. Decide: mock data vs real data; stub integrations vs live.
- **Outputs:** Draft **Prototype Spec**.
- **Checks:** Acceptance criteria exist for each user-visible step; “fake vs real” is explicit.

### 3) Set the build loop + guardrails (how we’ll vibe code safely)
- **Inputs:** Repo/app context (if any), constraints, desired stack.
- **Actions:** Create a **Prompt Pack** that forces: small diffs, clear file list, run instructions, and “ask before risky actions.” Create a task board of 3–8 vertical slices.
- **Outputs:** **Prompt Pack** + **Build Plan + Task Board**.
- **Checks:** Every slice has a Definition of Done and a quick validation method (manual steps or tests).

### 4) Scaffold the thinnest runnable slice (end-to-end)
- **Inputs:** Prompt pack, chosen platform/stack, prototype spec.
- **Actions:** Generate a minimal skeleton that runs. Implement the hero path with mock data. Capture run commands and known limitations.
- **Outputs:** Runnable prototype + run notes (for the runbook).
- **Checks:** A fresh user can run it in ≤ 5 minutes; the hero path is demonstrable.

### 5) Iterate in vertical slices (generate → run → verify → log)
- **Inputs:** Task board, working prototype.
- **Actions:** For each slice: request a plan + diff, apply changes, run, verify against acceptance criteria, and record decisions/bugs. Avoid broad refactors; prefer incremental improvements.
- **Outputs:** Updated prototype + iteration notes.
- **Checks:** Each slice ends with a user-visible improvement and a validated run.

### 6) Optional: build a tool to build the thing (timeboxed)
- **Inputs:** Repeated friction (editing, generating, transforming content).
- **Actions:** If it reduces time-to-demo, vibe code a tiny helper tool (editor, generator, script) and immediately use it to advance the prototype.
- **Outputs:** Helper tool + note on how it accelerates the workflow.
- **Checks:** The helper tool saves time within the current timebox; otherwise cut it.

### 7) Package the demo + quality gate + handoff
- **Inputs:** Prototype + all draft artifacts.
- **Actions:** Write the demo script + runbook. Run [references/CHECKLISTS.md](references/CHECKLISTS.md) and score with [references/RUBRIC.md](references/RUBRIC.md). Finalize **Risks / Open questions / Next steps**.
- **Outputs:** Final **Vibe Coding Prototype Pack**.
- **Checks:** A stakeholder can demo it without you; risks and next steps are explicit and owned.

## Quality gate (required)
- Use [references/CHECKLISTS.md](references/CHECKLISTS.md) and [references/RUBRIC.md](references/RUBRIC.md).
- Always include: **Risks**, **Open questions**, **Next steps**.

## Examples

**Example 1 (30–60 min prototype):** “Use `vibe-coding` to build a demo-ready web prototype of an ‘AI meeting notes → action items’ tool. Mock the LLM output. Output the full Vibe Coding Prototype Pack.”  
Expected: brief + spec + prompt pack + task board + demo script; prototype plan defaults to mock data and a single hero flow.

**Example 2 (non-engineer builder):** “I’m a PM. Use `vibe-coding` to help me create a clickable prototype of an onboarding checklist app in 45 minutes. I need a demo script for my team.”  
Expected: tight scope, fake data, vertical slices, and a runbook optimized for demo reliability.

**Boundary example:** “Vibe code a production payments backend and deploy it.”  
Response: out of scope; propose a prototype-only approach (mock payments), identify required security/engineering owners, and recommend a separate production plan.



---

## Referenced Files

> The following files are referenced in this skill and included for context.

### references/INTAKE.md

```markdown
# Intake questions (ask 3–5 at a time)

## 1) Demo promise + timebox
- What is the one thing the user should be able to do in the demo (hero scenario)?
- What is the timebox (30/60/90 minutes) and who is the demo audience?
- What level of fidelity is needed: “clickable”, “usable”, or “almost shippable” (prototype-only)?

## 2) User + workflow context
- Who is the target user and what situation are they in?
- Where does this fit: internal tool, customer-facing feature, or concept exploration?
- What are 3–5 explicit non-goals to prevent scope creep?

## 3) Platform + constraints
- Preferred platform: web app, mobile, desktop, CLI, spreadsheet, etc.?
- Any must-use tech stack or environment constraints?
- Any accessibility requirements for the demo?

## 4) Data + integrations (default to mock)
- Can we use mock data for the demo? If not, what’s the minimum real data needed?
- Any required integrations (APIs, files, databases)? What can be stubbed?
- Any privacy/compliance constraints (PII/PHI, retention, logging restrictions)?

## 5) “Build tools to build the thing” opportunities
- What parts are repetitive or painful (editing, transforming content, creating assets)?
- Would a tiny helper tool/editor meaningfully speed up the demo within the timebox?

## 6) Execution constraints (if writing code)
- Are we allowed to run commands and write files? Any repo constraints?
- Do we need a human review gate before edits/commands?
- What’s the rollback plan (git diff/revert, branch, backup folder)?


```

### references/TEMPLATES.md

```markdown
# Templates (copy/paste)

## 1) Vibe Coding Brief

### Demo promise (one sentence)
“In <timebox>, we will demo <hero scenario> for <target user>.”

### Context
- **What we’re prototyping:**  
- **Target user:**  
- **Where it fits (internal/customer/concept):**  
- **Demo audience:**  

### Non-goals (3–5)
-  

### Success criteria (demo-ready)
- The user can:  
- The demo shows:  
- Reliability requirement (what must not break):  

### Constraints
- Timebox:
- Platform preference:
- Data sensitivity / compliance:
- Tools allowed (read/write/terminal):

### Fake vs real (decisions)
- Data: mock | real (minimum: )
- Integrations: stub | live (minimum: )
- Auth: none | fake | real (minimum: )

## 2) Prototype Spec (minimum build contract)

### User flow (hero scenario)
1)  
2)  
3)  

### Screens / components (MVP)
- Screen/component:
  - Purpose:
  - Inputs:
  - Outputs:
  - Edge cases:

### Data model (prototype-level)
- Entities:
- Example data (mock):

### Integrations (if any)
- API/file/database:
  - What it’s used for:
  - What can be stubbed:
  - Failure handling:

### Acceptance criteria (observable)
- [ ]  
- [ ]  

### Out of scope
-  

## 3) Build Plan + Task Board (vertical slices)

Create 3–8 slices. Each slice must end with a runnable, user-visible improvement.

| Slice | User-visible behavior | Agent prompt (short) | Validation (steps/tests) | Notes |
|------:|------------------------|----------------------|--------------------------|-------|
| 1 | | | | |
| 2 | | | | |

## 4) Prompt Pack (safe vibe coding)

### Prompt A — Scaffold a runnable thin slice
Context:
- Goal: <demo promise>
- Platform/stack: <constraints>
- Keep it minimal and runnable.

Instructions:
- Propose a plan (3–6 bullets) before writing code.
- Keep changes small and localized; avoid broad refactors.
- List files you will create/modify.
- Include exact run commands.
- Do not add secrets, keys, or credentials.
- If anything is risky or destructive, stop and ask for confirmation.

Output:
1) Plan
2) File list
3) Patch/diff (or file contents)
4) Run instructions
5) Quick manual test steps

### Prompt B — Implement the next vertical slice
Inputs:
- Current state: <what works now>
- Next slice: <one user-visible behavior>
- Acceptance criteria:

Constraints:
- Keep existing behavior working.
- Prefer simple solutions over “best practice” architecture.

Output:
- Plan + diff + validation steps.

### Prompt C — Debug a break (fast triage)
Inputs:
- Error message / symptom:
- Steps to reproduce:

Instructions:
- Start with the smallest change likely to fix it.
- Suggest 1–3 hypotheses; pick the most likely.
- Provide a verification step after the fix.

## 5) Demo Script + Runbook

### Runbook (how to run)
- Prereqs:
- Setup:
- Run command:
- Where to open it:
- Known limitations:

### Demo talk track (3–5 minutes)
1) Context (who/why):
2) Hero scenario walkthrough:
3) “What’s real vs faked”:
4) What we learned:
5) Next steps:

### Backup plan (if it breaks)
- Screenshot/video fallback:
- Alternate flow:

## 6) Risks / Open questions / Next steps

### Risks (with mitigations)
- Risk:
  - Mitigation:

### Open questions
-  

### Next steps (prioritized)
1)  
2)  


```

### references/CHECKLISTS.md

```markdown
# Checklists

## A) Scope + demo promise checklist
- [ ] Demo promise is one sentence and timeboxed.
- [ ] Hero scenario is a single runnable flow (not a list of screens).
- [ ] 3–5 explicit non-goals prevent scope creep.
- [ ] “Fake vs real” decisions are explicit (data, integrations, auth).

## B) Prototype spec checklist
- [ ] User flow is written as 3–7 concrete steps.
- [ ] Acceptance criteria are observable (“User can…”).
- [ ] Data model is simple and includes example mock data.
- [ ] Out-of-scope items are listed.

## C) Vibe coding loop checklist (agent-assisted execution)
- [ ] Agent receives constraints and asks clarifying questions when needed.
- [ ] Changes are small and localized; file list is explicit.
- [ ] App is run and verified after each slice (or tests are run).
- [ ] A short change log exists (what changed, why, how verified).
- [ ] No secrets/credentials are requested, pasted, or written to files.

## D) “Build tools to build the thing” checklist (optional)
- [ ] The helper tool is timeboxed and has a clear payoff within the demo.
- [ ] The tool is immediately used to advance the prototype.
- [ ] If payoff isn’t clear, the tool is cut.

## E) Demo readiness checklist
- [ ] Runbook enables a fresh user to run the prototype in ≤ 5 minutes.
- [ ] Demo script is 3–5 minutes and tells a coherent story.
- [ ] Demo does not rely on fragile external dependencies when avoidable.
- [ ] Backup plan exists (fallback flow or recording).

## F) Final pack checklist
- [ ] All deliverables are present in the specified order (brief → spec → prompts → plan → demo → risks).
- [ ] Risks, open questions, and next steps are specific and prioritized.
- [ ] Rubric score meets the bar (see [RUBRIC.md](RUBRIC.md)).


```

### references/RUBRIC.md

```markdown
# Rubric (score 1–5 per category)

Suggested bar for “demo-ready”: average ≥ 4.0 and no category below 3.

## 1) Demo clarity and scope control
1 = No demo promise; scope is “everything”  
3 = Demo promise exists; some non-goals; partial fake-vs-real decisions  
5 = Crisp demo promise; strong non-goals; explicit fake-vs-real; timebox is realistic

## 2) Prototype contract quality (spec + acceptance)
1 = Vague requirements; no acceptance criteria  
3 = Basic flow and acceptance criteria; missing edge cases  
5 = Clear flow, components, data shape, and observable acceptance criteria

## 3) Vibe coding execution loop quality
1 = Random prompting; no checkpoints; large diffs  
3 = Some structure; occasional validation; incomplete logging  
5 = Tight loop: plan→small diff→run/verify→log; failures become tasks; progress is predictable

## 4) Safety and robustness
1 = Secrets or risky operations; no rollback  
3 = Some guardrails; partial rollback/runbook  
5 = Least privilege; no secrets; confirmation gates for risky actions; rollback and runbook are clear

## 5) Demo readiness and handoff
1 = Only works on the creator’s machine; no demo narrative  
3 = Runs with help; basic demo script  
5 = Runs from clean start; demo script is clear; backup plan exists; next steps are prioritized


```