8.2 — Getting better output

A handful of habits that consistently improve what you get out of VibeMap.

Make the prompt do real work

The single highest-leverage edit you can make is your initial prompt. Five minutes there saves hours later.

A great prompt:

• Names the user specifically. "Built for cost-conscious first-time scuba divers in Northern Europe planning their first overseas trip."
• Names the differentiator. "Unlike PADI Travel, we surface real total prices including all gear hire and surcharges."
• Scopes v1 explicitly. "v1: browse listings + book a single dive. Reviews, operator dashboards, and group bookings are post-v1."
• Skips the tech stack unless it's a hard constraint.
• Skips marketing copy. "Revolutionary platform" is noise; "marketplace for Red Sea liveaboards" is signal.

Read every persona

Personas drive every user story. If the personas are vague, your stories will be vague.

After generation, read each persona. Ask: Could I describe this person to a friend in one sentence? If not, edit the persona — give it specifics. Then your user stories will automatically improve.

Use the right level of feature granularity

A feature should be a coherent product capability, not a single screen.

5–12 features at the top level is the sweet spot for most v1 specs.

Edit ACs to read like passing tests

An acceptance criterion should be so specific you could write a test for it.

Bad ACs (don't ship these to your agent):

• "Login works"
• "Page looks good on mobile"
• "Add filters"

Good ACs (ship these):

• "User can sign in with email + password; invalid passwords show inline error; successful login redirects to /dashboard"
• "Page is fully usable at 320px viewport; nav collapses to hamburger below 768px; no horizontal scroll at any breakpoint"
• "Filter sidebar with price-range slider (min/max from listings), location dropdown, and rating checkbox; results update on filter change without page reload"

The "extra" sentence on a good AC is the difference between three iterations and one.

Approve in small waves, not all-at-once

Don't try to approve 80 ACs before starting the build. Approve 10. Plan. Build. Approve 10 more. Re-plan. Build. Repeat.

Why this works:

• You'll catch spec mistakes before your agent builds against them.
• You'll learn your agent's quirks on small batches and adjust.
• You'll keep momentum — staring at a wall of unapproved ACs is a productivity killer.

Trust the dependency graph

When VibeMap says AC B depends on AC A, don't override it casually. The dep graph is what lets your agent work the right things in the right order. If you're sure an edge is wrong, edit it — but verify first.

A common mistake: marking every AC as independent because the dep graph "slows down" your agent. It doesn't; it stops your agent from picking up un-buildable work.

Use the Deep model only when it matters

For most generations, Balanced is right. Use Deep when:

• You have 50+ ACs and the dependency graph keeps coming out wrong.
• Your schema needs to capture a complex relational pattern (audit trails, soft-deletes, polymorphic associations).
• You're regenerating acceptance criteria for a feature with subtle business logic (billing, permissions, financial calc).

Use Fast when:

• You're regenerating personas you'll edit by hand anyway.
• You're iterating on a feature title and want a fresh AC draft to compare.

Keep the spec close to the truth

If you decide mid-build that you actually need a different user flow, update the spec before telling your agent. The agent reads from the spec — a stale spec produces stale code.

A 10-minute weekly spec refresh:

1. Open the Features tab.
2. Delete features you've decided to drop.
3. Edit features whose scope shifted.
4. Add any new ACs you've thought of.
5. Re-plan from the Plan tab.

Then your agent's next-ready queue is back in sync with your actual roadmap.

Use the audit log as memory

Coming back to a project after a break? Don't try to remember where you left off. Open the Track tab and look at the recent events stream. It'll tell you exactly what was claimed, submitted, passed, or blocked — and by whom.

The audit log is also useful for:

• Showing teammates what your agent did last week
• Diagnosing why an AC got stuck
• Convincing yourself the agent really did finish that thing you can't remember finishing

Leave room for your agent to think

When you ask your agent "What should I work on?", the better question is "Use vibemap_get_next_ready_criterion to pick the next thing, then think aloud about your approach before you start coding."

The MCP server gives your agent the what. You give it the how to think about it. A few seconds of agent reasoning per AC catches things tests don't.

Where to go next

• Back to the start → 1 — Getting started
• API reference → 4 — API reference
• MCP tools → 5 — MCP server