The project Overview

The page every project opens on: where you are in the journey, how healthy your spec is, and five tabs holding the whole project in different shapes. · Recommended

Opening a project lands you here, and Project → Overview in the sidebar brings you back. It's the page you'll see most often, so it's worth two minutes to learn what each part of it is telling you.

If you want the journey itself — what to do next, in what order — read The Progression Map instead. This page is about the screen.

The five tabs

A tab strip across the top holds five views of the same project:

The PRD tab

The PRD tab assembles a complete product requirements document out of what you've generated — no extra generation, no cost. It's built fresh each time you open it, so it's never out of date with your spec.

Depending on what you've filled in, it runs through the project description, executive summary, project type and value, target audience, market and business context, goals and success metrics, core capabilities, user workflows, key interactions, personas, every feature with its user stories, then constraints, assumptions, risks, external dependencies, what's out of scope, and future considerations. Sections you haven't generated are simply left out — an early project produces a short PRD rather than a document full of empty headings.

Copy and Download sit in the top-right. Download gives you <project-name>-prd.md.

The Dev Spec tab

The Dev Spec tab is the engineering-facing counterpart: project context, technical architecture, technology stack, architecture preferences, integration points and external services, data considerations, technical constraints, assumptions and risks, internal and infrastructure dependencies, page routes and components, the database schema, the authorization model, the API specification, feature implementation notes, and a proposed file structure. It has the same Copy and Download buttons.

If you haven't run Prepare for Dev yet, this tab will tell you so where it matters: "API contracts not generated yet", with a link to run the data-contracts pipeline. That's the pipeline that derives the endpoints each page reads and writes.

💡 Tip: These two tabs are your escape hatch. Between them you can take the entire specification out of VibeMap as Markdown at any time, on any plan, without connecting anything.

The journey strip

Across the top of the Overview tab is a strip of every step in your journey, in order, grouped by phase. A step turns green with a tick once it has content, carries a count badge (how many features, pages, personas you have), and one step is highlighted as your next recommended move. Click any of them to go straight there.

The strip is mode-aware: a code-first project gets the same steps with the codebase leading and the verbs reversed ("Extract features" rather than "Generate features").

Where the Spec health score went

The 0–100 Spec health score used to sit on this page. It now lives in the Readiness panel on Prepare for Dev, alongside the ready-to-build verdict and the findings list — the place where those findings actually get resolved, rather than a number you could only read here and act on there.

The Requirements panel

The last card is Requirements — your project's requirements as a versioned document rather than a single prompt you can no longer see.

• The charter is your original prompt, frozen as v1. It never changes, so you can always read what you actually asked for.
• The requirements log below it lists every amendment since, newest first. The version number on the card is v1 plus however many amendments have been applied.

Amend requirements opens a dialog for changing what the project is meant to do: write the amendment and why, and VibeMap analyses which features, stories, criteria, personas, pages, or schema need to change as a result. You then approve or reject each proposed change individually before anything is written — high-confidence proposals arrive pre-ticked, conflicts are flagged, and unticked items are left alone.

That review surface is the same one the reconcile flow uses, so it works identically in both places: Staleness and reconciliation walks through it step by step. Both write through version control, so an amendment is as revertable as anything else — see Reverting changes.

An Open Kanban Tracker button sits at the bottom of the tab, for when you'd rather look at the work than the spec.

⚡ Power-user hints

• Use the score as a trend, not a target. Watching it climb as you fill gaps is useful; grinding it to 100 is not — some findings are judgement calls you're right to ignore.
• The charter is the argument-settler. When a spec has drifted over weeks of amendments, open the charter and re-read what you set out to build.
• PRD first, then share. Copying the PRD tab is the fastest way to give a stakeholder something readable without giving them a login.

↔ The traditional way

The same information normally lives in four places that never agree: a PRD in a docs tool, a technical spec in another, a backlog in a tracker, and the change history buried in comment threads. Here they're four views of one model — the PRD and Dev Spec are rendered from your spec on demand rather than maintained by hand, so they can't drift from it, and the health score is computed rather than argued about in a review meeting.

What's next

• What to do next, in order → The Progression Map
• Close the gaps the score is pointing at → Prepare for Dev
• Keep downstream work in step with changes → Staleness and reconciliation
• Read the whole spec as a map → Graph view
• Browse the change timeline → Viewing history