Source profileQuality 94/100Review permissions

event4u-app/agent-config/src/skills/worktree-lifecycle/SKILL.md

worktree-lifecycle

Use when governing a worktree across its whole life — scope-lock declaration, merge-readiness status, scoped verification, and safe cleanup that refuses while unique unmerged commits exist.

Source repository stars
9
Declared platforms
0
Static risk flags
1
Last source update
2026-08-28
Source checked
2026-08-28

Decision brief

What it does: where it fits

Governance layer for worktrees that already exist (or are about to). Creation mechanics — directory convention, ignore-safety, clean baseline — live in using-git-worktrees and are referenced, never restated here. This skill owns everything after the spawn: what the worktree is a…

Best for

  • Deciding whether a task should be isolated in a worktree at all
  • Declaring which paths a worktree owns so parallel agents stay disjoint
  • Answering "is this worktree merge-ready?" — status, dirty state,

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/event4u-app/agent-config --skill "src/skills/worktree-lifecycle"
Safe inspection promptEditorial

Inspect the Agent Skill "worktree-lifecycle" from https://github.com/event4u-app/agent-config/blob/6a5670b7881a676c0da90d2afb950298087c4ccb/src/skills/worktree-lifecycle/SKILL.md at commit 6a5670b7881a676c0da90d2afb950298087c4ccb. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Procedure

    Isolate when any holds; otherwise stay on the current branch (per the Do-NOT list in using-git-worktrees):

    Parallel agents/sessions must not share a working directoryThe current branch is mid-work and a stash/switch would risk stateThe change is exploratory and may be thrown away whole
  2. 02

    When to use

    Deciding whether a task should be isolated in a worktree at all Declaring which paths a worktree owns so parallel agents stay disjoint Answering "is this worktree merge-ready?" — status, dirty state, ahead/behind, verification evidence Running the scoped verification for a workt…

    Deciding whether a task should be isolated in a worktree at allDeclaring which paths a worktree owns so parallel agents stay disjointAnswering "is this worktree merge-ready?" — status, dirty state,
  3. 03

    The Iron Law

    Review the “The Iron Law” section in the pinned source before continuing.

    Review and apply the “The Iron Law” source section.
  4. 04

    1. Decide isolation

    Isolate when any holds; otherwise stay on the current branch (per the Do-NOT list in using-git-worktrees):

    Parallel agents/sessions must not share a working directoryThe current branch is mid-work and a stash/switch would risk stateThe change is exploratory and may be thrown away whole
  5. 05

    2. Scope lock

    At worktree start, write a .worktree-scope.md note at the worktree root and keep it untracked via .git/info/exclude (shared exclude — one line .worktree-scope.md, no commit needed):

    branch:owns:task:

Permission review

Static risk signals and limitations

Runs scripts

medium · line 69

The documentation asks the agent to run terminal commands or scripts.

git diff --name-only "$(git merge-base HEAD <base>)"..HEAD

Runs scripts

medium · line 99

The documentation asks the agent to run terminal commands or scripts.

npx tsx node_modules/@event4u/agent-config/src/scripts/worktree_cleanup_check.ts check <worktree-path>

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score94/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars9SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
event4u-app/agent-config
Skill path
src/skills/worktree-lifecycle/SKILL.md
Commit
6a5670b7881a676c0da90d2afb950298087c4ccb
License
MIT
Collected
2026-08-28
Default branch
main
View the original SKILL.md

worktree-lifecycle

Governance layer for worktrees that already exist (or are about to). Creation mechanics — directory convention, ignore-safety, clean baseline — live in using-git-worktrees and are referenced, never restated here. This skill owns everything after the spawn: what the worktree is allowed to touch, when it is merge-ready, and when it may be removed.

When to use

  • Deciding whether a task should be isolated in a worktree at all
  • Declaring which paths a worktree owns so parallel agents stay disjoint
  • Answering "is this worktree merge-ready?" — status, dirty state, ahead/behind, verification evidence
  • Running the scoped verification for a worktree's declared change
  • Removing a finished worktree without losing commits

Do NOT use when:

  • Creating the worktree — that is using-git-worktrees (Iron Law: no worktree without verified ignore + clean baseline)
  • Plain branch work (switch, rebase, PR) without worktree isolation — git-workflow
  • Picking a subagent-orchestration mode — subagent-orchestration selects the mode; this skill governs the worktrees a chosen mode uses

The Iron Law

EVERY GOVERNED WORKTREE DECLARES ITS SCOPE. NO REMOVAL WHILE
UNIQUE UNMERGED COMMITS EXIST. INHERITED COMMITS ARE NEVER DROPPED.

Procedure

1. Decide isolation

Isolate when any holds; otherwise stay on the current branch (per the Do-NOT list in using-git-worktrees):

  • Parallel agents/sessions must not share a working directory
  • The current branch is mid-work and a stash/switch would risk state
  • The change is exploratory and may be thrown away whole
  • A long-running build/test occupies the current worktree

Then create via using-git-worktrees (or the host primitive — § Host-native mapping below), declare the scope lock (§ 2), keep status honest (§ 3), and gate removal (§ 4).

2. Scope lock

At worktree start, write a .worktree-scope.md note at the worktree root and keep it untracked via .git/info/exclude (shared exclude — one line .worktree-scope.md, no commit needed):

## Scope lock
- branch: <branch-name>
- owns: <path or glob list — the ONLY paths this worktree edits>
- task: <one-line task statement>
- created: <ISO date>

The lock is the disjointness contract between parallel worktrees. A diff that leaves the owned paths is scope creep — stop and surface, per scope-control. Check mechanically:

git diff --name-only "$(git merge-base HEAD <base>)"..HEAD
# every path must match an `owns:` entry

3. Status / merge-ready checklist

A worktree is merge-ready only when ALL hold:

  1. Clean treegit status --porcelain is empty.
  2. Scope lock respected — changed files ⊆ owns: paths (command above).
  3. Verification evidence attached — the scoped probe for the declared change ran fresh and passed (per verify-before-complete); record command + result tail in the status report. No fresh evidence → not merge-ready, regardless of how the diff looks.
  4. Ahead/behind knowngit fetch origin --quiet then git rev-list --left-right --count HEAD...origin/<base>. Behind → flag; divergent (both sides non-zero on a pushed branch) → route to git-workflow § Divergent-State Recovery.
  5. No inherited-commit drops — commits on the branch that this session did not author stay on the branch; never rebase-out, reset-away, or exclude them (rule git-history-discipline, shared-branch Iron Law).

4. Cleanup discipline

Removal is gated by the deterministic helper (edge-case-tested: detached HEAD, branch without remote, tag-only reachability, deleted remote branch, untracked files, paths with spaces):

npx tsx node_modules/@event4u/agent-config/src/scripts/worktree_cleanup_check.ts check <worktree-path>

Exit 0 → removal allowed; exit 1 → refuse, gates in order:

  1. Detached HEAD — no branch to judge reachability for; resolve manually first.
  2. Unsaved workgit status --porcelain non-empty, untracked files included (never answer with --force).
  3. Unique-commit check — commits reachable from the worktree branch but from no other ref (branches, remotes, AND tags — a tag counts as reachability). Non-empty → refuse removal; the branch holds work that exists nowhere else. Surface the commit list and hand back — merging or preserving them is the user's call (git-history-discipline).

Then: remove, never deletegit worktree remove <path>, then git worktree prune. Branch deletion is a separate, permission-gated step (scope-control); never force-delete (-D) as part of cleanup. Cross-worktree scope-lock overlaps are scanned via worktree_cleanup_check scope-overlap (surfaced by /worktree status).

Whole-checkout sweeps. Worktrees accumulate one per branch and are never removed on merge; git worktree prune only clears registrations whose directory is already gone, so it does nothing for the live ones. Classify the whole set in one pass rather than gate-checking by hand:

npx tsx node_modules/@event4u/agent-config/src/scripts/worktree_cleanup_check.ts inventory [repo] [--json|--plan]

safe requires all of: on a branch, merged into the trunk, clean, inside a conventional worktree root (.claude/worktrees/ or .worktrees/), and no git activity for 48 h. review keeps its disqualifying reason so the next sweep starts from a shorter list; live means another session may hold it. A worktree outside the conventional roots is never safe — sitting beside the repo it can be mistaken for a sibling package, so its removal stays a judgement call.

The mode reports only. --plan prints git worktree remove plus git branch -d (never -D) for the safe set; running it is a bulk deletion needing the user's explicit this-turn approval (non-destructive-by-default), which a single earlier approval never covers.

Host-native mapping

Host capabilityUse
Claude Code EnterWorktree / ExitWorktreeEnter/leave a governed worktree in-session; scope lock is written right after enter
Claude Code subagent isolation: "worktree"Dispatch a slice into its own auto-managed worktree; unchanged worktrees are auto-cleaned by the host — the unique-commit gate still applies to any it leaves behind
No worktree primitive (other hosts)Degrade to plain git worktree add per using-git-worktrees § Procedure — same scope lock, same gates

The mapping changes only who creates the directory. Scope lock, merge-ready checklist, and cleanup gates are host-independent.

Gotcha

  • git log <branch> --not --all is always empty--all includes the branch itself, so the naive check never fires. The --exclude="refs/heads/<branch>" --all variant is also unreliable when combined with --not (observed on git 2.39). Use the for-each-ref expansion above — it enumerates every ref except the branch explicitly.
  • Scope note committed by accident.worktree-scope.md must be in .git/info/exclude; .gitignore would be a tracked change outside the scope lock.
  • "Unchanged worktree" ≠ "no unique commits" — a host auto-clean only covers worktrees with no changes; a worktree with committed but unmerged work still needs the unique-commit gate.
  • Stale ahead/behind — always git fetch before the rev-list --left-right count; a cached view reports merge-ready on a diverged branch.

Output format

  1. Worktree — path + branch, and the scope-lock owns: list
  2. State — clean/dirty, ahead/behind vs base, merge-ready verdict with the failing checklist item named when not ready
  3. Evidence — verification command(s) run + result tail, or "none attached" stated explicitly
  4. Next step — merge path, missing verification, or cleanup verdict (allowed / refused with the unique-commit list)

Do NOT

  • NEVER remove a worktree whose branch has commits on no other ref
  • NEVER git worktree remove --force past a dirty tree
  • NEVER drop, rebase-out, or reset-away inherited commits (rule git-history-discipline)
  • NEVER report merge-ready without fresh verification evidence
  • NEVER edit outside the scope-lock owns: paths without surfacing it

Handover

TaskSkill / command
Creating the worktree (ignore-safety, baseline)using-git-worktrees
Divergence recovery, safe squash, PR flowgit-workflow
Finishing the branchfinishing-a-development-branch
Day-to-day operations/worktree create · status · verify · cleanup

Frequently asked questions

What to verify before installation and use

What does the worktree-lifecycle source document cover?

Governance layer for worktrees that already exist (or are about to). Creation mechanics — directory convention, ignore-safety, clean baseline — live in using-git-worktrees and are referenced, never restated here. This skill owns everything after the spawn: what the worktree is a…

How do I install worktree-lifecycle?

The source record exposes this install command: npx skills add https://github.com/event4u-app/agent-config --skill "src/skills/worktree-lifecycle". Inspect the command and pinned source before running it.

Which permission-related actions were detected?

Static rules flagged exec-script in the source; the page lists the matching lines and excerpts.

Alternatives

Compare before choosing

Computed 10045,960

coreyhaines31/marketingskills

ab-testing

When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

Computed 10029,236

garrytan/gbrain

bulk-ingestion

End-to-end discipline for turning any large data source (audio libraries, email takeouts, document corpora, chat exports, API dumps) into brain pages at scale. The lifecycle spine: SCHEMA → ACCESS → TRIAL → EVALUATE → IMPROVE → CODIFY → TEST → SKILLIFY → BULK → MONITOR. State is tracked in a durable JSON manifest (see MANIFEST-PATTERN.md) so any crash, session boundary, or subagent fan-out resumes from ground truth instead of memory.

Computed 10025,136

alirezarezvani/claude-skills

app-store-optimization

App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist

Computed 1005,277

dotnet/skills

migrate-vstest-to-mtp

Migrates .NET test projects from VSTest to Microsoft.Testing.Platform (MTP). Use when user asks to "migrate to MTP", "switch from VSTest", "enable Microsoft.Testing.Platform", "use MTP runner", set OutputType=Exe only for test projects in Directory.Build.props, or mentions EnableMSTestRunner, EnableNUnitRunner, or UseMicrosoftTestingPlatformRunner. USE FOR: MTP behavioral differences vs VSTest (exit code 8, zero tests discovered, --ignore-exit-code, TESTINGPLATFORM_EXITCODE_IGNORE); centralizing