# Workflow

> The end-to-end loop, from creating a project to merging a pull request.

Every project follows the same loop. Once you've seen it once, the rest of the docs just fill in detail.

## 1. Create a project

A project is your workspace. The New Project flow offers several ways in:

- **Git URL** — paste any HTTPS or SSH URL. Private repos authenticate via your connected GitHub account.
- **Start fresh** — create a project without a repository and connect one later.
- **Empty repo** — a private GitHub repo is created for you, so there's always a target for pull requests.

The sandbox clones the repo (when you have one), installs dependencies, and boots the dev server while you watch the output stream live.

## 2. Start a chat thread

Each project keeps chat threads. The lead agent in a thread is persistent — every message you send creates a new execution attempt, but the agent and its history carry across turns. The [Project Map](https://darting.dev/docs/introduction/) shows shipped work, in-flight threads, and proposed plans across the whole project.

## 3. Describe the outcome

Tell the lead agent what you want. It self-assesses complexity:

| Path | What happens |
| ---- | ------------ |
| Direct | Simple asks get implemented immediately |
| Brief plan | Moderate work gets a short approach, then code |
| Living plan | Complex work becomes a versioned plan you **Build** when ready |

See [How the lead agent works](https://darting.dev/docs/lead-agent/) for details.

## 4. Let the swarm work

The lead agent writes files, runs commands, and can dispatch sub-agents and automations. Heavy work — builds, test suites, Playwright runs — happens inside [isolated sandboxes](https://darting.dev/docs/isolated-sandboxes/), not on your machine.

## 5. Review

The Code tab shows branch-aware diffs. The Git tab shows an SVG branch graph where you can click any commit to see its diff. While agents work, a live terminal, dev-server logs, and a streamed desktop are always in view. Implementation tasks often return [video proof](https://darting.dev/docs/video-proof/) of the feature working.

## 6. Open a PR and merge

When you're happy, open a pull request with a drafted title and body. The orchestrator [tracks CI, pushes fixes if checks fail, and marks the PR ready](https://darting.dev/docs/pull-requests-and-ci/) when they pass. **Arm auto-merge** when you want green checks to land without you — nothing merges until you opt in.

That's the whole loop. Repeat it across as many threads as you like — each runs in its own sandbox, so they never collide. The [merge queue](https://darting.dev/docs/git-and-commits/) groups open PRs by file overlap so unrelated work can land in parallel.