domains / families / software-engineering / using-git-worktrees

using-git-worktrees

combined

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification 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

When to use

• This skill is applicable to execute the workflow or actions described in the overview.

When not to use

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Skill page

Conflict

The copies overlap heavily on directory selection, gitignore safety, project setup, and baseline tests, but they disagree on the core workflow. obra/superpowers adds a Step 0 that detects whether the agent is already in a worktree or a submodule, asks for consent, and prefers native harness worktree tools before falling back to git. The other three copies omit that detection/consent/native-tool layer and instead present a direct git-worktree procedure with a global ~/.config/superpowers/worktrees option. Crowning one copy would hide a real alternative: the obra version is a harness-aware isolation procedure, while the others are a simpler manual git-worktree setup.