2.1 — How VibeMap works
On this page
2.1 — How VibeMap works
VibeMap is a pipeline. You feed in a product description; you get out a buildable, sprinted spec; your AI agent works through it.
This page explains the pipeline at a high level. You don't need to know any of this to use VibeMap — but it'll help you understand why the editor is laid out the way it is.
📸 Placeholder:
10-pipeline-overview.png— illustrated pipeline: prompt → summary → personas → features → user stories → acceptance criteria → pages → schema → files → sprints → kanban.
The four phases
Phase 1 — Generation
When you create a project, VibeMap runs through a sequenced pipeline:
- Summary — A tightened-up restatement of your prompt that surfaces product positioning.
- Personas — 2-5 user types your product serves, with goals and pain points.
- Features — The product's major capabilities, grouped logically.
- User stories — Per-feature "As a … I want … so that …" statements, tied to a specific persona.
- Acceptance criteria — Testable, atomic units of work, each tied to a user story. These are what your AI agent will actually claim and work on.
- Pages — The page-by-page UX outline (page name, purpose, sections, auth rules).
- Schema — A relational database schema sized for the feature set.
- Files — A starter file/folder structure for your codebase.
Each step is its own AI generation. Each one is editable. You can regenerate any one of them without redoing the others.
Phase 2 — Prepare & Review
Before any of this can drive your agent's work, you need to approve it. The web editor surfaces this as a four-step strip:
- Prepare — re-run any missing generations.
- Review — read and edit features, user stories, and acceptance criteria. Approve the ones you're happy with.
Only approved acceptance criteria become claimable by your agent. Unapproved ones stay in the draft pile.
Phase 3 — Plan
On the Plan tab (Pro+), VibeMap analyzes dependencies across your approved acceptance criteria and groups them into themed sprints. Each sprint typically contains 5-12 criteria that can be worked on in parallel; sprints are sequenced so that dependencies resolve first.
If you're on the free tier, you skip this step and your agent works the criteria in approval order.
Phase 4 — Track
On the Track tab, you see a live kanban board:
- Ready — claimable now (dependencies met, sprint active)
- In Progress — currently being worked on by an agent
- In Review — submitted by the agent; awaiting your or CI's resolution
- Passed — done, terminal
Your agent picks up work from Ready, moves it through, and you (or your CI workflow) close it out.
The entity hierarchy
Everything in VibeMap nests like this:
Project
├── Personas
├── Features
│ └── User Stories
│ └── Acceptance Criteria ← these are what your agent claims
├── Pages
├── Schema (tables + relations)
└── Files (folder + file outline)
When an acceptance criterion (AC) is "ready" to work on, that means:
- It's been approved.
- All of its prerequisite ACs (ACs it depends on) are themselves
passed. - It belongs to the active sprint (if you've planned sprints).
What you control vs what the AI controls
| You | VibeMap | Your agent | |
|---|---|---|---|
| The product idea | ✅ | ||
| The initial spec generation | ✅ | ||
| Editing the spec | ✅ | ||
| Approving criteria | ✅ | ||
| Sprint planning | ✅ | ||
| Re-planning after edits | ✅ trigger | ✅ runs | |
| Picking what to work next | ✅ via next-ready | ✅ asks for it | |
| Writing the code | ✅ | ||
| Submitting work for review | ✅ | ||
| Resolving the review | ✅ or CI |
VibeMap is never writing your application code. It's writing your spec and orchestrating your agent.