2.2 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-08-01T07:19:49-04:00 |
|
Implement skill branch worktree policy grill
Question
What branch and worktree policy should implement follow for normal tickets, parallel Wayfinder task execution, and wide-refactor or integration-branch exceptions?
Resolution
implement should assume the caller, current session, future Pi extension, Treehouse, Herdr, or human operator has already provided the right checkout.
It is worktree-compatible, not a worktree orchestrator.
It verifies and reports the checkout where it is working, but it does not create, lease, clean up, or switch worktrees.
Before starting, implement checks for uncommitted changes.
It stops when changes are unrelated or ambiguous, and continues only when the dirty state is clearly already part of the selected work.
It never auto-stashes.
When starting new work, implement uses or creates a non-default branch from an updated default branch.
If it is already on an appropriate non-default branch prepared for this work, it continues.
If it is on the default branch, it fast-forwards the default branch and creates a task branch.
If the default branch cannot fast-forward cleanly, it stops.
Branch naming follows repository, user, or orchestrator convention.
If no convention is discoverable and implement must create a branch, it chooses a clear short descriptive name and reports it.
Dependency branch handling preserves the old /implement guardrail.
implement checks declared blockers and stops when prerequisite implementation work is not reachable from the current base, reporting which prerequisite appears unmerged.
It does not automatically branch from, merge, or cherry-pick sibling task work.
Explicitly planned integration-branch or wide-refactor exceptions may use the branch strategy stated by the plan.