MCPInstall

using-git-worktrees

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates an isolated git worktree (via the native opencode v2 worktree tools) and moves the session into it

Installs
89
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/osmontero/opencode-skills --skill using-git-worktrees
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads using-git-worktrees automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Using Git Worktrees

Overview

Git worktrees create isolated workspaces sharing the same repository, allowing work on multiple branches simultaneously without switching.

Core principle: In opencode v2, worktrees are created with the native worktree_* tools, and the session moves into the worktree — not just the shell. This keeps opencode's tracking (list/remove), project config, and AGENTS.md discovery pointing at the right place.

Announce at start: "I'm using the using-git-worktrees skill to set up an isolated workspace."

Default Path: Native Worktree Tools

Use this when running inside opencode v2 (the normal case). The tools are worktree_create, worktree_list, worktree_remove (Code Mode namespace opencode), plus session_move.

1. Create the worktree

Call worktree_create with a name — use the feature/branch name (e.g. auth, fix-login-timeout). It returns { directory }.

Where the worktree lands is decided by the worktree.directory setting in the project's opencode config, not by the skill:

  • Not set (default): opencode's data directory, worktree/<project-id prefix>/<name> — outside the repo, so nothing to gitignore.
  • Set (e.g. "worktree": { "directory": ".worktrees" }): relative paths resolve against the project's canonical checkout. If the directory is inside the repo, it must be gitignored (see below).

Do not hand-roll the location with git worktree add — opencode only records and manages worktrees it created itself, so manual ones are invisible to worktree_list / worktree_remove.

If the user wants a non-default location, the v2-idiomatic move is to set worktree.directory in the config (and note it in AGENTS.md or memory) — not to pick a path per session.

2. Create the branch

worktree_create does not take a branch name: the new worktree is at a detached HEAD on the repo's current commit. Create the branch from inside the worktree:

git checkout -b "<branch-name>"

(git checkout main would fail — main is already checked out in the primary worktree; that is expected and not an error.)

3. Move the session into the worktree

Call session_move with the worktree directory as directory. The move takes effect at a safe boundary, so destination-dependent work (reads, edits, setup commands) belongs in the next call.

Why this instead of cd: a shell cd only changes one command's working directory; session_move re-roots the session's Location, so tool calls, config discovery, and instruction files all resolve against the worktree checkout.

4. Project-local location safety (only if inside the repo)

When worktree.directory places worktrees inside the checkout (.worktrees/, worktrees/, …), verify the directory is ignored before creating the worktree:

git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null

If not ignored: add it to .gitignore, commit, then create. This prevents worktree contents from polluting git status or being accidentally committed.

5. Run project setup

The worktree is a fresh checkout — dependencies are not shared with the main worktree. Auto-detect and run setup:

# Node.js
[ -f package.json ] && npm install

# Rust
[ -f Cargo.toml ] && cargo build

# Python
[ -f requirements.txt ] && pip install -r requirements.txt
[ -f pyproject.toml ] && poetry install

# Go
[ -f go.mod ] && go mod download

6. Verify clean baseline and report

Run the project's tests to confirm the worktree starts green:

# project-appropriate: npm test / cargo test / pytest / go test ./...

If tests fail: report the failures and ask whether to proceed or investigate. If they pass: report ready.

Worktree ready at <full-path> (branch <name>)
Session moved. Tests passing (<N> tests, 0 failures)
Ready to implement <feature-name>

Cleanup

Pairs with finishing-a-development-branch after the work is done:

  • worktree_remove with the worktree directory removes a worktree opencode recorded for the project. It uses the edit permission on that directory; set force: true only to discard uncommitted changes.
  • Never remove a worktree with unpushed, unmerged commits without explicit confirmation — that deletes the work.
  • A worktree created manually with raw git (fallback below) is not recorded by opencode; remove it with git worktree remove <path> instead.

Fallback: Raw Git

Use git worktree add directly only when:

  • Running in a harness without the native tools (Claude Code, Codex, plain terminal).
  • The worktree needs a base other than the current HEAD (git worktree add <path> -b <branch> <base-commit>).
  • The user explicitly asks for a manual worktree.

The same safety rules apply: gitignore check for project-local paths, setup, baseline tests, and announce the location.

Quick Reference

SituationAction
In opencode v2worktree_create → git checkout -b → session_move → setup → baseline
Non-default location wantedSet worktree.directory in opencode config
Location inside repogit check-ignore first; add to .gitignore + commit if not
Needs a base other than HEADFallback: git worktree add <path> -b <branch> <base>
Tests fail during baselineReport failures + ask
Work donefinishing-a-development-branch → worktree_remove

Common Mistakes

Assuming worktree_create makes a branch

  • Problem: It leaves a detached HEAD; commits land nowhere a branch points at.
  • Fix: git checkout -b <branch> inside the worktree immediately after creation.

cd-ing into the worktree instead of session_move

  • Problem: Only the shell's CWD changes; the session, config, and instruction discovery still point at the old location.
  • Fix: Call session_move; put dependent work in the next turn.

Hand-rolling git worktree add in opencode

  • Problem: opencode doesn't record manual worktrees, so worktree_list/worktree_remove can't see them, and the location ignores worktree.directory.
  • Fix: Use the native tools in v2; raw git is the fallback above.

Proceeding with failing baseline tests

  • Problem: Can't distinguish new bugs from pre-existing issues.
  • Fix: Report failures, get explicit permission to proceed.

Red Flags

Never:

  • Commit on the detached HEAD (create the branch first)
  • Remove a worktree with unpushed/unmerged work without confirmation
  • Skip baseline test verification
  • Assume the default location when the user has a project-local preference — check/set worktree.directory

Always:

  • Use native tools in opencode v2, raw git only in the fallback cases
  • Move the session with session_move after creation
  • Verify gitignore for in-repo locations
  • Auto-detect and run project setup, then a clean test baseline

Example Workflow

You: I'm using the using-git-worktrees skill to set up an isolated workspace.

[worktree_create name="auth" -> C:\Users\osmon\.local\share\opencode\worktree\c3488b\auth]
[git checkout -b feature/auth]
[session_move directory=<worktree dir>]
[npm install, npm test - 47 passing]

Worktree ready at C:\Users\osmon\.local\share\opencode\worktree\c3488b\auth (branch feature/auth)
Session moved. Tests passing (47 tests, 0 failures)
Ready to implement auth feature

Integration

Called by:

  • subagent-driven-development - REQUIRED before executing any tasks
  • executing-plans - REQUIRED before executing any tasks
  • Any skill needing an isolated workspace

Pairs with:

  • finishing-a-development-branch - REQUIRED for cleanup after work complete

FAQ

What does the using-git-worktrees skill do?

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates an isolated git worktree (via the native opencode v2 worktree tools) and moves the session into it

How do I install using-git-worktrees?

Run npx skills add https://github.com/osmontero/opencode-skills --skill using-git-worktrees in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/using-git-worktrees/ (personal) or .claude/skills/using-git-worktrees/ (project).

Which AI agents can use using-git-worktrees?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is using-git-worktrees safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains using-git-worktrees?

It is published by osmontero in osmontero/opencode-skills. It has 89 recorded installs.

More from osmontero/opencode-skills

View all →

designing-frontend-interfaces

osmontero/opencode-skills

Use when building or restyling any web interface — landing pages, dashboards, marketing sites, web apps, React/Vue components, HTML/CSS layouts, artifacts, posters — or when asked to make a UI look better, more polished, more distinctive, less generic, or less "AI-generated". Also use when a design brief, art direction, visual identity, type scale, or color system is needed before implementation.

Frontend & Design650 installs

designing-user-experience

osmontero/opencode-skills

Open the skill to read its SKILL.md instructions.

460 installs

reviewing-interface-quality

osmontero/opencode-skills

Open the skill to read its SKILL.md instructions.

363 installs

building-accessible-interfaces

osmontero/opencode-skills

Use when building or auditing any web UI for accessibility — keyboard navigation, screen readers, focus management, ARIA, color contrast, form labels and error announcements, reduced motion, or touch target size. Triggers include "is this accessible", "WCAG", "a11y", "screen reader", "keyboard navigation", "focus trap", "contrast ratio", "aria-label", or building modals, menus, tabs, comboboxes, toasts, and custom controls that must work without a mouse.

Frontend & Design350 installs

systematic-debugging

osmontero/opencode-skills

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

verifying-before-completion

osmontero/opencode-skills

Open the skill to read its SKILL.md instructions.

156 installs

Popular code quality & workflow skills

View category →

grill-me

mattpocock/skills

A relentless interview to sharpen a plan or design.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

handoff

mattpocock/skills

Compact the current conversation into a handoff document for another agent to pick up.

domain-modeling

mattpocock/skills

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.

codebase-design

mattpocock/skills

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

diagnosing-bugs

mattpocock/skills

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.