bambu-worktree

並行作業用の分離された Worktree

.worktrees/<feature>/ に独自のブランチを持つ新しい git worktree を作成します。これにより、同じ作業ディレクトリで何度も stash／checkout を繰り返すことなく、ユーザーが複数の要件を互いに干渉させずに並行して進められます。プロジェクトに依存しません。デフォルトのブランチ名、パッケージマネージャー、ブランチの命名規則を前提とせず、検出するかユーザーに確認します。

このスキルを使うタイミング

• 「X 用の worktree を作成して。」
• 「今進めている作業に触れずに、Y を並行して進めたい。」
• 「この機能を専用のフォルダーに分離して。」
• 「ほかの作業を続けながら Z を修正できるよう、別のチェックアウトを用意して。」
• 「ログイン機能用の新しい worktree」「このバグ修正用に並行チェックアウトを設定して」
• ユーザーが使いたいブランチ名をすでに指定しており、worktree の準備だけを求めている。

ユーザーが分離を求めていない場合、同じチェックアウト内で通常のブランチ操作（git checkout -b ...）を行うためには使わないでください。これは、複数の作業を同時に進めても互いに干渉しないようにするためのものです。

ワークフロー

ステップ 0 — 前提条件

git rev-parse --is-inside-work-tree   # estás dentro de un repo git
git worktree list --porcelain | head -5

ユーザーのメッセージに引数も要件の説明もない場合は、続行せず、先に短い説明（または使用したいブランチ名）を尋ねてください。フォルダー名とブランチ名を決めるために必要です。

ステップ 1 — メインリポジトリのルートを特定する

すべての worktree は、別の worktree の中ではなく、メインリポジトリ（git worktree list が最初に表示する worktree）のルートにある .worktrees/ の下に配置します。すでに既存の worktree 内にいる場合は、次のコマンドで実際のルートを解決します。

git worktree list --porcelain | sed -n '1,/^$/p'   # el primer bloque es siempre el worktree principal

現在のディレクトリではなく、そのルートを基準に .worktrees/ を操作します。

ステップ 2 — 機能名を決める

ユーザーの説明から、シンプルな kebab-case のスラッグを作成します。小文字を使い、アクセント記号は付けず、単語をハイフンで区切ります。コミット種別のプレフィックス（feat/、fix/ など）や明示的なスコープは付けず、要件を一意に識別でき、読みやすい 3～6 語だけを使います。

• 「チケット窓口に PIN ログインを追加」→ agregar-login-pin-taquilla
• 「旅行タイプ別の割引計算を修正」→ fix-calculo-descuento-tipo-viaje
• 「販売員別の Excel 売上レポート」→ reporte-ventas-vendedor-excel

ユーザーが使いたいフォルダー名／ブランチ名を明示している場合は、解釈し直さず、そのまま使用します（スペースや大文字が含まれている場合に限り、kebab-case に正規化します）。

ステップ 3 — ベースブランチを検出する

ユーザーがベースブランチを明示している場合は、それを使います。明示されていない場合は、リポジトリの実際のデフォルトブランチを検出します。決してハードコードしないでください（develop、main、master を前提にしないでください）。

git branch --show-current
gh repo view --json defaultBranchRef --jq .defaultBranchRef.name 2>/dev/null \
  || git remote show origin 2>/dev/null | sed -n '/HEAD branch/s/.*: //p'

1. 現在のブランチが検出したデフォルトブランチと一致する場合は、確認せずにそれをベースとして使います。新しい機能を始める際の通常の流れです。
2. 現在のブランチが別のブランチの場合（すでに機能ブランチ上にいる場合や、別の worktree 内にいる場合）は、新しい worktree のベースをそのブランチにするか、デフォルトブランチにするかをユーザーに確認してください。推測しないでください。

worktree を作成する前に git fetch origin <rama-base> を実行し、新しいブランチが古いローカルコピーではなく、最新の先端から始まるようにします。

ステップ 4 — 実行前の確認

• .worktrees/<feature> がすでに存在しないことを確認します（ls .worktrees/ または git worktree list）。存在する場合はユーザーに知らせ、別の名前にするか、その worktree を再利用して入るかを尋ねます。
• 同じ名前のローカルブランチまたはリモートブランチがすでに存在しないことを確認します（git branch --list <feature> ／ git ls-remote --heads origin <feature>）。存在する場合はユーザーに知らせ、続行前に確認を取ります。自分のブランチではない可能性や、新しく作成するより再開したほうがよい古いブランチである可能性があります。

ステップ 5 — .worktrees/ が無視されていることを確認する

このフォルダーはローカルに並行して作成するチェックアウトのセットです。リモートにプッシュしてはいけません。worktree を作成する前に、対象リポジトリの .gitignore を確認します。

grep -qxF '.worktrees/' .gitignore 2>/dev/null

記載されていない場合は、リポジトリの .gitignore に .worktrees/ の行を追加します（このスキル用リポジトリの .gitignore ではありません）。最終報告でその旨を明示してください。バージョン管理対象ファイルへの変更なので、書き込む前に確認したい場合は、ユーザーに伝えてください。

ステップ 6 — worktree を作成する

git worktree add -b <feature> .worktrees/<feature> origin/<rama-base>

作成されたブランチが明確になるよう、-b <feature> を明示的に指定します（git worktree add にパスからブランチ名を推測させないでください）。ローカルに origin/<rama-base> がまだ存在しない場合は、ステップ 3 の fetch の後に <rama-base> のみを指定します。

ステップ 7 — 最終報告

ユーザーに以下を伝えます。

• 作成した worktree のパス（メインリポジトリのルートからの相対パスである .worktrees/<feature>）。
• 新しいブランチ名と、そのブランチの派生元となるベースブランチ。
• .worktrees/ を .gitignore に追加した場合は、その旨を明示します。
• 明らかな次の手順として、そこで作業するために cd .worktrees/<feature> を実行するか、EnterWorktree のフローまたは新しい Claude Code セッションを使う場合は、そのフォルダーを別プロジェクトとして開くことを提案します。

重要なルール

1. デフォルトのベースブランチ（develop／main／master）を決めつけないでください。gh repo view または git remote show origin で検出するか、曖昧な場合は確認してください。
2. 作成前に、フォルダー名とブランチ名（ローカルおよびリモート）の衝突を必ず確認してください。ユーザーに確認せず、上書きしたり既存のものを再利用したりしないでください。
3. フォルダーはメインリポジトリのルートにある .worktrees/（先頭にドットが付く隠しフォルダー）です。対象リポジトリの .gitignore に記載されている必要があります。記載がなければ追加し、その旨を伝えてください。
4. git worktree add では、常に -b <feature> を明示的に指定してください。パスだけからブランチ名を推測させないでください。
5. ユーザーがブランチ名／フォルダー名を明示している場合は、スラッグを勝手に作らないでください。形式のみを整えて、その名前を尊重してください。