Skip to main content

Implement an issue in a worktree

Use this when another task or your own work may touch the main checkout.

Start with an isolated task

Select the project, open the menu, and choose In a new worktree… for your agent. Name the branch and session after the issue.

Give the agent the issue, relevant constraints, and a verifiable finish line:

Implement issue #[number]. Read the issue and existing code before choosing an
approach. Keep the change within [area]. Add tests for the new behavior and run
the affected checks. Don't broaden the public API. Finish with the decisions you
made, changed files, and checks run.

If the issue isn't available to the agent, paste its acceptance criteria into the task. A number without accessible context isn't a specification.

Leave the worktree alone

Let the session remain Working. Continue your own work in the main checkout or start another independent worktree. Don't edit the agent's checkout while it is active unless you are deliberately taking over.

If it Needs you, answer from the attention card when the choice is clear. Open the session when the question needs code or output context.

Review the result

When the session is Ready for review, open its Git changes and check the diff against the issue rather than the agent's summary. Confirm that:

  1. The behavior matches the acceptance criteria.
  2. The change stayed within the stated boundary.
  3. Tests cover the failure or new behavior.
  4. The reported checks passed in the worktree.

Send follow-up instructions in the same session if something is missing. The agent retains the task and checkout context.

Close cleanly

Commit the finished change through your normal workflow. Close the session only when it no longer holds useful output, then use Manage worktrees when the checkout is clean and no live session uses it. Removing the worktree doesn't remove its branch.

For several issues at once, apply the boundaries in Run parallel agents well.