> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bloom.diy/llms.txt
> Use this file to discover all available pages before exploring further.

# Prompting Best Practices

> How to prompt Bloom to build better full-stack apps, faster.

Bloom is not a code assistant you micromanage.\
Bloom is a **full-stack app builder.**

That means the way you prompt Bloom should look more like a **product brief** than a technical spec. If you prompt Bloom the way you would Cursor, Claude Code, or a0.dev, you’ll slow yourself down—and often get worse results.

This guide shows you how to prompt Bloom so it can do its best work.

***

## The Core Mental Shift

### From “Tell me how” → “Show me what”

Most coding agents expect you to specify:

* Database schemas
* Libraries and frameworks
* Routes, endpoints, and UI structure
* Low-level implementation details

Bloom already knows:

* The stack (Expo + Convex)
* How real-time data sync works
* How authentication and permissions should behave
* Mobile-first UI and performance best practices

<Note>
  **Your job is not to explain the stack.**\
  Your job is to explain the product.
</Note>

***

## The D.N.A. Prompting Framework

Bloom works best when you prompt in terms of **user experience**, not technical execution.

Use the **D.N.A. Framework**:

<Steps>
  <Step title="D — Describe the User" icon="user">
    Who is using the app, and in what situation?
  </Step>

  <Step title="N — Narrate the Journey" icon="map">
    What happens step by step when they use it?
  </Step>

  <Step title="A — Atmosphere / Vibe" icon="palette">
    How should the app feel emotionally?
  </Step>
</Steps>

This gives Bloom enough context to make thousands of correct technical decisions automatically.

***

## D — Describe the User

Always start with **who the app is for** and what state they’re in.

This helps Bloom infer:

* Touch target size
* Navigation complexity
* Contrast and accessibility
* Error handling and guardrails

<CardGroup cols={2}>
  <Card title="Good" icon="check">
    “I’m a delivery driver using the app one-handed while walking.”
  </Card>

  <Card title="Bad" icon="x">
    “Build a dashboard screen.”
  </Card>
</CardGroup>

You don’t need detailed personas—just **situational clarity**.

***

## N — Narrate the Journey

Don’t list features.\
**Tell the story of what happens.**

Focus on:

* What the user sees first
* What they do next
* What should feel instant or reassuring
* What outcome they expect

<CardGroup cols={2}>
  <Card title="Good" icon="check">
    When I open the app, I immediately see today’s tasks.\
    When I complete one, it disappears instantly so I feel progress.
  </Card>

  <Card title="Bad" icon="x">
    Add CRUD functionality for tasks.
  </Card>
</CardGroup>

Bloom translates journeys into:

* Real-time subscriptions
* Optimistic UI updates
* Animations and transitions
* Data models and permissions

***

## A — Atmosphere / Vibe

This is where **vibecoding** matters.

Use **emotional adjectives**, not design tokens.

Atmosphere influences:

* Layout density
* Motion and animation
* Visual weight and rhythm
* How serious or playful the app feels

**Examples:**

* Calm and reassuring
* High-energy and social
* Industrial and utilitarian
* Minimalist and polished

<Info>
  You do not need to specify colors, fonts, or CSS unless you want to override Bloom’s defaults.
</Info>

***

## What *Not* to Do with Bloom

### Don’t micromanage implementation

Avoid prompts like:

* “Create a users table with these columns…”
* “Use JWT with refresh tokens…”
* “Poll every 5 seconds…”

Bloom already knows the optimal way to do this in its stack.

<Note>
  If you care about **behavior**, describe the behavior.\
  Bloom will choose the best implementation.
</Note>

***

### Don’t bundle unrelated changes

Bloom works best when each message contains:

* One new feature, **or**
* One clear improvement, **or**
* One bug to fix

If you need multiple things:

* Send multiple messages, or
* Clearly separate them as part of one user journey

***

## When to Be Explicit

Specificity helps when you care about:

* A particular interaction (e.g. “long-press to delete”)
* A hard constraint (“never visible to other users”)
* An aesthetic override (“monochrome, no shadows”)
* A bug or incorrect behavior

If something breaks, describe:

* What you expected
* What actually happened
* Where in the flow it occurs

✅ Include error messages if visible\
❌ Avoid “fix this” or guessing the implementation

***

## Bloom vs Other Agents

Why this matters:

| Tool                 | How You Prompt                      |
| -------------------- | ----------------------------------- |
| Claude Code / Cursor | Step-by-step technical instructions |
| a0 / Rork / Vibecode | Explicit UI and logic changes       |
| **Bloom**            | Product vision and user experience  |

Prompt Bloom like a generalist tool, and you’ll limit its strengths.\
Prompt Bloom with **D.N.A.**, and you’ll get better UX, faster iteration, and fewer back-and-forths.

***

## Example: Rewriting a Prompt for Bloom

<CardGroup cols={2}>
  <Card title="Instead of" icon="x">
    Add authentication with rate limiting and error handling.
  </Card>

  <Card title="Try" icon="check">
    I’m a forgetful user who worries about security (D).\
    If I fail login too many times, I want to feel protected from hackers (N).\
    The screen should feel heavy, serious, and secure—like a vault (A).
  </Card>
</CardGroup>

Bloom handles:

* Auth flows
* Rate limiting
* UI feedback
* Security posture

You focus on **intent**.

***

## Final Rule of Thumb

<Check>
  If your prompt sounds like a spec sheet, you’re over‑prompting.\
  If it sounds like a movie scene, you’re doing it right.
</Check>

Bloom isn’t here to follow instructions.\
It’s here to **interpret your vision and build the product**.

Describe the user.\
Tell the story.\
Set the vibe.

**Let Bloom handle the rest.**