> Source: https://mywaypoint.ai/docs/build
> Documentation index: https://mywaypoint.ai/llms.txt

# Getting started with Chip Build

**Describe the thing you need. Chip builds it in your workspace: a real table, the screen your team opens, the automation that keeps it current. It asks you exactly one kind of question on the way: the kind that changes what gets built.**

One build, from a prompt to a working space, using the request a support lead actually typed & what came back.


## For

- [For Support](https://mywaypoint.ai/for-support)
- [How Chip Works](https://mywaypoint.ai/how-chip-works)
- [For Revenue](https://mywaypoint.ai/for-revenue)
- [Platform overview](https://mywaypoint.ai/docs/platform)

## Before you start

Three things get a build started, all of them things you already know:

- **A problem in your own words, or a spec if you have one.** "I need to keep track of the support runbooks we're reviewing this quarter" is a complete request.
- **An idea of what one row is.** A runbook? A review of a runbook? Chip will ask if you leave it open.
- **A workspace with something in it, or a spreadsheet.** Chip builds against what you already have. If the data lives in a file, attach it & Chip reads the columns itself.

Open **Build** in the left navigation. The screen greets you by name, offers a box that says *Describe what you need in plain English — Chip builds it in your workspace* & shows four **Blueprints** down the right-hand side: a recruiting tracker, a spreadsheet turned into a real table, a weekly renewals digest, a contract intake. Each is a complete build you can start with one click.

![The Build screen: the composer that says Describe what you need in plain English, four Blueprints down the right, and the spaces list in the sidebar](https://mywaypoint.ai/static/assets/chip-build/flow-1-composer-full.png "Figure 1: the Build screen.")

## Step 1: Say what you want to be true

Example Request:

```prompt-request
I need to keep track of the support runbooks we're reviewing this quarter. Each runbook has an owner and moves through not started, in review, needs changes, then published. Put this in a new space of its own rather than an existing team's area. Seed it with about a dozen realistic example runbooks spread across the stages so I can see what it looks like before we load the real ones.
```

It says what one row is (a runbook), where the work should live (a new space), what the stages are & what "done" looks like (a dozen examples across the stages).

Four things genuinely change what Chip builds:

| Tips for better results | Why it matters |
|---|---|
| **Define the object you want to track.** | Decides what one row is, the table's grain. Expensive to change later |
| **Say where the data lives today.** | Typed by hand, imported from a file, synced from a system you have connected. Each is a different build |
| **Name what should happen on its own.** | A notification, a label, a scheduled check. Chip builds the ones you name |
| **Say who will open it & what they need to know.** | Picks the screen. "Which expire soon" is a sorted list. "What stage is each in" is a `kanban`. "How are we doing" is a dashboard |

Chip chats with you to clarify and align on key decisions before building:

![Chip's question card on a request about tracking job applicants: Should this live in a new, dedicated Recruiting Tracker space? Step 1 of 2, three options with the recommended one marked, Back and Continue](https://mywaypoint.ai/static/assets/chip-build/flow-1b-question-card.png "Figure 2: a question that changes the build. A different request from the one this guide follows; the runbook request answered this in its own words, so Chip went straight to the plan.")

## Step 2: Chip confirms the plan before it builds

Chip reads what is already in your workspace first. Then, before it creates anything, it writes the plan down & puts it in front of you. Here is what it showed, word for word:

> **Scope:** This will be a new space, separate from all existing team areas. The register will hold one row per runbook; no existing records, spaces, or automations will be changed.
>
> **Acceptance check:** You can open the new space, see the sample runbooks spread across all four stages, identify each owner, and move a runbook through the review stages.
>
> **Risks:** The example rows are real editable data in the new space. They can be removed later, but this build will create the space, table, board, and sample entries.
>
> **Build the new standalone space, editable register, stage board, and realistic sample data.** · **Confirm build**

That acceptance check is the sentence you will test the result against. If it is not what you meant, say so now: nothing has been created yet.

Chip writes the gate for the build in front of it, so the headings & the button change: *Confirm build* on the runbook request, **Create tracker** on the recruiting one, where the card also offered *Revise the plan* (keep it as a draft & say what should change before anything is created). On a smaller ask it may simply ask you to say yes.

![The confirmation gate headed Before I build this, with Changes, Triggers & Frequency, Impact and Scope, the sentence Please confirm that you want me to create this initial tracker, and a card offering Create the tracker, Revise the plan or Something else](https://mywaypoint.ai/static/assets/chip-build/flow-0-confirm-gate.png "Figure 3: the confirmation gate, on the recruiting request: Before I build this, then Changes · Triggers & Frequency · Impact · Scope, then the card. Captured with nothing created.")

## Step 3: Watch it work

Press **Confirm build**. An **Activity** line appears above Chip's reply as soon as it starts & climbs as it works, with its status in a sentence underneath: *I'm checking the Support Runbook Reviews workspace for runbook ownership, review dates, and current stage.* Chip builds autonomously from here & the screen keeps up as it works.

![A build in progress: the Activity row counting steps as Chip works, with its status underneath](https://mywaypoint.ai/static/assets/chip-build/flow-2-build-running.png "Figure 4: a build in progress.")

## Step 4: Read the report, then open the screen

When it finishes, Chip writes down what now exists, where to look & what it assumed.

![The runbook kanban at its own route: four columns, not started, in review, needs changes and published, with twelve cards](https://mywaypoint.ai/static/assets/chip-build/flow-4-kanban.png "Figure 5: the working screen.")

Ask a question of it while you are there. *"Which runbooks are overdue for review and who owns them? Group by stage."* comes back as **Review status found**. Where the data falls short, Chip says exactly that & names what is missing: *the workspace does not define a review deadline, so I cannot verify that any runbook is formally overdue.* That honesty is the reason you can ask it the big question first.

![Chip's answer headed Review status found: tables grouped by stage with owners and last-reviewed dates](https://mywaypoint.ai/static/assets/chip-build/flow-3-answer.png "Figure 6: an answer.")

## Step 5: See everything one request produced

Open the space. In the left panel is the inventory: one table (**Support Runbooks**), the screens over it & a **Files** list (*intent*, *overview*, *plan*) that Chip wrote as it went. The intent document carries your request verbatim & what Chip understood by it. The plan is the record of every decision, so the next person in reads why things are the way they are.

![The space's inventory panel: one table, three screens and the documents Chip wrote during the build](https://mywaypoint.ai/static/assets/chip-build/flow-5-space.png "Figure 7: the space.")

## The limit is your imagination

You have a table, a screen & a written record from one sentence, and Chip keeps the context of what it built. Every logical next step is one more sentence, the way the Blueprints already show:

- **"Every Monday at 9am, find the contracts renewing in the next 30 days and post them to Slack."** A scheduled digest. Chip builds it; nothing sends until you turn it on.
- **"Here's our contract spreadsheet, get it into the system."** *(attach the file)* Chip reads the columns, shows you the mapping before writing anything & asks only about the rows it would otherwise mangle.
- **"The thing that summarises escalations should also flag duplicates."** Describe the symptom; Chip finds it & comes back with a proposal before changing anything.

Bring the real one. The messier the better: the interesting part is what Chip decides & what it asks.

---