worktree-retry-cleanup

Cleans stale git worktree lanes and branches before re-dispatching parallel coder tasks.

Updated Sep 14, 2026
One-click install
npx skills add https://github.com/pandejesal/drone-nav-sar --skill worktree-retry-cleanup-pandejesal
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: worktree-retry-cleanup
Source: https://github.com/pandejesal/drone-nav-sar/tree/main/.swarm/bundled-skills/worktree-retry-cleanup
Command: npx skills add https://github.com/pandejesal/drone-nav-sar --skill worktree-retry-cleanup-pandejesal

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Re-dispatching a parallel coder task that already has a worktree lane can fail because of stale worktrees or leftover branches, and blindly deleting them risks destroying work owned by another active session. ## Core Features & Use Cases - Provisioning-first cleanup: Re-dispatches through the standard coder/worktree path so built-in provisioning pre-cleans safe, stale same-lane worktrees and branches automatically. - Ownership verification: Reads .swarm/session/state.json and checks delegationChains to confirm no other active session owns the lane before any manual removal. - Surgical removal: Targets only .swarm-worktrees/<session>/<task> via git worktree remove and git worktree prune, deleting the swarm/lane/<session>/<task> branch only after confirming it is stale, with force deletion requiring explicit human approval. - Use Case: A coder task failed mid-run and must be retried; this protocol verifies lane ownership, removes only the confirmed stale worktree and branch, and verifies the branch list is empty before retrying. ## Quick Start Before re-dispatching the failed coder task, follow the worktree retry cleanup protocol to verify lane ownership and remove only the stale worktree and branch.

Frequently Asked Questions about worktree-retry-cleanup

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I clean up a git worktree before retrying a failed task?

Re-dispatch through the standard provisioning path first, since it pre-cleans safe stale lanes automatically. If manual cleanup is required, run git worktree remove on the specific lane path, then git worktree prune, and verify the lane branch is gone before retrying.

How do I check if a worktree lane is owned by another session?

Read .swarm/session/state.json and verify that no other session's delegationChains reference the <session>/<task> lane. If another active session owns the lane, stop immediately and do not delete anything.

When is it safe to delete a stale worktree branch?

Delete the swarm/lane/<session>/<task> branch with git branch -d only after confirming it is not checked out anywhere and contains no needed commits. Force deletion requires explicit human approval.

Why does worktree provisioning block my task retry?

Provisioning fails closed when a lane is dirty, active in another worktree, or owned by another active session. Treat the error as a signal and surface it to the user rather than deleting the lane.

What are the risks of manually removing git worktrees?

Removing the wrong path can destroy uncommitted work or lanes owned by other active sessions. Always target only the specific .swarm-worktrees/<session>/<task> directory, never the session parent, and verify ownership first.