---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:46:29-04:00"
blocked-by: []
tags:
  - ticket/research
---

# Implement skill treehouse research

## Question

What should the migrated `implement` skill learn from Kun Chen's `treehouse` workflow about using git worktrees for implementation sessions?

## Findings

Kun Chen's `treehouse` manages a pool of reusable isolated git worktrees per repository under a configured root, defaulting to `~/.treehouse/`.
It is designed so each agent gets its own environment instantly without cloning, conflicts, or coordination overhead, while preserving dependencies and build cache between sessions.
The migrated `implement` skill should consider worktree isolation as a stronger default than mutating the user's current checkout when the tool is available.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.

Treehouse worktrees use detached HEAD reset to the local or remote default branch that is further ahead, avoiding branch-name conflicts at acquisition time.
An implementation skill that expects to create a named branch may need to create the task branch after entering or leasing the worktree, rather than relying on the worktree manager to allocate the feature branch.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.

Treehouse marks worktrees as in-use through process scans and short-lived owner reservations, and has durable leases for automation with `treehouse get --lease`.
A leased worktree is never handed out later and never pruned until released with `treehouse return`.
For a non-interactive `implement` workflow, `treehouse get --lease --lease-holder <session> --json` is more appropriate than opening a subshell.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.

Treehouse leases include a random `lease_id`, `lease_holder`, and `leased_at`, and `treehouse return` can require `--if-lease-id` and `--if-lease-holder`.
This gives automation ABA protection so cleanup cannot accidentally release a later acquisition of the same path.
A migrated skill should record the lease path and identity in the Wayfinder task artifact if it uses Treehouse, and release with identity checks during cleanup.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.

Treehouse treats tracked changes and untracked files as dirty, even when repository config hides untracked files from normal `git status` output.
Its prune and destroy commands are dry-run or safe by default and skip dirty, unmerged, unverifiable, in-use, and leased worktrees unless explicit destructive flags are provided.
The migrated `implement` skill should preserve this safety stance and should not destroy or return a dirty leased worktree without surfacing the risk.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.

Treehouse supports user-level lifecycle hooks, including `post_create`, and routes hook stdout to stderr when using `get --lease` so stdout remains machine-readable.
This makes it suitable for dependency installation, environment setup, and cache reuse outside the `implement` skill itself.
The migrated skill should avoid duplicating environment bootstrap when a worktree manager's hooks own it.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.

## Conclusion

If worktree automation is in scope, the migrated `implement` skill should prefer optional Treehouse leasing over ad hoc `git worktree` management: acquire an isolated reusable worktree, create or check out the task branch inside it, record lease identity in the ticket, avoid destructive cleanup when dirty, and release with `--if-lease-id` after successful handoff.
This should remain optional unless the user decides every implementation must run outside the current checkout.