52 lines
3.9 KiB
Markdown
52 lines
3.9 KiB
Markdown
---
|
|
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.
|