The Builder and its Steps

The Builder lists the tickets of your enabled projects, and takes the ones you start through the same seven Steps. Each Step blocks the next. The agents are the same for the whole team, their prompts and their permissions, whoever starts the ticket. Each member chooses only their harness and its model.

Start a ticket

Choose Start on a ticket's row, then how it starts.

  • With a plan. The planner designs the change with you first, and the ticket goes through every Step.
  • Without a plan. The ticket goes straight to Resolve, and the first two Steps are skipped.

A ticket of a published plan enters the Builder by itself, when you choose Implement on the plan.

The seven Steps

  1. Plan & revision. The planner drafts the change and asks what it cannot decide alone. You end it with Implement, or by publishing again if the ticket changed.
  2. Publish. The publisher writes the plan to your tracker and your documentation. The page on Plans says what.
  3. Resolve. A resolver implements the ticket in its own worktree, runs your repository's checks, and pushes the ticket's branch.
  4. Pull request. Your team opens the pull request. Within a few minutes of a new comment, the resolver reads it, fixes what it can prove, and leaves you the reply, ready to paste. A comment that needs a decision waits for you.
  5. CI. Tillerly follows your build. A new commit starts it again.
  6. QA. When the build is green, QA waits for you. You choose QA Done.
  7. Merged. Your team merges on the code host. Tillerly sees the merge and closes the ticket. A declined pull request closes it as declined.

Several tickets at once

Each member chooses how many tickets they work at once, on the harness page of the settings, up to what your organization allows. Each ticket has its own resolver, resolver 1 to resolver N, and its own worktree on your machine. A ticket stays on its resolver. Lowering the number makes the tickets of the resolvers turned off wait until you raise it again.

What the resolver follows

When a project's Follow comments is on, in its settings, the resolver that holds a ticket starts again within a few minutes

  • for a new comment on its pull request, a review of the comments,
  • for a new comment on its tracker, while it waits for you or its pull request is open, such as an answer to its question.

A comment that comes while the build is red starts a fix of the build instead. Your own comments on the pull request start nothing by themselves, the next review reads them, and so does Read the comments.

When something needs you

  • Resume starts the resolver again on a ticket it left half done.
  • Fix the build starts it on a red build. It reads the failed builds' logs and pushes a fix to the pull request's branch.
  • Read the comments starts a review session on the pull request's new comments.
  • Cancel stops following the ticket until the merge. Its branch, its pull request and its tracker status stay as they are.

Everything waiting for you is listed on Work, the dashboard's home.