Generating pages

A complete sitemap — every route, section, and data dependency — derived from your features and stories. · Required · Starter plan

Pages are the structural backbone of your product and the second-to-last Plan step. They matter twice over: they define your information architecture, and they give the schema generator far richer context. That's why pages come before schema — page layouts tell the schema generator what data each screen actually shows and edits.

Figure: Pages list.

Generating your pages

1. Open the Pages page from the project sidebar. (Code-first projects find it under Extract Specs.)
2. Click Generate Pages — the confirm step is labelled Generate Pages & Sitemap.
3. The AI reviews your features, user stories, and business goals, maps each requirement to a route, and breaks every page into logical UI sections.
4. Review the result — a full information architecture ready for design and schema.

Generation usually takes 30–60 seconds. Every page carries a route, title, sections/components, data dependencies (which tables and fields it reads or writes), API endpoints, and SEO metadata.

The Pages views

The Pages page has six tabs along the top:

Figure: The visual sitemap of your pages.

The Branding view holds the palette generated for your project — primary, secondary, accent, background, and text tokens. These feed both the in-app UI preview and any Tailwind config your coding agent produces.

Figure: Branding & colour theme.

How pages trace back to your spec

Nothing here exists in isolation. A feature like "User Authentication" produces /login, /register, and /forgot-password; each story maps to specific sections on those pages; and data dependencies are derived from the acceptance criteria attached to those stories. Change a feature and regenerating pages reflects it across the sitemap.

Pages also feed criteria back the other way: once pages exist, run Derive Criteria from Pages to catch UI behaviours the feature pass missed — see Acceptance criteria.

Adding more, or editing by hand

• Generate Additional Pages — a second pass that fills gaps against your current features.
• Edit metadata directly — rename routes, adjust priorities, and update descriptions without regenerating.

⚠️ Watch out: Generating pages before you have features produces a generic skeleton. Do features and stories first — pages are only as good as the requirements underneath them.

⚡ Power-user hints

• Check the Sitemap view first. Missing navigation paths and orphan routes are far easier to catch visually than in a list.
• Use List view to kill duplication. If the same "Testimonials" section appears on three pages, consolidate before handoff so your agent builds it once.
• Order matters: pages → schema. Resist generating schema early. Every page you define adds context that produces more complete tables.

Author with your own agent (MCP)

Instead of clicking Generate Pages, a connected IDE agent can author the sitemap straight into the project on its own tokens — the "Prefer your own agent? Keep it on your tokens" disclosure under the button. Pages need a Starter plan either way: the gate is on the capability, not the engine, so a Free project can't have them authored over MCP either. Full detail: Two ways to generate.

💡 Tip: Database schema is not part of this pass — it's a separate, run-last step. See Generating the database schema.

↔ The traditional way

A designer or architect normally draws the sitemap and wireframe inventory by hand in Figma or a whiteboard, then reconciles it against the PRD manually. VibeMap derives the whole route map, section breakdown, and data dependencies straight from the spec — and keeps them traceable, so a feature change ripples through instead of silently going stale.

What's next

• Preview a page in the browser before you approve it → In-app UI preview
• See how it all connects (and where it's incomplete) → Graph view
• Then design your data model → Generating the database schema