---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-08-01T07:19:49-04:00"
blocked-by:
  - "[[039-implement-skill-old-workflow-research]]"
  - "[[043-implement-skill-treehouse-research]]"
  - "[[044-implement-skill-herdr-worktree-research]]"
  - "[[045-implement-skill-pi-worktree-extensions-research]]"
  - "[[076-implement-skill-matt-to-tickets-research]]"
tags:
  - ticket/grill
---

# 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.