agentsclimarketplace

Using git worktrees

Skill heymegabyte/claude-skills/20-superpowers/using-git-worktrees

14-category autonomous product-building OS for 32+ AI coding tools. One-line prompts → deployed products.

Install
npx -y skills add heymegabyte/claude-skills --skill using-git-worktrees

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 18 stars18 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

SKILL.md

3.0 KB, as published. Nobody here has run it

Using Git Worktrees

Ensure work runs in an isolated workspace. Detect existing isolation first, then prefer the harness's native worktree tool, then fall back to git worktree. Never fight the harness.

Pairs with [[main-only-branch]] — main always committed, worktrees for isolation. The harness ships native worktree tools (EnterWorktree/ExitWorktree); use them over raw git.

Announce: "Using the using-git-worktrees skill to set up an isolated workspace."

Step 0 — detect existing isolation

GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
BRANCH=$(git branch --show-current)
  • GIT_DIR != GIT_COMMON is ALSO true in a submodule. Guard: git rev-parse --show-superproject-working-tree returns a path → you're in a submodule, treat as a normal repo.
  • GIT_DIR != GIT_COMMON (not submodule) → already in a linked worktree. Skip to Step 2; do NOT nest another. Report the path + branch (note if detached HEAD — branch creation deferred to finish time).
  • GIT_DIR == GIT_COMMON → normal checkout. If no worktree preference is declared in instructions, ask consent before creating one; honor a declared preference silently; if declined, work in place → Step 2.

Step 1 — create the workspace

  1. Native EnterWorktree tool (the default) — call it first, always. It owns placement, branch, and cleanup; passing name creates, passing path switches into an existing one. On exit, ExitWorktree with action: "remove" or "keep". Never mix with raw git worktree add — that creates phantom state the native tool can't see.
  2. Git fallback (only if no native tool):
    • Directory priority: declared instruction preference > existing .worktrees/ (wins over worktrees/) > default .worktrees/.
    • Verify ignored before creating: git check-ignore -q .worktrees. If not ignored, add to .gitignore + commit first — else worktree contents get tracked.
    • git worktree add "$LOCATION/$BRANCH_NAME" -b "$BRANCH_NAME" && cd "$_".
    • Permission/sandbox denial on add → tell the user, work in place, run setup + baseline there.

Step 2 — setup + baseline

  • Auto-detect and install: package.json→npm install, Cargo.toml→cargo build, requirements.txt→pip install -r, pyproject.toml→poetry install, go.mod→go mod download.
  • Run the project test suite to confirm a clean baseline. Tests fail → report + ask before proceeding (can't tell new bugs from pre-existing). Tests pass → report ready: path, test count, feature.

See

  • [[main-only-branch]] — worktrees for isolation, main always committed
  • finishing-a-development-branch — merge/PR/cleanup when work is done
<!-- budget: ~43 -->

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.