using-git-worktrees

Installation
SKILL.md

Using git worktrees

A worktree gives a task its own checkout while sharing the repository's history. This companion establishes that checkout and returns its verified location to the calling workflow; it does not implement or ship the task.

Zero attribution: never add or leave co-author, AI, or tool attribution in any output.

Inputs

  • Identify the target repository and requested task. In a workspace, use the Project Matrix to resolve the project; an ambiguous repository blocks creation, not independent inspection.
  • Use <project-repo>/.worktrees/<task-name> for placement. Honor the user's branch and base revision when supplied. Otherwise follow applicable project conventions; default a new task branch to the current checkout's recorded HEAD, and state that assumption. If the task requires an unavailable base, resolve it before creating anything.
  • The request to work in a worktree already authorizes setup. Do not ask for the same permission again. A request for only a new branch stays a branch operation; ambiguous isolation wording needs its form resolved before this skill runs.

Rules

  • Preserve existing work. Inspect staged, unstaged, and untracked changes in both the source and any reused checkout. Leave unrelated changes in place. Uncommitted source changes do not appear in a new worktree; if the task needs them, resolve a scoped transfer with the user before proceeding. Never stash, reset, overwrite, or copy the whole checkout as a shortcut.
  • Keep isolation binding. A permission error, occupied branch, or failed setup is a blocked worktree step. Report it and pause dependent edits; never fall back to writing in the original checkout without the user's explicit change of scope.
  • Keep shipping separate. Setup never stages or commits, even to record an ignore rule. It does not merge, push, delete branches, or remove worktrees. Leave the worktree available to the caller; later shipping and cleanup follow their own authorized workflow. For user-requested cleanup, verify integration and preserve needed tracked, untracked, and ignored files first; a push or issue closure alone is not integration proof. Cleanup is outside this setup skill.
  • Keep context attached. Capture applicable workspace and project instructions before switching. A worktree may live outside their filesystem scope; pass those instructions and the verified checkout to any already-authorized local worker. Creating a worktree does not authorize delegation.
Installs
4
GitHub Stars
3
First Seen
10 days ago
using-git-worktrees — devarfeen/agent-skills-kit