Claude Skill

worktree-per-agent

Isolate an agent's work in its own git worktree branched off the default branch, so two agents never land conflicting changes on the shared checkout. Use at the start of any implementation task in a repo where others may also be working, and whenever a repo's instructions say "wo

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download jakeselby-agent-harness-primitives_skills_worktree-per-agent-0c8664f.zip · 1 KB
Part of jakeselby/agent-harness — 14 skills

Install

skills CLI npx skills add https://github.com/JakeSelby/agent-harness/tree/main/primitives/skills/worktree-per-agent
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install jakeselby-agent-harness@llmmart
Git git clone https://github.com/JakeSelby/agent-harness.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole jakeselby/agent-harness collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

One worktree per agent

The shared checkout belongs to the human. An agent that edits it directly races every other agent and every uncommitted human change. So: branch a worktree off the default branch, work there, land the result through the repo's normal path, remove the worktree.

Create

REPO=$(git rev-parse --show-toplevel)
NAME=<task-slug>
DEST=$(harness worktree create "$NAME" "$REPO")
cd "$DEST"

The dedicated root keeps temporary task checkouts separate from permanent clones. It defaults to ~/worktrees/<repo>/<task>; HARNESS_WORKTREE_ROOT may replace ~/worktrees. The helper fetches origin and branches from origin/main, so it starts from what is actually merged. If the repo's instructions name a different base, pass --base; if they name a different location, follow them. Never create a task worktree as a sibling under the directory holding permanent repositories.

Work

  • Install dependencies in the worktree if the repo needs them per checkout; do not assume the shared checkout's node_modules or virtualenv is reachable.
  • Run the repo's quality gate in the worktree before pushing, per verification.md.
  • Never cd back into the shared checkout to run something "quickly".

Land

Push the branch and open a PR, or push to main if the repo's instructions allow it. Then:

harness worktree remove "$NAME" "$REPO" --merged

--merged deletes the local branch as well, and only once gh reports a merged pull request whose head commit is the branch tip. A repository that squash-merges leaves the branch's own commits out of the default branch, so git branch -d refuses work that did land; that proof is the check instead. Drop --merged to keep the branch. Removal does not count regenerable caches such as __pycache__ that a gate run wrote, and still refuses any other modified, untracked or ignored entry; --also-clear <name> adds a regenerable top-level directory the built-in list misses.

Things that bite

  • Tooling that resolves paths against the working directory (planning frameworks, skill projections) will not find its files in a worktree. If a tool halts with a missing-script error, that is the guard working; run that tool from the shared checkout only.
  • Shared append-only documents (a decisions log, a changelog) are not worktree material: two agents appending in two worktrees produce a conflict at merge. Append to those on the default branch in one place.
  • Generated index files are rebuilt once at merge, never on both sides.
  • Leftover worktrees confuse git status and history rewrites. git worktree list before any operation that touches every branch. harness worktree audit "$REPO" reports dirty and stale checkouts; a clean checkout can still contain unpublished commits, so audit branch history before removal.
Files (agent-harness)
  • SKILL.md 3.1 KB
    ---
    name: worktree-per-agent
    description: Isolate an agent's work in its own git worktree branched off the default branch, so two agents never land conflicting changes on the shared checkout. Use at the start of any implementation task in a repo where others may also be working, and whenever a repo's instructions say "work in a worktree".
    ---
    
    # One worktree per agent
    
    The shared checkout belongs to the human. An agent that edits it directly races every other
    agent and every uncommitted human change. So: branch a worktree off the default branch, work
    there, land the result through the repo's normal path, remove the worktree.
    
    ## Create
    
    ```bash
    REPO=$(git rev-parse --show-toplevel)
    NAME=<task-slug>
    DEST=$(harness worktree create "$NAME" "$REPO")
    cd "$DEST"
    ```
    
    The dedicated root keeps temporary task checkouts separate from permanent clones. It defaults to
    `~/worktrees/<repo>/<task>`; `HARNESS_WORKTREE_ROOT` may replace `~/worktrees`. The helper fetches
    `origin` and branches from `origin/main`, so it starts from what is actually merged. If the repo's
    instructions name a different base, pass `--base`; if they name a different location, follow them.
    Never create a task worktree as a sibling under the directory holding permanent repositories.
    
    ## Work
    
    - Install dependencies in the worktree if the repo needs them per checkout; do not assume the
      shared checkout's `node_modules` or virtualenv is reachable.
    - Run the repo's quality gate in the worktree before pushing, per `verification.md`.
    - Never `cd` back into the shared checkout to run something "quickly".
    
    ## Land
    
    Push the branch and open a PR, or push to `main` if the repo's instructions allow it. Then:
    
    ```bash
    harness worktree remove "$NAME" "$REPO" --merged
    ```
    
    `--merged` deletes the local branch as well, and only once `gh` reports a merged pull request
    whose head commit is the branch tip. A repository that squash-merges leaves the branch's own
    commits out of the default branch, so `git branch -d` refuses work that did land; that proof is
    the check instead. Drop `--merged` to keep the branch. Removal does not count regenerable caches
    such as `__pycache__` that a gate run wrote, and still refuses any other modified, untracked or
    ignored entry; `--also-clear <name>` adds a regenerable top-level directory the built-in list
    misses.
    
    ## Things that bite
    
    - **Tooling that resolves paths against the working directory** (planning frameworks, skill
      projections) will not find its files in a worktree. If a tool halts with a missing-script
      error, that is the guard working; run that tool from the shared checkout only.
    - **Shared append-only documents** (a decisions log, a changelog) are not worktree material:
      two agents appending in two worktrees produce a conflict at merge. Append to those on the
      default branch in one place.
    - **Generated index files** are rebuilt once at merge, never on both sides.
    - **Leftover worktrees** confuse `git status` and history rewrites. `git worktree list` before
      any operation that touches every branch. `harness worktree audit "$REPO"` reports dirty and
      stale checkouts; a clean checkout can still contain unpublished commits, so audit branch history
      before removal.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related