# Writing prompts The quality of what Build generates is directly tied to the quality of the prompt. This page covers what to include in an initial prompt and how to phrase follow-ups for precise iterative changes. *** ### Initial prompts An initial prompt should describe the app in enough detail that Build can make confident decisions about architecture. You don't need to specify every detail, but the more you cover, the less Build has to guess. Useful things to include: * The app's core purpose in one or two sentences * The main user roles and what each one does * The key pages or views * Any specific technical requirements (database, auth method, third-party integrations) * Visual preferences, if they matter dark mode, a reference product, a color palette **Example vague prompt** ``` Make a web app for managing tasks. ``` This works, but Build will make many assumptions. The output may not match what you had in mind. **Example specific prompt** ``` Build a task manager for small teams. Users can sign up and belong to a workspace. Inside a workspace, users can create projects and add tasks with a title, description, due date, assignee, and priority (low / medium / high). Tasks can be viewed in a list or Kanban board. Include email notifications when a task is assigned. Dark mode by default. ``` This gives Build enough to make the right decisions on architecture, data model, and UI without over-constraining it. *** ### Follow-up prompts Follow-ups are instructions to modify the existing codebase. Be specific about what you want changed and, if relevant, where. | Instead of | Try | | --------------------- | -------------------------------------------------------------------------------------------------- | | *Fix the dashboard* | *The KPI cards on the dashboard are not aligned on mobile. Stack them vertically below 768px.* | | *Add payments* | *Add Stripe Checkout for a single $29/month subscription plan. Redirect to /dashboard on success.* | | *Make it look better* | *The sidebar feels cluttered. Remove the icon labels and increase the spacing between nav items.* | *** ### Referencing real-world products It's useful to reference an existing product as a visual or structural reference. Build understands these references and uses them to guide layout and interaction patterns without copying them. ``` The dashboard layout should feel similar to Linear clean, minimal, keyboard-navigable, with a command palette. ``` ``` The onboarding flow should work like Notion's one step at a time, no forced sign-up before showing the product. ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.codemate.ai/build/writing-prompts.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.