using-git-worktrees
作業ごとに独立した作業場を用意させる。すでに隔離されているかを先に確かめる作り
npx skills add obra/superpowers/using-git-worktrees入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 223,088
- 実用度
- 68
- GitHub star
- 313,505
- 最終更新
- 2026/11/4
頼み方の例
そのままコピーして使えますusing-git-worktreesを使って、検索機能の追加用に独立した作業場を用意してください。すでに隔離されているならそのまま使ってください。作業場を作る前に、いまどこにいるかを報告してください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- シェルコマンドを実行する記述があります
- パッケージを導入する記述があります
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
コードブロックの言語: bash
いつ使うか
エージェントに作業させるとき、いま開いている作業ツリーを汚したくないときです。
git worktree とは
git worktree は、同じリポジトリからもう 1 つ作業ディレクトリを生やす仕組みです。ブランチを切り替えるのではなく、別のディレクトリに別のブランチを同時に置けます。
エージェントと組み合わせると効く理由
エージェントとの組み合わせで効く理由は具体的です。
- 手元の未コミットの変更を巻き込まない
- 作業中に別の用事が入っても、切り替えずに済む
- 複数の作業を並行させられる
- 失敗したらディレクトリごと捨てられる
最後の 1 つが一番大きいです。エージェントに実装を任せると、途中で方針が変わったり、そもそも筋が悪かったと分かったりします。作業場が独立していれば、捨てる判断が軽くなります。
何も作る前に、すでに隔離されているかを確かめる
このスキルの良いところは、何も作る前に、すでに隔離されているかを確かめることです。
GIT_DIR=$(cd "$(git rev-parse --git-dir)" && pwd -P)
GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" && pwd -P)
この 2 つが違えば、いま既に worktree の中にいます。その場合は新しく作らず、そのまま使います。
本文の言葉では「harness と戦うな」。実行環境が既に隔離を用意しているなら、その上に重ねない、という方針です。エージェント用のスキルとしては、ここが一番よく考えられているところです。
submodule の除外まで入っている
さらに submodule の除外まで入っています。GIT_DIR != GIT_COMMON は git submodule の中でも成立するので、worktree だと誤認しないよう確認を挟みます。
git rev-parse --show-superproject-working-tree
これがパスを返したら submodule の中なので、通常のリポジトリとして扱う。踏んでから直したとしか思えない丁寧さで、こういう記述があるスキルは信用できます。
優先順位
優先順位も明示されています。
- 検出するすでに隔離されているかを検出する
- 専用の仕組みを使う実行環境に専用の仕組みがあればそれを使う
- 手で作る無ければ手で
git worktreeを作る
報告のしかたまで決まっている
報告のしかたまで決まっています。ブランチ上なら「<path> の隔離された作業場にいます（ブランチ <name>）」、detached HEAD なら「外部管理のため、仕上げの時点でブランチ作成が必要」。どこで作業しているか分からなくなる事故を防ぐ作りです。
使わないほうがいいとき
依存パッケージが重い構成
依存パッケージが重い構成では、代償が大きいです。
worktree ごとに node_modules を入れ直すことになります。数分かかる構成なら、ブランチを切り替えるほうが速い場面もあります。
1 行直すだけの作業
1 行直すだけの作業には要りません。手数だけが増えます。
実行環境が独自の隔離を持っている
実行環境が独自の隔離を持っているなら、そちらに任せてください。このスキルもそう指示していますが、無理に git worktree を使う理由はありません。
git を使っていない
git を使っていないなら対象外です。
注意点
解析で見つかった記述
SKILL.md の解析では、シェルコマンドの実行とパッケージの導入の記述が見つかっています。同梱ファイルはなく、コードブロックの言語は bash です。
git の操作を任せることになる
git の操作を任せることになります。
worktree の作成はリポジトリの構造に触る操作です。壊れる種類の操作ではありませんが、作業場が増えたことを忘れると、どこで何をしたか分からなくなります。git worktree list で定期的に確認してください。
作る前に同意を取り、.gitignore を書き換えることがある
通常のリポジトリにいるときは、指示に好みが書かれていなければ、作る前に「隔離した worktree を用意しますか」と聞く決まりです。断られたらその場で作業します。
手で作る場合、作業場のフォルダが git の対象外になっているかを git check-ignore で確かめます。対象外でなければ .gitignore に足してコミットしてから進む、と書かれています。リポジトリに 1 件コミットが増えるので、知らずに走らせると驚くところです。
作ったあとに依存を入れ、試験を流す
作業場ができると、package.json があれば npm install、Cargo.toml なら cargo build、requirements.txt なら pip install、pyproject.toml なら poetry install、go.mod なら go mod download を走らせます。そのあと試験を流し、落ちたら報告して、進めるか調べるかを聞きます。
作業場の掃除は自分でやる
同じ公開元の finishing-a-development-branch を使えば、ローカルでマージしたときと破棄したときに、.worktrees/ か worktrees/ の下のものに限って片付けます。
「開始時に宣言する」指定がある
「開始時に宣言する」指定があります。「using-git-worktrees スキルを使って独立した作業場を用意します」と最初に言うよう書かれています。どのスキルが動いているかが分かるので、複数のスキルを入れているときの切り分けに役立ちます。
同じ公開元のスキルとの並び
このスキルは brainstorming や test-driven-development と同じ公開元（obra/superpowers）です。実装計画を実行する前段として位置づけられていて、セットで使う想定の並びになっています。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
よくある質問
worktree とブランチの切り替えはどう違いますか
同時に存在できるかどうかが違います。ブランチの切り替えは 1 つの作業ディレクトリの中身を入れ替えるので、未コミットの変更があると邪魔になります。worktree は別のディレクトリなので、両方を同時に開いておけます。
エージェントに任せる場面では後者が効きます。作業中のものを見ながら、別のものを進められます。
作った worktree はどこにできますか
実行環境に専用の仕組みがあれば、その仕組みが決めます。手で作る場合の順位は本文に決まっていて、指示にある場所、既にある .worktrees/（無ければ worktrees/）、どちらも無ければプロジェクト直下の .worktrees/ です。どこに作ったかを報告させてください。依頼文に「作業場のパスを教えて」と入れるのが確実です。
失敗した作業場を捨てる手順は
git worktree remove <path>
ブランチも要らなければ git branch -D <name> で消します。強制削除なので、消す前に中身を確認してください。未コミットの変更があると remove は拒否されます（--force で越えられますが、そこは自分で判断してください）。
衝突が起きたときはどうしますか
worktree は衝突を防ぐ仕組みではありません。最後に統合するときの衝突は普通に起きます。同じ公開元ではありませんが、resolving-merge-conflicts がその工程を扱っていました。ただし公開元の説明では v1.3.0 で取り下げられ、いまは保守されていません（2026-10-09 確認）。