# Your first task

> Give Agent mode a small code change, approve the proposal, follow the work in Orchestra, and review the resulting pull request.

This walkthrough takes one code change from a written request to a pull request. You stay in control of what starts, and you make the final merge decision.

Before you begin:

- Index the repository with the [Quickstart](https://docs.fatelabs.ca/quickstart).
- Connect the Estelle GitHub App and grant it access to that repository so Estelle can push a branch and open a pull request. See [GitHub](https://docs.fatelabs.ca/github).
- Make sure your account has credits available for the build. If it cannot start, Estelle tells you before doing the work.

**Tip:**

Start with a narrow change that has an observable result. The [example repository](https://docs.fatelabs.ca/example-repo) shows the kind of review and test output you can inspect afterward.

## Write a request the agent can test

Name the repository, the behavior you want, and how you will know it works. Include an error case when one matters.

```text
In acme/api, add a GET /health endpoint that returns a 200 response with {"status":"ok"}. Add a test for the response.
```

Other useful request shapes:

```text
In acme/web, reject an empty email on the sign-up form with the message "Enter your email". Add tests for empty and valid input.

In acme/api, add limit and cursor parameters to the orders list. Default limit to 50 and test both parameters.
```

Avoid requests such as "clean up the code" or "make it faster" unless you also name the scope and the result you want. If you need to explore first, use **Ask** mode to understand the relevant code before requesting a change.

## Start the build

### Describe the work in Agent mode

Open [Estelle in the dashboard](https://app.fatelabs.ca/dashboard/ask) and choose **Agent** above the message box. Select the repository if the page asks for one, then send your request.

You can attach a specification, screenshot, or other supporting file with the paperclip. Attachments on a build request are passed to the coding agent.

### Review and approve the proposal

Estelle replies with a proposal that names the action and its settings. Check the repository, task, and anything the action will change.

The card says **Nothing happens until you choose.** Your options are:

- **Allow once** to run this action one time.
- **Always allow**, when offered, to remember this kind of approval for the workspace.
- **Change it** to revise the request before anything runs.
- **Refuse it** to stop the action. You can include a reason for the agent.

Choose **Allow once** for a first task.

### Follow the work in Orchestra

After approval, Estelle starts the build in a **Silo**, a cloud computer for the work. The conversation links to the build and its current state.

Open [Orchestra](https://app.fatelabs.ca/dashboard/orchestra) to follow each step, open the agent's session, or send additional context. If the build is going in the wrong direction, use Orchestra's controls to pause or cancel it.

You do not need to keep the page open. The final message tells you what completed, what was tested, and where to find the result, or explains why the build stopped.

### Answer when the build needs you

If the agent reaches a decision only you can make, Estelle posts a **needs you** message in the Agent conversation and waits.

Reply with the decision or missing context. Do not leave a waiting build unattended indefinitely; resume it when you have the answer or cancel it in Orchestra.

### Review the pull request

When the build delivers its change, open the pull request and review:

1. The diff and whether it matches your request.
2. The test and check results, including any failures or checks that did not run.
3. **Prism**'s review, including inline findings and anything Prism could not review.
4. **Twice** results when a running-app test is part of the work.

A pull request is a proposal, not an approval. If it is a draft or its description reports a problem, resolve that problem before treating it as ready. Ask the agent for another change or edit the branch yourself.

### Merge when you are satisfied

Merge through GitHub or from the session's pull request view. By default, Estelle does not merge for you and does not deploy the merged code.

Automatic merging is a separate opt-in workflow with its own controls. See [Autonomy](https://docs.fatelabs.ca/autonomy).

## Understand the result

| Result | What to do |
|---|---|
| Pull request with completed checks | Review the diff and findings, then merge or request changes. |
| Draft pull request | Read the reported reason and the checks. It still needs work or a deliberate human review. |
| Build needs you | Answer in the Agent conversation, or cancel the build in Orchestra. |
| Build stopped or failed | Read the final message and the failed step. Correct the request or environment before retrying. |
| Prism could not review | Treat that as an incomplete review, not as a finding or a clean result. Retry after addressing the stated cause. |

## Limits

- Estelle works from the repository and index available to it. Re-index when recent code is missing, and verify important answers against the files.
- Builds and their coding agents use credits. The dashboard reports when the account cannot start or continue the work.
- Prism comments and reports findings; it does not approve, request changes, or merge.
- Estelle does not deploy your change. Your normal release process starts after you merge.

## Related

- [Agent mode](https://docs.fatelabs.ca/agent-mode): Learn about proposals, approvals, attachments, and live cards.
- [Orchestra](https://docs.fatelabs.ca/orchestra): Follow, message, pause, or cancel a running build.
- [Prism](https://docs.fatelabs.ca/prism): Understand review verdicts, findings, and incomplete reviews.