3.9 KiB
status, parent, claimed-by, claimed-at, blocked-by, tags
| status | parent | claimed-by | claimed-at | blocked-by | tags | |
|---|---|---|---|---|---|---|
| resolved | 038-implement-skill-map | 019fbb66-80d0-7a01-8ac9-01255adfc7b2 | 2026-07-31T23:46:29-04:00 |
|
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.