Projects & repositories
Where the code lives, and how it lands.
One project, set up the way your team ships.
A project holds the repositories agents work in and everything that decides how they work there: who may use it, the branch changes land on, its checks and how many tasks run at once. Connect your Git account in the guided setup — GitHub in one click, or GitLab, Bitbucket and Azure DevOps — and create a project from a repository. Its first task is a guided onboarding run that works out how the code runs, fills in its stack and makes sure its checks exist and pass.
- Access, branch, checks and caps per project
- GitHub, GitLab, Bitbucket or Azure DevOps
- An onboarding task on every new project
Every repository a change touches, in one project.
Add every repository the work spans: agents work in all of them, and the checks run in the primary. Pick one your connected Git accounts reach, paste any address, or create a new private repository from the project wizard or any repository row — an empty one gets its main and develop branches for you. Every pull request a task opens, one per repository, is listed with its state on the task board and the task page.
- Several repositories, one primary
- Pick, paste or create a repository
- Every pull request a task opened, with its state
Merge lanes: a merge queue that finds the culprit.
Merge lanes are a merge queue for high-volume delivery: finished pull requests are batched and tested together, through suites of millions of tests, and only a green build reaches your branch. When a batch fails, the lane bisects it to the change that broke it, ejects that one and merges the rest. Switch a lane off and its queued pull requests still merge first; Stop lane ends its runs at once and hands each pull request back to its own task.
- Batched through suites of millions of tests
- A failed batch bisected to its culprit
- Stop lane hands each pull request back
Project memory: one task learns, the next is told.
Agents keep notes on each project as they work: a gotcha and how to reproduce it, a recipe that worked, a map of the code. Each note is handed to the later tasks it concerns; its row counts the tasks that were given, saw and used it, sorts by those counts, and opens in full. Retire a note that has gone stale, or purge it for good.
- Gotchas, recipes and code maps, per project
- Given, seen and used, counted and sortable
- Each note opens to its full text
Which repository would go first?
Start free, then pick the plan that fits how many repositories you run and how many changes land in them.