The five phases in practice

What you’ll learn

• What you can change on the Set up page after the first set-up.
• How Check and Plan protect you from building the wrong thing.
• How a build moves from stage to stage.
• What to do when a step fails.

Set up: where the code lives

During set-up Claude reads the tickets and finds where each one lives: commits that mention it, the names in it, and where that code is defined. It uses your organisation's code search (Sourcebot), or searches GitLab directly when there is none. It changes nothing.

The Set up page then shows Tickets and where they’re built, the branches per environment, and how the feature is built. To change anything, use Ask Claude to change something: Claude checks branches and layers, and proposes the change. You save it as a new setup version.

Check: the app's own checks

The app checks the setup itself: the validator's rules and the branches on GitLab. Problems are listed with what to fix. Tell Claude in the panel and it proposes the fix. Ask Claude to check everything adds the checks that need judgement. When it's right, click Continue to planning.

Plan: the contract

Make the plan produces, per repository and ticket, what will change, in stages called tiers, with the branches and the time logged on every commit. If you disagree, tell Claude and Re-plan. Nothing is branched until Approve and start Tier 1.

Build: stage by stage

Claude implements the tickets one stage at a time, in a temporary copy of the repositories, and opens one merge request per repository. Every push and merge request creation waits for your approval.

The Build page shows:

• the Tiers and where each stands;
• the Merge requests, with their review notes;
• the Run state;
• the Designs linked to the tickets.

When a stage is done, click Confirm and continue to the next stage. Some stages need the previous one merged first — for example, an API that uses a shared library needs the library's merge request merged and published. The page says so before you confirm.

Example: team-invites has three tiers. Tier 1 changes core-lib; you approve the push, a reviewer merges the merge request, and the library is published. Only then do you confirm Tier 2, where Claude changes the accounts API to use the new library version.

Tip: one step runs at a time per feature. While Claude works, a spinner shows next to the feature in Recents and in the Ask Claude button.

Document

Claude writes the run documentation and the API collection exports for each environment. Download them from the Document page, or Write the documentation again after changes.

When a step fails

The feature's page says why, and you get a notification. The cause is often a token that expired or a branch that moved. Fix it — for example save a new GitLab token in Connected accounts — then start the step again.

Tip: changing the setup after the plan makes the run state out of date. The page asks you to re-plan before the next stage, so the plan always matches the setup.

Check yourself

1. Where do you change the repository a ticket is built in, after set-up?

On the Set up page, with Ask Claude to change something (or by removing the repository), then save the new setup version.

2. Why might the page refuse to let you confirm the next stage yet?

The next tier depends on work from the current one that must be merged (and sometimes published) first.

3. A build step failed with a GitLab 401 error. What is the likely fix?

Your GitLab token expired or lacks rights. Save a new token, then start the step again.