---
name: vibe-coding-companion
description: "The 2026 vibe-coding workflow: idea → spec → Cursor/Claude prompts → working app, the loop tightened. Operationalises 'vibe coding' — describe an app in plain English and ship it without writing code. Generates a tight spec, drops into Cursor/Claude/Bolt/Lovable prompts in the right order, handles the iteration loop, and keeps you from drowning in 30-tab chaos."
license: MIT
---

# Vibe Coding Companion

Vibe Coding Companion turns a plain-English app idea into a structured spec and an ordered stack of prompts for the AI builders you already use — Cursor, Claude, Bolt, and Lovable. It is for solo builders, indie hackers, and PMs who can describe what they want but don't want to hand-write code or babysit twenty half-finished chat threads.

## When to use it

- You have an idea ("a habit tracker with streaks and a weekly email") and want a buildable spec, not a blank editor.
- You've been pasting the same context into Cursor and Bolt over and over and losing track of what's current.
- A generated app half-works and you need a disciplined fix loop instead of re-prompting from scratch.
- You're deciding which tool to start in — Lovable/Bolt for the first UI, Cursor/Claude for iteration on a real repo.

## How it works

The skill runs a four-stage pipeline:

1. **Spec** — interviews you briefly, then emits a `spec.md`: one-paragraph pitch, user stories, data model, screen list, and an explicit out-of-scope section so the first build stays small.
2. **Scaffold prompts** — generates tool-specific opening prompts. For **Bolt**/**Lovable** it writes a single self-contained build prompt (stack, pages, routes, sample data). For **Cursor**/**Claude Code** it writes a repo-aware prompt plus a `.cursorrules`-style conventions block.
3. **Iteration loop** — for each change you describe, it produces a *scoped* diff prompt that references the spec and names the exact files/components to touch, so the agent edits instead of regenerating.
4. **State file** — maintains `vibe-state.md` tracking which tool holds the source of truth, what's shipped, and the open backlog.

## Example

```bash
curl -fsSL --create-dirs -o ~/.claude/skills/vibe-coding-companion/SKILL.md https://claudeskil.com/skills/vibe-coding-companion/SKILL.md

# In Claude Code / Cursor chat:
> vibe: build a "leftovers" app — log fridge items with
  expiry dates, get a daily "use these soon" list

# Skill replies with spec.md, then:
> vibe: scaffold for lovable
> vibe: next — add push reminders 2 days before expiry
```

Each `vibe: next` returns a prompt you paste straight into your builder, plus an updated `vibe-state.md`.

## Tips & gotchas

- Keep one tool as source of truth. The state file flags "drift" when you've edited the same feature in two tools — reconcile before continuing.
- Bolt/Lovable prompts are intentionally one-shot and verbose; don't trim them, the redundancy is what stops the builder from inventing a different stack.
- The spec's out-of-scope list is load-bearing. Moving an item *into* scope is a deliberate `vibe: scope` command, not an offhand request.
- For Cursor, commit before each `vibe: next` so the scoped diff lands on a clean tree.

## FAQ

**Does it write code itself?** No — it produces specs and prompts. The actual generation happens in Cursor, Claude, Bolt, or Lovable.

**Can I switch tools mid-project?** Yes. Run `vibe: handoff <tool>` and it repackages current state into that tool's prompt format.

**What if the generated app breaks?** Describe the bug in plain English; the loop emits a fix prompt naming the suspect files rather than rebuilding the feature.