Prompting Guide
Ember is a real product, not a parlor trick. The better your prompt, the closer the first result lands to what you actually want, and the fewer iterations it takes to ship. This page is the field guide for getting what you want.
The first prompt - what to include
The spec collector is built to ask clarifying questions, but it cannot read your mind. A few minutes spent on the first prompt saves a lot of iteration time later.
Strong first prompts include:
- What the thing is. A landing page, a Telegram bot, an X automation, a chat agent. Be explicit. "A landing page for my crypto consultancy" beats "a site about my business".
- Who it is for. "For founders looking to hire a fractional CTO" tells the system who to design and write for.
- The vibe. Words like "minimal", "playful", "professional", "brutalist", "warm", "dark" all map directly to design decisions the system can make. Pick one or two.
- One or two specific must-haves. "With a contact form that captures email", "with three pricing tiers", "with a section showing my past clients". These ground the spec.
Weak first prompts are vague ("build me a website"), purely emotive ("something that looks great"), or contradictory ("minimal but with lots of animations"). They produce vague results because the system has no anchors.
A good first prompt looks like this
Build me a landing page for a fractional CTO service. Target audience is early-stage founders. Dark theme, warm accent colour, minimal vibe. Hero with a strong tagline about shipping software faster, three feature cards explaining what I do, a section with testimonial quotes, and a contact CTA at the bottom.
That gives the system everything it needs to produce a coherent first build. Iterations from there are tweaks, not rewrites.
Picking a target
Ember builds four kinds of things. Pick the right one up front so the spec collector routes you to the right templates.
| You want to build | Target type | Example phrasing |
|---|---|---|
| A website (marketing, portfolio, blog, app dashboard) | Web | "A landing page for X", "A portfolio site showcasing my projects" |
| A Telegram bot that replies to commands | Telegram bot | "A Telegram bot that schedules reminders", "A bot that auto-replies in a community group" |
| An X (Twitter) automation | X bot | "A bot that posts daily updates about Bitcoin price", "An auto-replier for my X mentions" |
| A conversational AI agent (chat panel + tools + integrations) | Agent | "An agent that helps users debug their code", "A research assistant agent" |
The spec collector will usually pick the right target on its own from your wording, but being explicit removes ambiguity. "Build me a Telegram bot that..." is better than "Build me something for Telegram".
If your idea spans multiple targets - say, a landing page for a Telegram bot you built elsewhere - build them as separate projects in Ember and link them however you want.
Templates: when to be specific vs let Ember pick
Ember has production-grade templates for the common patterns: landing pages, portfolios, pricing pages, blogs, docs sites, link-trees, chat agents. If your request maps cleanly to one of those, you do not need to name it - the spec collector will route correctly.
If you have a strong opinion about the structure, name the pattern explicitly:
- "A landing page like a SaaS marketing site" routes to the landing template
- "A portfolio with project cards and case studies" routes to the portfolio template
- "A pricing page with three tiers" routes to the pricing template
If your idea is genuinely unusual and does not fit a known pattern, describe the structure section by section instead of naming a template. Ember will still build it, just through the more flexible generation path. That path takes a little longer but it is more powerful.
Iterating - phrasing for changes
Once your project is built, every chat message becomes an iteration. Each phrasing maps to a different speed and shape of change.
Quick visual tweaks
These are the fastest changes. Phrase them as direct edits:
- "Change the headline to 'Ship faster, scale further'"
- "Make the accent colour navy"
- "Tighten the spacing in the hero section"
- "Add a tagline under the headline that says..."
The system recognises these as content-level edits and runs the fastest generation path.
Structural changes
When you want to add a new section, swap layouts, or restructure the page:
- "Add a section after the features grid showing four testimonial quotes"
- "Move the contact form to the bottom and replace the current bottom CTA with a 'Get in touch' button"
- "Switch from a centred hero to a split-hero layout with image on the right"
These run through a multi-file generation path. The system understands the whole project's structure and emits coordinated changes across all the affected files.
Complex refactors
When you want to substantially reorganise the project or add capabilities that touch many parts of the codebase:
- "Restructure the whole site so the dashboard lives in its own route and add a sidebar nav for it"
- "Add user authentication with Supabase, gate the dashboard behind login, and keep the marketing page public"
- "Refactor all the feature cards to use icons and shorter copy"
These go through the agentic loop, where the system explores the existing code, plans the changes, implements them across multiple files, and verifies the result compiles. You can watch the agent work in real time in the dashboard. Complex refactors are where Ember really earns its place - most vibe-coding tools cannot do this at all.
Tips that make a big difference
Be specific about voice. "Professional but not corporate", "casual and energetic", "technical with dry humour" - these all change the copy the system writes. The system writes in whatever voice you specify and stays consistent across iterations.
Anchor with examples. "Like Linear's landing page", "Like Stripe's pricing page but warmer", "The voice of Notion's marketing". The system understands references and uses them as design anchors. You do not need to be exhaustive - one or two anchors per project is plenty.
Say what you do not want. "Don't use stock-photo language", "No emojis in the body copy", "Don't add testimonials, I'll add them myself later". Negative constraints help the system stop second-guessing.
Iterate one thing at a time when something feels off. If you say "the hero feels wrong, the colours are too cold, and the feature cards are confusing" you will get a confused response trying to fix everything. Pick the most important issue, fix it, then move to the next.
Use the preview window to evaluate. The preview hot-reloads as you iterate. Click around. Read the real copy. The system optimises for what you say, but you spot the actual problems by interacting with the result.
Working with the agent target
The agent target builds autonomous LLM agents that run independently. Prompting an agent is different from prompting a static website.
Spec the agent's role precisely
Agents work best when their job is well-defined. "An assistant" is too broad. "An assistant that answers customer support questions about my pricing and refund policy, escalates anything else to a human, and never invents facts" is shippable.
The spec should cover:
- What the agent does. Concrete tasks.
- Who it talks to. End users, your team, both.
- What it must not do. Hallucinate, recommend competitors, share private data.
- How it should sound. Formal, casual, technical, witty.
Tools
Agents can be given tools the platform supports - making HTTP requests to allowlisted hosts, sending messages on Telegram, X, or Discord, and (coming soon) querying databases and running scheduled triggers. To enable a tool, just say so during iteration:
- "Give the agent the ability to fetch documentation from api.github.com" enables HTTP tools
- "This agent needs to send Telegram messages" enables the Telegram tool and prompts you for your BotFather token
- "It should be able to check the user's calendar" tells the system to set up the calendar integration
The agent's system prompt is updated automatically to make it aware of the tools available.
Iteration
Just like web projects, agents iterate via chat. "Make the agent more concise", "Add a step where it confirms the user's intent before doing anything destructive", "It should respond in the same language the user used" are all valid iteration prompts.
The agent's behaviour updates without redeploying. The next message they send to your agent uses the new behaviour.
Common gotchas
The spec collector will ask clarifying questions before building. Answer them. Trying to skip the questions by clicking Build too early gives the system insufficient information and produces worse results.
The system will refuse some requests. If you ask for something that the security gate flags - hardcoded credentials, calls to non-allowlisted hosts, dangerous code patterns - the system will surface a friendly error and ask you to rephrase. This is the platform protecting you and your users. Rephrase the intent without the unsafe specifics.
Generated apps cannot use packages outside the curated allowlist by default. If you need a specific library, ask for it in the iteration. The platform may add it to the allowlist if it passes the security review.
The preview is hosted by Ember. Anything that requires the app to be at a specific public URL (custom domain, webhooks pointed at the prod URL) needs the project to be published first. The preview is for visual iteration; publish is for going live.
Agent inference bills to your own provider account, not Ember's. When you paste your Anthropic or OpenAI key for an agent project, every message that agent processes (chat panel, Telegram, scheduled triggers) is billed to your account directly. This is the platform's BYO model - it keeps the platform's pricing predictable and your agent usage uncapped.
Where to go next
- New to Ember? Start with the System Overview for the product story.
- Building an agent and want to see how the architecture supports it? Read How It Works.
- Building something secure? The Why It's Defensible page covers the security guarantees.