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

# Writing initial prompts

The prompt is the most important thing you write in the app builder. The plan, the build, the eventual app — all of it traces back to how you described what you wanted. A good prompt isn't long. It's specific about the right things and silent on the rest.

## What to include

<AccordionGroup>
  <Accordion title="The audience — who uses it">
    Internal team only? Client-facing? Both? When the audience is mixed, name what each side does. "Our team assigns goals; clients check them off" tells the app builder two views, two workflows.
  </Accordion>

  <Accordion title="The outcome — what the app makes possible">
    What does the app let someone do that they can't do today? Lead with this. "Track which clients have completed onboarding" is an outcome. "A table" is not.
  </Accordion>

  <Accordion title="The primary actions — what users actually do">
    Not every action, just the core ones. "Internal user creates a goal, assigns it to a client, sets a due date. Client marks goals complete. Team gets notified when goals are completed or overdue."
  </Accordion>

  <Accordion title="The business-specific definitions">
    If your prompt uses a term that has a definition specific to how you operate — "at risk," "onboarded," "active," "blocked" — say what it means. The app builder will guess otherwise, and the guess might not match how your firm thinks about it.
  </Accordion>

  <Accordion title="External services, if any">
    If the app should integrate with Stripe, Slack, Calendly, or something else, say so. The app builder will ask for the credentials during the build.
  </Accordion>
</AccordionGroup>

## What to skip

<AccordionGroup>
  <Accordion title="UI specifics — colors, fonts, layouts">
    The app builder uses Assembly Studio's design system. Describing visual choices in the prompt rarely helps and often boxes the build into a worse layout than the one the app builder would pick.
  </Accordion>

  <Accordion title="Tech choices">
    Frameworks, databases, hosting, APIs. The app builder handles these. Mentioning them adds noise.
  </Accordion>

  <Accordion title="Schemas and data models">
    Don't try to spec out the table structure. Describe what the app does and the app builder infers the data model from there.
  </Accordion>

  <Accordion title="Implementation steps">
    The prompt is a description of the app, not a build plan. Leave the sequencing to the app builder.
  </Accordion>
</AccordionGroup>

## Worked examples

### Example 1: A client check-in app

<CodeGroup>
  ```text Strong theme={null}
  A weekly check-in app for our coaching clients.

  Every Monday at 9am, each client gets a short form: how
  was last week, what's the focus this week, anything
  blocking them. Their answers show up in our team's
  dashboard sorted by client, with red flags surfaced at
  the top — a client is "red flag" if they're blocked or
  if they skipped last week's check-in.

  Our team can leave a note on any check-in that the
  client doesn't see. If a client says they're blocked,
  the assigned coach gets an in-product notification.
  ```

  ```text Weak theme={null}
  Build me a check-in app for clients with notifications.
  ```
</CodeGroup>

### Example 2: An internal deal pipeline

<CodeGroup>
  ```text Strong theme={null}
  An internal sales pipeline for our team.

  Deals move through stages: New, Discovery, Proposal,
  Negotiation, Closed Won, Closed Lost. Each deal is tied
  to a company in our CRM and has an owner, a value, and a
  next step. We need a board view (cards in columns by
  stage) and a list view (filterable, sortable by value
  and last touched).

  Staff can move their own deals. Only admins can move
  deals to Closed Won or Closed Lost. Owners get notified
  by email when a deal sits in one stage for more than 14
  days.
  ```

  ```text Weak theme={null}
  CRM with deals and a kanban.
  ```
</CodeGroup>

### Example 3: A client request portal

<CodeGroup>
  ```text Strong theme={null}
  A request portal for our clients.

  Clients submit requests with a title, description,
  priority (low/medium/high/urgent), and optional file
  attachment. They see the status of each request:
  Received, In Progress, Waiting on You, Done.

  Our team gets a queue in the Dashboard, sorted by
  priority then by submission date. Staff can change
  status, assign a request to a teammate, and reply
  inline. The client gets emailed when status changes
  or when we reply.
  ```

  ```text Weak theme={null}
  A help desk app.
  ```
</CodeGroup>

## Common mistakes

<Warning>
  Trying to build several apps at once. "An app that tracks deals AND handles invoicing AND sends weekly digests" is three apps. The app builder will build one mediocre app instead of three good ones. Build them separately.
</Warning>

<Warning>
  Over-specifying the UI. "A blue header with the logo on the left, four cards in a row, and a dropdown menu in the corner" is a design spec, not an app description. Describe what the app does; let the app builder handle the layout.
</Warning>

<Warning>
  Under-specifying the trigger words. "Notify the team when something important happens" leaves the app builder guessing. Define what counts as important.
</Warning>

<Warning>
  Skipping the audience. Studio will ask, but you'll get a better plan if you say up front whether the app is internal-only, client-facing, or both.
</Warning>

<Tip>
  When in doubt, write your prompt as if you were briefing a new team member who's smart but doesn't know your business. That's roughly what the app builder is — capable, but it needs context that's obvious to you.
</Tip>