Prompting Best Practices

Bloom is not a code assistant you micromanage.
Bloom is a full-stack mobile 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

---

​

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: 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

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

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

---

​

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.

---

​

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: 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

Bloom handles:

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

You focus on intent.

---

​

Final Rule of Thumb

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.