From 454a3d16a3e3835599aebbce8cd25d1bbff0269d Mon Sep 17 00:00:00 2001 From: Hiroki SAKABE Date: Sun, 2 Aug 2026 00:41:26 +0900 Subject: [PATCH 1/7] feat: enforce runtime worktree isolation --- skills/issue-implement/SKILL.md | 60 ++++++++++++++++++++++----------- skills/worktree-start/SKILL.md | 56 +++++++++++++++++++----------- 2 files changed, 76 insertions(+), 40 deletions(-) diff --git a/skills/issue-implement/SKILL.md b/skills/issue-implement/SKILL.md index 4e002c9..4663592 100644 --- a/skills/issue-implement/SKILL.md +++ b/skills/issue-implement/SKILL.md @@ -1,7 +1,7 @@ --- name: issue-implement -description: 特定の GitHub issue への実装着手と PR 作成を依頼されたときに使う。issue 番号・URL・会話内で選んだ issue のいずれかを起点に、実装・commit・lint・受け入れ条件チェック・cross-review・PR 作成・CI 確認まで一気通貫で自動進行する。コードを書いてプルリクを出す作業全般が対象で、issue 選定相談・タイトル編集・クローズ操作・PR レビュー単体には使わない。 -version: 1.0.5 +description: 特定の GitHub issue への実装着手と PR 作成を依頼されたときに使う。issue 番号・URL・会話内で選んだ issue のいずれかを起点に、runtime と worktree の実装隔離を preflight で保証してから、実装・commit・lint・受け入れ条件チェック・cross-review・PR 作成・CI 確認まで一気通貫で自動進行する。コードを書いてプルリクを出す作業全般が対象で、issue 選定相談・タイトル編集・クローズ操作・PR レビュー単体には使わない。 +version: 1.1.0 --- # Issue Implement Skill @@ -14,15 +14,16 @@ GitHub issue を起点とした issue-driven 開発サイクルの中核 skill - **`issuekit:cross-review` skill**: 実装・commit 後、PR 作成前に、実装セッションから独立した reviewer session による second opinion を得る。APM plain-skill mode では `cross-review` として呼び出す。実装前に runtime と対応 CLI を事前確認し、未対応 runtime や CLI 未導入の場合は明確に失敗させる（該当 skill 側の失敗時対応に従う）。 - **`issuekit:acceptance-check` skill**: 実装・commit 後、cross-review より前に受け入れ条件の自動検査を実施する。APM plain-skill mode では `acceptance-check` として呼び出す。 -- **`issuekit:worktree-start` skill**: Claude Code 環境かつ default branch 上で起動された場合に、実装直前で worktree への自動切り替えに使用する (条件付き、後述 step 4)。APM plain-skill mode では `worktree-start` として呼び出す。Claude Code 以外の runtime ではこの step は skip される。 +- **`issuekit:worktree-start` skill**: Claude Code の対話 session が default branch 上にいる場合に、実装直前で `EnterWorktree` による専用 worktree への切り替えに使用する (後述 step 4)。APM plain-skill mode では `worktree-start` として呼び出す。他 runtime では呼ばず、runtime 別の安全な再開手順を案内して停止する。 - **`gh` CLI**: GitHub 操作全般に使用する。 ## スコープ -- **含む**: Status 確認、Depends on の close 確認、親 issue の文脈取り込み、worktree への自動切り替え (Claude Code 環境かつ default branch 上のときのみ、条件付き)、実装と適宜 commit、lint/format/型チェック、受け入れ条件チェック、cross-review、PR 作成、CI 確認・修正。 +- **含む**: Status 確認、Depends on の close 確認、親 issue の文脈取り込み、runtime / branch / worktree の実装隔離 preflight、Claude Code で可能な場合の worktree 切り替え、実装と適宜 commit、lint/format/型チェック、受け入れ条件チェック、cross-review、PR 作成、CI 確認・修正。 - **含まない**: - default branch 名を hardcode した branch ガード。default branch 名はリポジトリにより異なる (main / master / develop / trunk 等) ため、`gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` で動的に解決した値と現在ブランチを比較する。 - - 非 Claude Code 環境向けの worktree 化フォールバック。Codex CLI では `EnterWorktree` が無いためこの step を skip し、ユーザーが事前に切った worktree / branch で続行する。Cursor / Gemini など `cross-review` 未対応 runtime は、実装前の preflight で停止する。 + - Codex App の managed worktree / Handoff の作成・操作。これらは App が所有する機能であり、skill は App 管理 worktree を作成したふりをしない。 + - Codex CLI の起動済み session を別 cwd へ安全に移せるという仮定。default branch 上では停止し、通常の `git worktree add` と `codex -C ` で新しい session を開始する手順を返す。 - ユーザーが既に手動で feature ブランチに切り替えているケースの上書き。default branch 以外にいる場合は worktree 化を行わず既存ブランチを尊重する。 - レビュー指摘の修正を `git commit --amend` / `rebase` / `fixup` で履歴整形すること。指摘対応は **追加 commit** で行い、試行錯誤やレビュー対応の経緯を履歴に残す。 @@ -73,26 +74,43 @@ REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner') gh api "repos/${REPO}/issues/${ISSUE_NUMBER}/parent" --jq '{number, title, state}' || true ``` -### 4. worktree への自動切り替え (条件付き) +### 4. 実装隔離 preflight (必須) -実装サイクルの冒頭で、default branch 上のまま実装を始めて main / master を直接汚す事故を機械的に防ぐためのステップ。以下の AND 条件 4 つを **すべて** 満たす場合のみ、`issuekit:worktree-start` skill (APM plain-skill mode では `worktree-start`) を呼び出して新規 worktree に切り替える。 +実装・ファイル書き込み・commit の **前** に runtime、現在 branch、worktree 状態、並列 worker かを分類する。default branch を直接変更しないことと、書き込みを伴う並列 worker が同じ working tree を共有しないことをここで保証する。後続 step 8 の `cross-review` に必要な CLI も同時に確認する。runtime は実行中 agent が明示的に把握している値を使い、`PATH` 上の CLI の存在順から推測しない。 -この step に入る前に、後続の step 8 で `cross-review` を実行できる runtime / CLI かを事前確認する。Codex CLI で実装している場合は `codex`、Claude Code で実装している場合は `claude` が必要。Cursor / Gemini など `cross-review` 側に手順が定義されていない runtime、または実行中 runtime を明示的に判定できない場合は、実装・commit に進む前に停止する。CLI の有無は対応するコマンドだけを `command -v` で確認し、インストール済み CLI の存在順から runtime を推測しない。 +```bash +DEFAULT_BRANCH=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name') +[ -n "$DEFAULT_BRANCH" ] || { echo "default branch を取得できませんでした。" >&2; exit 1; } +CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD) +GIT_COMMON_DIR=$(git rev-parse --git-common-dir) +GIT_DIR=$(git rev-parse --git-dir) +``` + +分類後は次の表に従う。ここでいう「専用 worktree」は `GIT_COMMON_DIR` と `GIT_DIR` が異なる linked worktree を指す。 + +| 現在位置 / 呼び出し方 | 判定 | +| --- | --- | +| すでに専用 worktree 内 | 二重作成せず、その worktree で続行する。 | +| default branch 以外の既存 feature branch、かつ単独実装 | ユーザーの branch を上書きせず、そのまま続行する。 | +| 並列 worker | **1 worker = 1 worktree を必須**とする。専用 worktree 内でなければ、branch 名にかかわらず実装・commit 前に停止する。同じ worktree を別 worker と共有しない。 | +| default branch | runtime 別手順で専用 worktree へ移る。安全に移行できなければ停止する。 | -1. **`EnterWorktree` ツールが利用可能** (= Claude Code 環境)。Codex CLI / Cursor / Gemini 等の非 Claude Code 環境では `EnterWorktree` が存在しないため自動的に false となり、本 step は skip される。 -2. **現在のセッションが worktree の外**: `git rev-parse --git-common-dir` と `git rev-parse --git-dir` の出力が一致する。一致しなければ既に worktree 内なので skip。 -3. **現在のブランチが default branch**: `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` の結果と `git rev-parse --abbrev-ref HEAD` が一致する。default branch 以外 (= ユーザーが手動で feature ブランチに切り替え済み) なら skip し、既存ブランチを尊重する。 -4. **対象 issue が step 1 のコメント確認を通過した `Status: Ready`**: step 1 で確認済みの値を使う。`Status: Draft` / フォーマット不完全 / コメント上の未解決 blocker・本文矛盾・方針保留・受け入れ条件の未反映変更は step 1 で early abort 済み (worktree も作成しない) なので、ここに到達した時点で常に「着手可能な Ready」。 +default branch 上の runtime 別分岐: -呼び方は **タスク説明モード** (issue 番号は渡さない)。issue title から kebab-case の slug を生成し、末尾に `-` を付けたブランチ名 (例: issue #42「Slack 連携の OAuth フロー」→ `slack-oauth-flow-42`) を指定する。issue 番号を渡すと `worktree-start` 側で Status 判定経路に入り `issue-implement` への再帰連鎖が発生してしまうため、Status は本 skill 側で既に確認済みである旨を踏まえて純粋な worktree 切り替え機能だけを使う形にする。 +- **Claude Code 対話 session**: `EnterWorktree` が利用できる場合だけ `issuekit:worktree-start` (APM plain-skill mode では `worktree-start`) を呼ぶ。issue title から作った `-` を **タスク説明モード**で渡し、切り替え後に `GIT_COMMON_DIR != GIT_DIR` を再確認してから続行する。`EnterWorktree` が無い旧版や、切り替えに失敗した場合は停止し、`claude --worktree -` で新しい session を開始して `issue-implement ` を再実行するよう案内する。 +- **Codex CLI**: worktree 作成を skip して続行してはならない。起動済み session の cwd を skill が安全に移せると仮定せず停止し、衝突しない実パスと branch 名を決めたうえで次の再開例を返す。 -いずれかの条件が欠ける場合は worktree を切らずにそのまま step 5 (実装) に進む: + ```bash + git worktree add ../.- -b - "$DEFAULT_BRANCH" + codex -C ../.- + # 新しい session で issue-implement を再実行 + ``` -- preflight を通過した非 Claude Code 環境 (= Codex CLI) → ユーザーが事前に切った worktree / branch で続行。Cursor / Gemini など `cross-review` 未対応 runtime は上記の事前確認で停止済み。 -- 既に worktree 内 → 二重発火を避けるため何もしない (`worktree-start` 側の再進入チェックでも no-op になる)。 -- default branch 以外のブランチ → ユーザーが意図して feature ブランチを切っているとみなし上書きしない。 +- **Codex App**: App の **Worktree** で開始済み、または **Handoff** で managed worktree へ移動済みなら続行する。Local の default branch 上なら実装前に停止し、App UI で Worktree chat を開始するか Handoff してから再実行するよう案内する。managed worktree / Handoff は runtime 所有であり、skill 自身は作成・操作しない。 +- **Claude Code Agent view / Desktop**: Agent view の background session と Desktop の新規 Code session は runtime が自動隔離する。実際に linked worktree へ移ったことを確認して続行する。移行前の main checkout では書き込みを始めない。 +- **未対応 runtime**: default branch 上では停止する。対応する reviewer-session launch 手順も無ければ、cross-review preflight の時点でも停止する。 -なお `worktree-start → issue-implement → worktree-start` の循環は、2 度目の `worktree-start` 呼び出しが上記条件 2 で worktree 内と判定され自動的に no-op になるため発生しない。 +`Status: Draft` / フォーマット不完全 / コメント上の blocker は step 1 で early abort 済みなので、この preflight に到達しない。`worktree-start → issue-implement` で入った場合は linked worktree 判定により二重作成しない。 ### 5. 実装（必要に応じて適宜 commit） @@ -169,8 +187,10 @@ PR URL と CI 結果（成功 / 修正後成功）をユーザーに返す。 ## やらないこと - default branch 名 (`main` / `master` / `develop` 等) を hardcode した branch ガード。step 4 の判定は `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` の結果と動的に比較する。 -- 非 Claude Code 環境向けの worktree 化フォールバック実装。`EnterWorktree` ツールが無い環境では step 4 を skip し、ユーザーが事前に切った worktree / branch でそのまま続行する。 -- 既に default branch 以外のブランチで作業しているユーザーへの worktree 強制切り替え。step 4 の条件 3 で skip する (= 既存 feature ブランチを尊重)。 +- default branch 上で worktree 化を単に skip して実装へ進むこと。runtime が安全に切り替えられなければ、書き込み・commit 前に停止して再開手順を返す。 +- Codex CLI の起動済み session の cwd を skill が変更すること、または Codex App の managed worktree / Handoff を skill が作成・操作すること。 +- 書き込みを伴う並列 worker が同じ worktree を共有すること。並列 worker は branch 名にかかわらず 1 worker = 1 worktree とする。 +- 単独実装で、すでに default branch 以外の feature branch にいるユーザーへの worktree 強制切り替え。step 4 の分類で既存 branch を尊重する。 - step 4 で `worktree-start` を呼ぶ際に issue 番号を渡すこと。issue 番号を渡すと `worktree-start` 側の Status 判定経路に入り `issue-implement` への再帰連鎖が起きるため、タスク説明モードで slug (`-<issue 番号>`) のみを渡す。 - issue 本文や PR への `close` キーワードの自動付与（ユーザー明示指定時のみ）。 - 受け入れ条件を満たさない状態での PR 作成。 diff --git a/skills/worktree-start/SKILL.md b/skills/worktree-start/SKILL.md index 38ece53..7407018 100644 --- a/skills/worktree-start/SKILL.md +++ b/skills/worktree-start/SKILL.md @@ -1,12 +1,12 @@ --- name: worktree-start -description: "Claude Code 専用。素の `claude` で起動した直後に、タスク説明または issue URL / 番号から命名した git worktree へ `EnterWorktree` で切り替えて作業を開始する。issue 起点・タスク起点どちらでも並列セッション立ち上げに使う。issue URL / 番号入力で Status: Ready かつコメント上の未解決事項がない場合は worktree 切り替え後に `issue-implement` へ自動連鎖する。" -version: 1.0.4 +description: "Claude Code 専用。起動済みの対話 session から、タスク説明または issue URL / 番号で命名した git worktree へ `EnterWorktree` で切り替える。既存 linked worktree では issuekit の安全策として no-op にし、issue URL / 番号が Status: Ready かつコメント上の未解決事項なしなら切り替え後に `issue-implement` へ自動連鎖する。" +version: 1.1.0 --- # Worktree Start Skill -Claude Code が v2.1.49 で導入した `EnterWorktree` ツールを使い、起動済みセッションの cwd を新規 git worktree に切り替えて並列タスクを開始する skill。`issue-implement` が「issue 起点の実装サイクル」の orchestrator であるのに対し、本 skill は **issue 起点・タスク起点どちらでも入れる entry point** として並ぶ。 +Claude Code の `EnterWorktree` ツールを使い、起動済み対話 session の cwd を専用 git worktree に切り替えてタスクを開始する skill。`issue-implement` が「issue 起点の実装サイクル」の orchestrator であるのに対し、本 skill は **issue 起点・タスク起点どちらでも入れる entry point** として並ぶ。 ## スコープ @@ -14,7 +14,7 @@ Claude Code が v2.1.49 で導入した `EnterWorktree` ツールを使い、起 - **含まない**: - **外部タブ管理ツール (ターミナルマルチプレクサ等) との連携**: 並列タブの起動はユーザー操作のまま。 - **Codex CLI / 他 agent 用の fallback 実装**: `EnterWorktree` は Claude Code 固有で、他 runtime には対応 primitive が存在しない。 - - **`EnterWorktree` の `path` パラメータでクリーン命名する回避策**: `worktree-` prefix 強制を許容する方針 (issue #13 スコープ外)。 + - **既存 worktree 間の移動**: 現行 `EnterWorktree` は `.claude/worktrees/` 配下の別 worktree へ path 指定で切り替えられるが、本 skill はタスクの二重割り当てを防ぐため、すでに linked worktree 内なら no-op とする。 - **作成済み worktree のクリーンアップ**: `ExitWorktree` / `git worktree remove` 等は呼ばない。 - **Status: Draft / フォーマット不完全な issue 入力時の `issue-implement` 連鎖**: 受け入れ条件が確定していない issue は着手対象外。worktree 作成のみ行い `issue-refine` を案内する。 @@ -25,13 +25,20 @@ Claude Code が v2.1.49 で導入した `EnterWorktree` ツールを使い、起 - すでにターミナルエミュレータで素の `claude` が起動しており、これから worktree に入りたい状況。 - `issuekit:issue-implement` skill (APM plain-skill mode では `issue-implement`) の冒頭ステップから呼ばれたとき。この場合は **Status / Depends on / 親 issue の確認は上流で完了済み**であり、本 skill 側では入力を「タスク説明モード」(後述 step 2) として扱って worktree 切り替え機能のみを提供する。詳細は後述「上流 skill (`issue-implement`) からの呼び出し」を参照。 -## Claude Code 限定であること +## Runtime ごとの位置づけ -本 skill は **Claude Code 専用** で、Codex CLI / Cursor / Gemini など他の agent runtime では利用できない。 +本 skill 自体は **Claude Code の対話 session 専用** で、Codex CLI / Codex App / Cursor / Gemini など他の agent runtime では利用できない。ただし worktree 隔離は各 runtime がそれぞれ所有する機能であり、次の境界を混同しない。 -- `EnterWorktree` ツールは Claude Code v2.1.49 (2026-02-19) で CLI に追加された Claude Code 固有の primitive である。 -- Codex CLI には worktree の概念がなく ([openai/codex#13120](https://github.com/openai/codex/issues/13120))、Codex Worktrees は Desktop app 専用機能のため CLI からは呼び出せない。 -- 他 agent からは fallback 実装を提供しない（issue #13 のスコープ外）。Codex 等で動かす場合は、ユーザーが手元で `git worktree add` を実行してから当該 worktree で agent を起動する従来手順に従うこと。 +| Runtime / 機能 | 隔離方法 | 本 skill の役割 | +| --- | --- | --- | +| Claude Code CLI 対話 session | 起動時は `claude --worktree <name>`、起動後は `EnterWorktree` | 起動後の `EnterWorktree` 呼び出しだけを担当する。 | +| Claude Code subagent | frontmatter の `isolation: worktree`、または spawn 時の `isolation: "worktree"` | 作成しない。subagent runtime に委ねる。 | +| Claude Code Agent view | background session が書き込み前に自動で専用 worktree へ移る | 作成しない。移行後の linked worktree では no-op。 | +| Claude Desktop Code session | 新規 session ごとに自動 worktree | 作成しない。Desktop runtime に委ねる。 | +| Codex CLI | `git worktree add` 後に `codex -C <path>` | fallback を実行しない。`issue-implement` が default branch 上で停止して再開手順を返す。 | +| Codex App | App の managed worktree / Handoff | App 所有。skill から作成・操作しない。 | + +Claude Code の現在の worktree 仕様は [公式 worktree ドキュメント](https://code.claude.com/docs/en/worktrees)、Agent view は [公式 Agent view ドキュメント](https://code.claude.com/docs/en/agent-view) を参照する。 ## 上流 skill (`issue-implement`) からの呼び出し @@ -43,11 +50,11 @@ Claude Code が v2.1.49 で導入した `EnterWorktree` ツールを使い、起 そのため `issue-implement` から呼ばれた際は、本 skill 側で再度 `gh issue view` による Status / Depends on / 親 issue の検証は行わない（**Status チェックは上流に委譲**）。具体的には、上流から渡されるのは **issue 番号ではなく事前生成済みのブランチ名 slug** (`<title-slug>-<issue 番号>` 形式) のみであり、本 skill はそれを step 2 の「タスク説明モード」と同じ経路で扱う。issue 番号を伴う入力経路 (Status 判定 → Ready 時に `issue-implement` 連鎖) には入らないため、`issue-implement → worktree-start → issue-implement` の再帰連鎖は発生しない。 -万一上流が誤って issue 番号を渡してしまった場合でも、step 2 の Ready 経路から `issue-implement` を呼び出すと、その呼び出し先 `issue-implement` が再度本 skill を呼び出した時点で step 1 の no-op 判定 (現セッションが既に worktree 内) に引っかかり何もしないため、循環は二重チェックで自動的に止まる。とはいえ無駄な再呼び出しを避けるため、上流からは必ずブランチ名 slug のみを渡す運用にすること (詳細は `issue-implement` の "やらないこと" 節を参照)。 +万一上流が誤って issue 番号を渡してしまった場合でも、step 2 の Ready 経路から `issue-implement` を呼び出すと、その呼び出し先 `issue-implement` が再度本 skill を呼び出した時点で step 1 の issuekit 固有 no-op 判定に引っかかり何もしないため、循環は止まる。とはいえ無駄な再呼び出しを避けるため、上流からは必ずブランチ名 slug のみを渡す運用にすること (詳細は `issue-implement` の "やらないこと" 節を参照)。 ## 依存 -- **Claude Code v2.1.49 以上**: `EnterWorktree` ツールを必要とする。古いバージョンでは tool not found となるため、`claude --version` で確認しユーザーへアップデートを案内する。 +- **`EnterWorktree` が利用できる Claude Code**: tool が無い場合は `claude --version` で確認し、最新版へ更新して session を再起動するか、`claude --worktree <name>` で新しい session を開始するよう案内する。 - **`git`**: worktree 作成のために必要（`EnterWorktree` の内部で利用される）。 - **git リポジトリ内であること**: 起動 cwd が git working tree でない場合、`EnterWorktree` は失敗する。 @@ -63,16 +70,16 @@ issue URL / 番号が渡された場合は、本 skill 側で `gh issue view --c ## 実行手順 -### 1. 既存 worktree への再進入チェック (no-op 判定) +### 1. 既存 worktree のチェック (issuekit 固有の no-op 判定) -`EnterWorktree` ツール自体が「既に worktree 内にいるセッション」からの再進入を拒否する。本 skill ではこれに依存し、**現在のセッションが worktree 内であることを検知できた場合は何もせず終了する**（呼び出し時点で no-op）。 +**現在の session が linked worktree 内なら何もせず終了する**。これは `EnterWorktree` primitive の一般的制約ではなく、「すでにタスク用 worktree にいる session を別 worktree へ動かさず、二重作成もしない」という issuekit 固有の安全方針である。現行 Claude Code は `EnterWorktree` に既存の `.claude/worktrees/` 配下 path を渡して別 worktree へ切り替えることもできるが、本 skill はその機能を使わない。 判定は以下のいずれかで行う: - `git rev-parse --git-common-dir` と `git rev-parse --git-dir` を比較し、異なれば worktree 内。 - もしくは `git worktree list` の現在 path がメイン working tree と異なるかを確認。 -`EnterWorktree` を投機的に呼んでツール側のエラーで気付く運用は避ける。skill 側で先に判定し、ユーザーには「すでに worktree 内のため何もしません」と返す。 +`EnterWorktree` を投機的に呼ばず skill 側で先に判定し、ユーザーには「すでに専用 worktree 内のため、この worktree で続行します」と返す。 ### 2. 入力タイプの判定と issue 取得 @@ -93,7 +100,7 @@ issue URL / 番号が渡された場合は、本 skill 側で `gh issue view --c - **issue 入力から**: issue title から同形式の slug を生成し、末尾に `-<issue 番号>` を付与する。issue とブランチを後から照合できるようにする狙い。 - 例: issue #42「Slack 連携の OAuth フロー」 → `slack-oauth-flow-42` - **ユーザー明示指定**: 「ブランチ名は `xxx` にして」と渡された場合は LLM 命名を行わずそのまま採用する。 -- prefix: `EnterWorktree` 側で `worktree-` プレフィックスが強制付与される仕様 ([Claude Code worktrees docs](https://code.claude.com/docs/en/worktrees)) を許容する。skill 側でクリーンな命名のために `path` パラメータで回避することはしない（issue #13 スコープ外）。 +- Claude Code の既定では `.claude/worktrees/<name>/` に `worktree-<name>` branch が作られる。この命名をそのまま許容する。既存名を再利用すると、状態に応じて既存 worktree が開かれるため、呼び出し前に `git worktree list` で意図した対象か確認する。 ### 4. `EnterWorktree` の呼び出し @@ -105,6 +112,8 @@ EnterWorktree({ name: "slack-oauth-flow-42" }) 成功すれば現在のセッションの cwd が新規 worktree (`worktree-slack-oauth-flow-42` 系のブランチ + 対応ディレクトリ) に切り替わる。以降のツール呼び出しは新 worktree 上で動作する。 +切り替え後は `git rev-parse --git-common-dir` と `git rev-parse --git-dir` が異なることを確認する。worktree は fresh checkout なので、依存関係の install、build cache、環境初期化が必要なら実装前に行う。gitignored な `.env` 等が必要なら repository root の `.worktreeinclude` に `.gitignore` 構文で列挙する。tracked file は対象にせず、secret を含む場合はコピー先も同じ権限境界にあることを確認する。 + ### 5. (issue Ready 時のみ) `issue-implement` への引き継ぎ step 2 で **issue URL / 番号 + `Status: Ready` + コメント上の未解決 blocker / 本文矛盾 / 方針保留 / 受け入れ条件の未反映変更なし** だった場合のみ、`issuekit:issue-implement` skill (APM plain-skill mode では `issue-implement`) を該当 issue 番号で呼び出し、issue 駆動の実装サイクルへ引き継ぐ。 @@ -124,19 +133,26 @@ step 2 で **issue URL / 番号 + `Status: Ready` + コメント上の未解決 - **issue Draft / 表記なしの場合**: `issue-refine` で整理してから再度呼ぶ案内。worktree は既に作成済み。 - **タスク説明の場合**: 「次は何をしますか?」の確認 (そのまま実装に入る、別 skill を呼ぶ、など)。 +## Resume / cleanup の扱い + +- worktree 内の session を `--resume` / `--continue` すると Claude Code はその worktree に戻る。元 worktree が無い場合は起動ディレクトリで再開する。`--fork-session` は起動ディレクトリから fork し、元 session の worktree は保持する。 +- 対話 session 終了時、clean な unnamed worktree は自動削除され、named session や変更・新規 commit がある worktree は keep / remove の確認対象になる。`-p` の非対話実行には終了確認がないため自動 cleanup されず、必要なら `git worktree remove <path>` を使う。 +- subagent / Agent view の runtime 管理 worktree は別の cleanup 規則を持つ。未変更なら自動削除され得るが、変更・未追跡 file・未 push commit がある場合は保持される。ユーザー変更を破棄する `--force` cleanup は自動実行しない。 +- worktree ごとに repository files、dependencies、build cache が増えるため disk 使用量を確認し、不要になった worktree は作業を保存したうえで整理する。 + ## 失敗時の対応 -- **`EnterWorktree` ツールが見つからない**: Claude Code が v2.1.49 未満。`claude --version` を確認し、`npm install -g @anthropic-ai/claude-code` でアップデートしてから再起動するよう案内する。 -- **「Already inside a worktree」系のエラーが返る**: skill 側の事前チェックを通り抜けてしまったケース。報告のみ行い、再呼び出しは試みない（既に目的の状態にある可能性が高い）。 +- **`EnterWorktree` ツールが見つからない**: `claude --version` を確認し、`npm install -g @anthropic-ai/claude-code` で最新版へ更新して session を再起動するか、`claude --worktree <name>` で新しい session を開始するよう案内する。 +- **切り替え後も linked worktree と確認できない**: 実装を開始せず停止し、`git worktree list` と Claude Code のエラーを確認する。既存 worktree ならその path で `claude` を開始し直す方法も案内する。 - **git リポジトリ外で呼ばれた**: `git rev-parse --is-inside-work-tree` で先に検知し、git repo 内で再実行するようユーザーへ案内する。 - **ブランチ名衝突**: `EnterWorktree` 側のエラー出力をそのままユーザーに見せ、別のブランチ名を提示してもらう（自動でサフィックス付与等は行わない。意図しない命名を避けるため）。 ## やらないこと -- **既に worktree 内にいるセッションでの再進入**: 上記 step 1 で no-op として返す。`EnterWorktree` 自体も再進入を拒否するため、二重チェック構造で安全側に倒す。 +- **既に worktree 内にいる session の別 worktree への移動**: primitive が可能でも、上記 step 1 で issuekit 固有の no-op とする。 - **外部タブ / ペインの自動起動**: 並列タブの起動はユーザー操作のまま。skill から外部のターミナルマルチプレクサ等を直接操作しない。 - **Status: Draft / フォーマット不完全な issue 入力時の `issue-implement` 連鎖**: 受け入れ条件が確定していない issue は着手対象外。worktree 作成までで止め、`issue-refine` を案内する。Status の判定軸は `issue-create` の定義 (受け入れ条件の確定度) に従う。 - **タスク説明 (issue なし) 入力時の `issue-implement` 連鎖**: issue 番号が文字列として登場しても、URL / 番号として明示入力されていなければ `gh issue view` を呼ばずタスク説明として扱う。連鎖は行わない。 -- **Codex CLI / 他 agent 用の fallback 実装**: 本 skill は Claude Code 専用。「Claude Code 限定であること」セクション参照。 -- **`EnterWorktree` の `path` パラメータでクリーン命名を試みる**: `worktree-` prefix 強制を許容する方針 (issue #13 スコープ外)。 +- **Codex CLI / 他 agent 用の fallback 実装**: 本 skill は Claude Code 専用。「Runtime ごとの位置づけ」セクション参照。 +- **Codex App の managed worktree / Handoff の作成・操作**: App 所有の UI / lifecycle を skill の機能として扱わない。 - **作成済み worktree のクリーンアップ**: `ExitWorktree` / `git worktree remove` 等は呼ばない。worktree のライフサイクル管理はユーザー責務。 From 4d02746bff0faadc83b917337233f9bb54ffda27 Mon Sep 17 00:00:00 2001 From: Hiroki SAKABE <hiroki.sakabe@icloud.com> Date: Sun, 2 Aug 2026 00:41:31 +0900 Subject: [PATCH 2/7] docs: align runtime worktree guidance --- AGENTS.md | 24 +++++++++++++++--------- README.md | 39 +++++++++++++++++++++++++++++++-------- 2 files changed, 46 insertions(+), 17 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index eb03ebe..b365f80 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -16,13 +16,13 @@ The bundle codifies an **issue-driven development** workflow where the GitHub is - `issue-implement` → `acceptance-check` (verifies `## 受け入れ条件` against the final repo state after implementation+commits, **before** `cross-review` so an acceptance ✗ does not waste a cross-review pass) - `issue-implement` → `cross-review` (second-opinion code review of the `base...HEAD` diff after `acceptance-check` passes, before PR creation; review fixes land as additional commits, not amends) -- `issue-implement` → `worktree-start` (**conditional**, before implementation in `issue-implement` step 4): fires only when **all four** conditions hold — `EnterWorktree` is available (= Claude Code runtime), the session is outside any worktree (`git rev-parse --git-common-dir` == `--git-dir`), the current branch is the repo's default branch (`gh repo view --json defaultBranchRef`), and `Status: Ready`. `Status: Draft` triggers an early abort in step 1, so the worktree is never created for Draft issues. +- `issue-implement` → `worktree-start` (**conditional**, inside the mandatory isolation preflight before implementation): fires only for a Claude Code interactive session on the repository's default branch when `EnterWorktree` is available. An existing linked worktree is reused; an existing non-default feature branch is preserved for a single implementation; unsafe runtime/location combinations stop before writes or commits. `Status: Draft` still aborts in step 1 before this preflight. - `worktree-start` → `issue-implement` (**only** when input is an issue URL/number with `Status: Ready`; with a generic task description, `Status: Draft`, or unformatted issues it stops at the worktree switch) - `issue-create` / `issue-refine` / `issue-pick` are entry points; they do not chain into other skills. `issue-pick` is a triage entry point and does not chain (see its "やらないこと" — handing off to `issue-implement` is via user only). The `issue-implement ↔ worktree-start` edge is **bidirectional but not looping**: -- When `worktree-start` is the entry point and chains forward into `issue-implement`, the latter would re-invoke `worktree-start`, but the second call hits the "already inside a worktree" no-op check and returns immediately. +- When `worktree-start` is the entry point and chains forward into `issue-implement`, the latter sees that it is already in a linked worktree and continues without re-invoking `worktree-start`. - When `issue-implement` is the entry point and calls `worktree-start` from step 4, it must pass a pre-generated branch-name slug (`<title>-<issue番号>`), **not** the issue number. Passing the number would re-enter `worktree-start`'s Status-detection path and re-chain back into `issue-implement` unnecessarily. The recursion would still terminate via the no-op check, but the redundant invocation is avoided by routing through the task-description mode of `worktree-start`. When editing one skill, check whether others reference it. Cross-references appear in two forms: @@ -56,14 +56,20 @@ These strings are not localizable in the current implementation. Forking is requ `acceptance-check` reports `✓ / ✗ / ?` and never writes. It does not flip `- [ ]` to `- [x]`, never edits issue bodies, and does not perform actual UI/CLI verification (only suggests how). `?` items are explicitly delegated to the caller. -## Worktree-start is Claude Code only +## Runtime worktree isolation -`worktree-start` invokes the `EnterWorktree` tool added to Claude Code in v2.1.49 (2026-02-19). This primitive is Claude Code-specific: +`issue-implement` step 4 is a mandatory isolation preflight. It resolves the default branch dynamically, checks `git rev-parse --git-common-dir` against `--git-dir`, and classifies the runtime/location before any implementation write or commit: -- Codex CLI has no worktree concept ([openai/codex#13120](https://github.com/openai/codex/issues/13120)); Codex Worktrees ship only in the Desktop app, not the CLI. -- The skill therefore does **not** provide a fallback for non-Claude-Code agents — when run under another runtime the `EnterWorktree` tool will simply not exist. Users on Codex / Cursor / Gemini should fall back to plain `git worktree add` outside the agent. -- Branch naming is the skill's responsibility (LLM-named in kebab-case, or user-supplied verbatim). The `worktree-` prefix forced by `EnterWorktree` is intentionally accepted; the `path` parameter escape hatch is out of scope (see issue #13). -- The skill is a no-op when the current session is already inside a worktree — `EnterWorktree` itself rejects re-entry, and the skill double-checks via `git rev-parse --git-common-dir` / `--git-dir` before calling the tool. +- A linked worktree continues without double creation. A non-default feature branch is preserved for a single implementation. +- A write-capable parallel worker requires **one worker = one worktree** even if it is already on a feature branch; workers never share a working tree. +- Default-branch execution must move to a dedicated worktree or stop before implementation. There is no skip-and-continue path. +- Codex CLI stops and instructs the user to run ordinary `git worktree add`, then `codex -C <path>` in a new session. The running session is not assumed to migrate cwd. +- Codex App managed worktrees and Handoff are App-owned. Skills may verify that the chat is isolated or tell the user to use the App UI, but must not claim to create or control App-managed worktrees. +- Claude Code interactive sessions may invoke `worktree-start`, which owns the in-session `EnterWorktree` call. `claude --worktree`, subagent `isolation: worktree`, Agent view background-session isolation, and Desktop automatic session worktrees remain runtime-owned paths. + +`worktree-start` is therefore still Claude Code-only, but its no-op inside an existing linked worktree is an **issuekit policy**, not a general `EnterWorktree` limitation. Current Claude Code can switch to another existing worktree under `.claude/worktrees/`; issuekit intentionally does not do so because it would displace a session already assigned to a task. Resume and cleanup follow the current [Claude Code worktree documentation](https://code.claude.com/docs/en/worktrees): resumes return to the associated worktree when it exists, interactive exit cleanup depends on whether work is present, and non-interactive `-p` worktrees require manual cleanup. + +Worktrees are fresh checkouts. Document dependency/environment initialization and disk usage where relevant. `.worktreeinclude` is for ignored local files needed by Claude Code-created and Codex App managed worktrees; it does not apply to ordinary `git worktree add`. ## Cross-review reviewer session selection @@ -82,7 +88,7 @@ The runtime must be determined from the running agent's explicit environment, no - `gh` CLI — all GitHub operations. Must be authenticated against the target repo. - The CLI for the current agent runtime: Codex CLI (`brew install --cask codex`) when implementing from Codex, or Claude CLI (`npm install -g @anthropic-ai/claude-code`) when implementing from Claude Code. `cross-review` must fail loudly (not silently skip) when the corresponding CLI is unavailable or the current runtime has no documented reviewer-session launch step. -- Claude Code v2.1.49 or newer — required by `worktree-start` for the `EnterWorktree` tool. Older versions surface this as "tool not found"; the skill instructs users to upgrade rather than attempting any workaround. +- Claude Code with `EnterWorktree` support — required by `worktree-start`. If unavailable, the skill instructs users to update/restart or start a new isolated session with `claude --worktree` rather than continuing on the default branch. ## Editing skills diff --git a/README.md b/README.md index 99cfde6..45c1243 100644 --- a/README.md +++ b/README.md @@ -25,6 +25,7 @@ An Agent Skills bundle that treats each GitHub issue as the canonical "rich plan - [📦 Install](#-install) - [🛠️ Dependencies](#-dependencies) - [🧩 Skills](#-skills) +- [🌳 Worktree isolation](#-worktree-isolation) - [🔁 Workflow](#-workflow) - [💡 Philosophy](#-philosophy) - [🆚 Comparison with related frameworks](#-comparison-with-related-frameworks) @@ -78,7 +79,7 @@ issuekit assumes the following tools are available on the host: - **The CLI for your current agent runtime** — required by `cross-review` to start an independent reviewer session: - **[Codex CLI](https://github.com/openai/codex)** (`brew install --cask codex`) when the implementation is driven from Codex CLI. - **[Claude CLI](https://docs.claude.com/en/docs/claude-code)** (`npm install -g @anthropic-ai/claude-code`) when the implementation is driven from Claude Code (uses `claude -p` headless mode). -- **Claude Code v2.1.49 or newer** — required by `worktree-start` only (it uses the `EnterWorktree` tool added in 2.1.49). Other skills load on any Agent Skills-compatible runtime, but `cross-review` currently documents reviewer-session launch steps only for Codex CLI and Claude Code. +- **Claude Code with `EnterWorktree` support** — required by `worktree-start`. If the tool is unavailable, update Claude Code and restart the session, or start a new isolated session with `claude --worktree <name>`. Other skills load on any Agent Skills-compatible runtime, but `cross-review` currently documents reviewer-session launch steps only for Codex CLI and Claude Code. `gh` must be authenticated against the repository you want to operate on. `cross-review` does not switch to another backend automatically; it uses the CLI that corresponds to the runtime currently driving the implementation. If that CLI is unavailable, or if the current runtime has no documented reviewer-session launch step, `cross-review` fails explicitly rather than silently skipping the review. @@ -93,17 +94,36 @@ issuekit ships seven skills under `skills/`: | `issue-create` | Entry point | Open a new GitHub issue using issuekit's standard format (`Status: Ready` / `Status: Draft` header, intent, plan, acceptance criteria, out-of-scope). | | `issue-refine` | Entry point | Re-shape an existing issue (title-only or partially formatted) into the standard format. | | `issue-pick` | Entry point | Read-only triage: from a set of open issues, suggest the next one to take on, with rationale. | -| `worktree-start` | Entry point | **Claude Code only.** Switch the running session into a freshly named git worktree via the `EnterWorktree` tool. Accepts a task description **or** an issue URL/number — when the input is a `Status: Ready` issue, it chains into `issue-implement` after the worktree switch (otherwise it stops at the switch). | -| `issue-implement` | Orchestrator| Drive the full cycle from an issue number: status check → worktree start → implementation / commits → acceptance check → cross-review → PR → CI. The full cycle currently requires Codex CLI or Claude Code because of `cross-review`. | +| `worktree-start` | Entry point | **Claude Code interactive sessions only.** Switch the running session into a named git worktree via `EnterWorktree`. If already in a linked worktree, issuekit leaves it there. A `Status: Ready` issue chains into `issue-implement` after the switch. | +| `issue-implement` | Orchestrator| Drive the full cycle from an issue number: status check → mandatory isolation preflight → implementation / commits → acceptance check → cross-review → PR → CI. The full cycle currently requires Codex CLI or Claude Code because of `cross-review`. | | `acceptance-check` | Verifier | Read-only verifier that extracts `## 受け入れ条件` from an issue body and reports each item as `✓ / ✗ / ?`. Called by `issue-implement` after implementation/commits, before `cross-review`. | | `cross-review` | Verifier | Start an independent reviewer session with the current runtime's CLI and get a second-opinion code review before PR creation. Called by `issue-implement` after `acceptance-check` passes; review fixes land as additional commits. | -`issue-implement` is the orchestrator; the other skills are either entry points or verifiers it calls. `worktree-start` is the only entry point that is Claude Code-specific (`EnterWorktree` is a Claude Code primitive — Codex CLI has no equivalent), so it has no fallback under other agent runtimes. It is also the only entry point that conditionally chains into the orchestrator: when invoked with an issue URL/number whose body has `Status: Ready`, it hands off to `issue-implement` after the worktree switch. +`issue-implement` is the orchestrator; the other skills are either entry points or verifiers it calls. `worktree-start` is the only Claude Code-specific entry point and owns only the in-session `EnterWorktree` transition. Codex App managed worktrees and Handoff remain App-owned, while Codex CLI users create ordinary git worktrees outside the running agent session. `worktree-start` conditionally chains into the orchestrator when invoked with a `Status: Ready` issue. `Status: Draft` is reserved for issues whose acceptance criteria are not yet certain. Draft issues include a `## Ready にするための未決事項` checklist containing the concrete decisions needed to finalize those criteria; implementation-plan choices alone do not make an issue Draft. --- +## 🌳 Worktree isolation + +Before `issue-implement` writes files or commits, it classifies the current location as a linked worktree, a non-default feature branch, or the repository's default branch. An existing linked worktree is reused without creating another one. A single implementation on an existing feature branch is also preserved. A write-capable parallel worker is stricter: **one worker must have one dedicated worktree**, and workers must never share a working tree. + +[Codex subagent workflows](https://learn.chatgpt.com/docs/agent-configuration/subagents) are available in the CLI, IDE extension, and App, but orchestration does not itself isolate file writes. Keep parallel exploration and review read-only where possible; if multiple workers write, assign each worker a separate worktree. + +| Runtime | Isolation contract on the default branch | +| --- | --- | +| Codex CLI | Stop before implementation. Create an ordinary worktree with `git worktree add`, then start a new session with [`codex -C <path>`](https://learn.chatgpt.com/docs/codex/cli/reference) and rerun `issue-implement`. The running CLI session is not assumed to migrate cwd safely. | +| Codex App | Start the chat in an App-managed **Worktree**, or use **Handoff** from Local to Worktree. These are App-owned features; issuekit does not create or control managed worktrees. See [Codex Worktrees](https://learn.chatgpt.com/docs/environments/git-worktrees). | +| Claude Code CLI | Start isolated with `claude --worktree <name>`, or let `worktree-start` use `EnterWorktree` from an interactive session. See [Claude Code worktrees](https://code.claude.com/docs/en/worktrees). | +| Claude Code subagent | Set `isolation: worktree` in the agent frontmatter or spawn configuration. See [Claude Code subagents](https://code.claude.com/docs/en/sub-agents). | +| Claude Code Agent view | Background sessions move into isolated worktrees before editing unless isolation is explicitly disabled. See [Agent view](https://code.claude.com/docs/en/agent-view#how-file-edits-are-isolated). | +| Claude Desktop Code session | New sessions receive automatic worktrees; lifecycle remains Desktop-owned. See [Claude Desktop](https://code.claude.com/docs/en/desktop#work-in-parallel-with-sessions). | + +A worktree is a fresh checkout. Install dependencies and initialize the environment in each worktree as needed; dependencies and build caches can multiply disk usage. If ignored local files such as `.env` or `.env.local` are required, add a repository-root `.worktreeinclude` using `.gitignore` syntax. Only ignored files are copied by Codex App managed worktrees and Claude Code-created worktrees; ordinary `git worktree add` does not process this file. Keep secrets within the same trust boundary and do not list tracked files. + +--- + ## 🔁 Workflow The skills compose into a single issue-driven cycle. Entry points feed an issue into the orchestrator, which calls the verifiers before producing a commit and a PR. @@ -113,8 +133,11 @@ flowchart LR A[issue-create] --> I[(GitHub issue<br/>Status: Ready)] R[issue-refine] --> I P[issue-pick] -. suggests .-> I - I --> W[worktree-start] - W --> IMPL[issue-implement<br/>implementation + commits] + I --> PF[issue-implement<br/>isolation preflight] + PF -->|Claude Code default branch| W[worktree-start] + W --> IMPL[implementation + commits] + PF -->|existing worktree / feature branch| IMPL + PF -. unsafe runtime/location: stop .-> STOP[restart in isolated worktree] IMPL --> AC[acceptance-check] AC --> CR[cross-review] CR --> C[PR + CI] @@ -125,9 +148,9 @@ flowchart LR classDef out fill:#f3f4f6,stroke:#6b7280,color:#1f2937 class A,R,P,W entry - class IMPL orch + class PF,IMPL orch class CR,AC ver - class I,C out + class I,C,STOP out ``` --- From 2ca00a90e2d59db5585ef95815c09d94dc62d80c Mon Sep 17 00:00:00 2001 From: Hiroki SAKABE <hiroki.sakabe@icloud.com> Date: Sun, 2 Aug 2026 00:45:17 +0900 Subject: [PATCH 3/7] fix: harden isolation preflight paths --- AGENTS.md | 4 ++-- README.md | 2 +- skills/issue-implement/SKILL.md | 27 +++++++++++++++++---------- skills/worktree-start/SKILL.md | 30 ++++++++++++++++++------------ 4 files changed, 38 insertions(+), 25 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index b365f80..8c0c267 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -60,8 +60,8 @@ These strings are not localizable in the current implementation. Forking is requ `issue-implement` step 4 is a mandatory isolation preflight. It resolves the default branch dynamically, checks `git rev-parse --git-common-dir` against `--git-dir`, and classifies the runtime/location before any implementation write or commit: -- A linked worktree continues without double creation. A non-default feature branch is preserved for a single implementation. -- A write-capable parallel worker requires **one worker = one worktree** even if it is already on a feature branch; workers never share a working tree. +- A linked worktree continues without double creation. A non-default feature branch is preserved for a single implementation. A main working tree in detached HEAD stops as unclassifiable; a runtime-owned detached HEAD linked worktree (such as Codex App) is allowed. +- A write-capable parallel worker is evaluated first and requires **one worker = one worktree** even if it is already on a feature branch. Continue only when runtime/session context establishes that the linked worktree is dedicated to that worker; otherwise stop. - Default-branch execution must move to a dedicated worktree or stop before implementation. There is no skip-and-continue path. - Codex CLI stops and instructs the user to run ordinary `git worktree add`, then `codex -C <path>` in a new session. The running session is not assumed to migrate cwd. - Codex App managed worktrees and Handoff are App-owned. Skills may verify that the chat is isolated or tell the user to use the App UI, but must not claim to create or control App-managed worktrees. diff --git a/README.md b/README.md index 45c1243..3dc786b 100644 --- a/README.md +++ b/README.md @@ -107,7 +107,7 @@ issuekit ships seven skills under `skills/`: ## 🌳 Worktree isolation -Before `issue-implement` writes files or commits, it classifies the current location as a linked worktree, a non-default feature branch, or the repository's default branch. An existing linked worktree is reused without creating another one. A single implementation on an existing feature branch is also preserved. A write-capable parallel worker is stricter: **one worker must have one dedicated worktree**, and workers must never share a working tree. +Before `issue-implement` writes files or commits, it classifies the current location as a linked worktree, a non-default feature branch, or the repository's default branch. An existing linked worktree is reused without creating another one. A single implementation on an existing feature branch is also preserved. A write-capable parallel worker is evaluated first and is stricter: **one worker must have one dedicated worktree**. If exclusive assignment cannot be established from runtime/session context, the worker stops instead of assuming a linked worktree is safe. [Codex subagent workflows](https://learn.chatgpt.com/docs/agent-configuration/subagents) are available in the CLI, IDE extension, and App, but orchestration does not itself isolate file writes. Keep parallel exploration and review read-only where possible; if multiple workers write, assign each worker a separate worktree. diff --git a/skills/issue-implement/SKILL.md b/skills/issue-implement/SKILL.md index 4663592..8e60682 100644 --- a/skills/issue-implement/SKILL.md +++ b/skills/issue-implement/SKILL.md @@ -1,7 +1,7 @@ --- name: issue-implement description: 特定の GitHub issue への実装着手と PR 作成を依頼されたときに使う。issue 番号・URL・会話内で選んだ issue のいずれかを起点に、runtime と worktree の実装隔離を preflight で保証してから、実装・commit・lint・受け入れ条件チェック・cross-review・PR 作成・CI 確認まで一気通貫で自動進行する。コードを書いてプルリクを出す作業全般が対象で、issue 選定相談・タイトル編集・クローズ操作・PR レビュー単体には使わない。 -version: 1.1.0 +version: 2.0.0 --- # Issue Implement Skill @@ -79,20 +79,27 @@ gh api "repos/${REPO}/issues/${ISSUE_NUMBER}/parent" --jq '{number, title, state 実装・ファイル書き込み・commit の **前** に runtime、現在 branch、worktree 状態、並列 worker かを分類する。default branch を直接変更しないことと、書き込みを伴う並列 worker が同じ working tree を共有しないことをここで保証する。後続 step 8 の `cross-review` に必要な CLI も同時に確認する。runtime は実行中 agent が明示的に把握している値を使い、`PATH` 上の CLI の存在順から推測しない。 ```bash -DEFAULT_BRANCH=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name') -[ -n "$DEFAULT_BRANCH" ] || { echo "default branch を取得できませんでした。" >&2; exit 1; } -CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD) -GIT_COMMON_DIR=$(git rev-parse --git-common-dir) -GIT_DIR=$(git rev-parse --git-dir) +DEFAULT_BRANCH=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name') || { echo "default branch を取得できませんでした。" >&2; exit 1; } +[ -n "$DEFAULT_BRANCH" ] || { echo "default branch が空です。" >&2; exit 1; } +GIT_COMMON_DIR=$(git rev-parse --git-common-dir) || { echo "git common dir を取得できませんでした。" >&2; exit 1; } +GIT_DIR=$(git rev-parse --git-dir) || { echo "git dir を取得できませんでした。" >&2; exit 1; } +if CURRENT_BRANCH=$(git symbolic-ref --quiet --short HEAD); then + : # branch checkout +elif [ "$GIT_COMMON_DIR" != "$GIT_DIR" ]; then + CURRENT_BRANCH='' # Codex App 等の detached HEAD linked worktree は worktree 判定で扱う +else + echo "main working tree が detached HEAD のため安全に分類できません。" >&2 + exit 1 +fi ``` -分類後は次の表に従う。ここでいう「専用 worktree」は `GIT_COMMON_DIR` と `GIT_DIR` が異なる linked worktree を指す。 +分類後は次の表を **上から順に**評価する。ここでいう「専用 worktree」は `GIT_COMMON_DIR` と `GIT_DIR` が異なるだけでなく、runtime の session / worker 情報または呼び出し文脈から、その worker に排他的に割り当てられたと確認できる linked worktree を指す。専用か確認できなければ共有されている可能性があるため停止する。 | 現在位置 / 呼び出し方 | 判定 | | --- | --- | -| すでに専用 worktree 内 | 二重作成せず、その worktree で続行する。 | -| default branch 以外の既存 feature branch、かつ単独実装 | ユーザーの branch を上書きせず、そのまま続行する。 | -| 並列 worker | **1 worker = 1 worktree を必須**とする。専用 worktree 内でなければ、branch 名にかかわらず実装・commit 前に停止する。同じ worktree を別 worker と共有しない。 | +| 並列 worker | **最優先。1 worker = 1 worktree を必須**とする。その worker 専用と確認できる linked worktree 内でなければ、branch 名にかかわらず実装・commit 前に停止する。同じ worktree を別 worker と共有しない。 | +| 単独 session ですでに専用 worktree 内 | detached HEAD を含め、二重作成せずその worktree で続行する。 | +| default branch 以外の既存 feature branch、かつ単独実装 | ユーザーの branch を上書きせず、そのまま続行する。`CURRENT_BRANCH` が空ならこの判定に入れない。 | | default branch | runtime 別手順で専用 worktree へ移る。安全に移行できなければ停止する。 | default branch 上の runtime 別分岐: diff --git a/skills/worktree-start/SKILL.md b/skills/worktree-start/SKILL.md index 7407018..efd5896 100644 --- a/skills/worktree-start/SKILL.md +++ b/skills/worktree-start/SKILL.md @@ -1,6 +1,6 @@ --- name: worktree-start -description: "Claude Code 専用。起動済みの対話 session から、タスク説明または issue URL / 番号で命名した git worktree へ `EnterWorktree` で切り替える。既存 linked worktree では issuekit の安全策として no-op にし、issue URL / 番号が Status: Ready かつコメント上の未解決事項なしなら切り替え後に `issue-implement` へ自動連鎖する。" +description: "Claude Code 専用。起動済みの対話 session から、タスク説明または issue URL / 番号で命名した git worktree へ `EnterWorktree` で切り替える。既存 linked worktree では worktree 作成だけを issuekit の安全策として no-op にし、issue URL / 番号が Status: Ready かつコメント上の未解決事項なしなら `issue-implement` へ自動連鎖する。" version: 1.1.0 --- @@ -72,24 +72,30 @@ issue URL / 番号が渡された場合は、本 skill 側で `gh issue view --c ### 1. 既存 worktree のチェック (issuekit 固有の no-op 判定) -**現在の session が linked worktree 内なら何もせず終了する**。これは `EnterWorktree` primitive の一般的制約ではなく、「すでにタスク用 worktree にいる session を別 worktree へ動かさず、二重作成もしない」という issuekit 固有の安全方針である。現行 Claude Code は `EnterWorktree` に既存の `.claude/worktrees/` 配下 path を渡して別 worktree へ切り替えることもできるが、本 skill はその機能を使わない。 +**現在の session が linked worktree 内なら新しい worktree は作らない**。これは `EnterWorktree` primitive の一般的制約ではなく、「すでにタスク用 worktree にいる session を別 worktree へ動かさず、二重作成もしない」という issuekit 固有の安全方針である。現行 Claude Code は `EnterWorktree` に既存の `.claude/worktrees/` 配下 path を渡して別 worktree へ切り替えることもできるが、本 skill はその機能を使わない。 + +その後の制御は入力ごとに分ける: + +- **上流 `issue-implement` からの slug / タスク説明**: worktree 切り替えだけを skip して呼び出し元へ戻る。上流はその worktree で実装を続ける。 +- **直接渡されたタスク説明**: worktree 切り替えだけを skip し、この worktree で次に何をするか確認して終了する。 +- **直接渡された issue URL / 番号**: step 2 の Status / コメント確認へ進む。step 3 / 4 の作成は skip し、Ready なら step 5 で `issue-implement` へ引き継ぐ。Draft / 表記なし / blocker ありなら step 6 の報告へ進む。 判定は以下のいずれかで行う: - `git rev-parse --git-common-dir` と `git rev-parse --git-dir` を比較し、異なれば worktree 内。 - もしくは `git worktree list` の現在 path がメイン working tree と異なるかを確認。 -`EnterWorktree` を投機的に呼ばず skill 側で先に判定し、ユーザーには「すでに専用 worktree 内のため、この worktree で続行します」と返す。 +`EnterWorktree` を投機的に呼ばず skill 側で先に判定し、ユーザーには「すでに専用 worktree 内のため、作成は skip してこの worktree を使います」と返す。 ### 2. 入力タイプの判定と issue 取得 ユーザー入力を以下に分類する: - **タスク説明 (issue なし)**: そのまま step 3 のブランチ名生成へ進む。issue 連鎖は行わない (step 5 はスキップ)。`issue-implement` 上流から呼ばれた場合 (= 事前生成済みブランチ名 slug が渡される) もこの経路で扱い、Status 判定や `gh issue view` は走らせない。 -- **issue URL / 番号**: URL から番号を抽出し、`gh issue view <N> --comments` で本文、title、コメントを取得する。本文先頭の `Status:` を確認し、コメントに本文未反映の補足や矛盾がないかも確認して以下に分岐する。本文とコメントが矛盾する場合は、`updatedAt` やコメント時系列を踏まえて最新の意図を推定し、判断できないものだけを要確認として扱う: - - **`Status: Ready` かつコメントに未解決 blocker / 本文との矛盾 / 方針保留 / 受け入れ条件の未反映変更が無い**: 連鎖対象。step 3 でブランチ名を生成し、step 4 完了後 step 5 で `issue-implement` へ引き継ぐ。 - - **`Status: Ready` だがコメントに未解決 blocker / 本文との矛盾 / 方針保留 / 受け入れ条件の未反映変更がある**: 受け入れ条件や前提が揺らいでいるため `issue-implement` への連鎖は **行わない**。worktree は作成して切り替えるが、step 6 の完了報告でコメント上の要確認点を示し、ユーザー確認または `issue-refine` での整理を案内する。 - - **`Status: Draft`**: 受け入れ条件が未確定なため `issue-implement` への連鎖は **行わない**。worktree は作成して切り替えるが、step 6 の完了報告で `issuekit:issue-refine` skill (APM plain-skill mode では `issue-refine`) での整理を案内する。 +- **issue URL / 番号**: URL から番号を抽出し、`gh issue view <N> --comments` で本文、title、コメントを取得する。すでに linked worktree 内なら step 3 / 4 の作成だけを skip する。本文先頭の `Status:` を確認し、コメントに本文未反映の補足や矛盾がないかも確認して以下に分岐する。本文とコメントが矛盾する場合は、`updatedAt` やコメント時系列を踏まえて最新の意図を推定し、判断できないものだけを要確認として扱う: + - **`Status: Ready` かつコメントに未解決 blocker / 本文との矛盾 / 方針保留 / 受け入れ条件の未反映変更が無い**: 連鎖対象。既存 linked worktree でなければ step 3 / 4 で作成・切り替え、既存ならその2 stepを skip して、step 5 で `issue-implement` へ引き継ぐ。 + - **`Status: Ready` だがコメントに未解決 blocker / 本文との矛盾 / 方針保留 / 受け入れ条件の未反映変更がある**: 受け入れ条件や前提が揺らいでいるため `issue-implement` への連鎖は **行わない**。既存 linked worktree でなければ worktree を作成して切り替え、既存なら保持したうえで、step 6 の完了報告でコメント上の要確認点を示す。 + - **`Status: Draft`**: 受け入れ条件が未確定なため `issue-implement` への連鎖は **行わない**。既存 linked worktree でなければ worktree を作成して切り替え、既存なら保持したうえで、step 6 の完了報告で `issuekit:issue-refine` skill (APM plain-skill mode では `issue-refine`) での整理を案内する。 - **`Status:` 表記なし / フォーマット不完全**: 同様に連鎖せず、`issue-refine` を案内する。 ### 3. ブランチ名の決定 @@ -104,7 +110,7 @@ issue URL / 番号が渡された場合は、本 skill 側で `gh issue view --c ### 4. `EnterWorktree` の呼び出し -確定したブランチ名を `name` 引数に渡して `EnterWorktree` を呼ぶ。 +step 1 で既存 linked worktree と判定済みなら本 step は skip し、現在の worktree を保持する。それ以外では、確定したブランチ名を `name` 引数に渡して `EnterWorktree` を呼ぶ。 ``` EnterWorktree({ name: "slack-oauth-flow-42" }) @@ -127,10 +133,10 @@ step 2 で **issue URL / 番号 + `Status: Ready` + コメント上の未解決 ユーザーには以下を返す: -- 入った worktree のパス (新 cwd) と作成されたブランチ名 (`worktree-` prefix 込み)。 +- 使用する worktree のパス (新規作成時は新 cwd) と branch 名。既存 linked worktree を再利用した場合は、その path と branch / detached HEAD 状態を返す。 - **issue Ready で連鎖した場合**: `issue-implement <N>` を起動済みで、続けて issue サイクルが進むこと。 -- **issue Ready だがコメント上の要確認点があり連鎖しなかった場合**: 要確認点を列挙し、ユーザー確認または `issue-refine` で整理してから再度呼ぶ案内。worktree は既に作成済み。 -- **issue Draft / 表記なしの場合**: `issue-refine` で整理してから再度呼ぶ案内。worktree は既に作成済み。 +- **issue Ready だがコメント上の要確認点があり連鎖しなかった場合**: 要確認点を列挙し、ユーザー確認または `issue-refine` で整理してから再度呼ぶ案内。新規作成または再利用した worktree は保持する。 +- **issue Draft / 表記なしの場合**: `issue-refine` で整理してから再度呼ぶ案内。新規作成または再利用した worktree は保持する。 - **タスク説明の場合**: 「次は何をしますか?」の確認 (そのまま実装に入る、別 skill を呼ぶ、など)。 ## Resume / cleanup の扱い @@ -149,7 +155,7 @@ step 2 で **issue URL / 番号 + `Status: Ready` + コメント上の未解決 ## やらないこと -- **既に worktree 内にいる session の別 worktree への移動**: primitive が可能でも、上記 step 1 で issuekit 固有の no-op とする。 +- **既に worktree 内にいる session の別 worktree への移動**: primitive が可能でも、上記 step 1 で worktree 作成だけを issuekit 固有の no-op とする。直接 issue 入力の Status 確認と `issue-implement` 連鎖まで止めない。 - **外部タブ / ペインの自動起動**: 並列タブの起動はユーザー操作のまま。skill から外部のターミナルマルチプレクサ等を直接操作しない。 - **Status: Draft / フォーマット不完全な issue 入力時の `issue-implement` 連鎖**: 受け入れ条件が確定していない issue は着手対象外。worktree 作成までで止め、`issue-refine` を案内する。Status の判定軸は `issue-create` の定義 (受け入れ条件の確定度) に従う。 - **タスク説明 (issue なし) 入力時の `issue-implement` 連鎖**: issue 番号が文字列として登場しても、URL / 番号として明示入力されていなければ `gh issue view` を呼ばずタスク説明として扱う。連鎖は行わない。 From 1aa107a8b6c193375ce337f8f411f98ec217df91 Mon Sep 17 00:00:00 2001 From: Hiroki SAKABE <hiroki.sakabe@icloud.com> Date: Sun, 2 Aug 2026 00:46:59 +0900 Subject: [PATCH 4/7] fix: mark worktree chaining as breaking --- skills/worktree-start/SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/skills/worktree-start/SKILL.md b/skills/worktree-start/SKILL.md index efd5896..a11defe 100644 --- a/skills/worktree-start/SKILL.md +++ b/skills/worktree-start/SKILL.md @@ -1,7 +1,7 @@ --- name: worktree-start description: "Claude Code 専用。起動済みの対話 session から、タスク説明または issue URL / 番号で命名した git worktree へ `EnterWorktree` で切り替える。既存 linked worktree では worktree 作成だけを issuekit の安全策として no-op にし、issue URL / 番号が Status: Ready かつコメント上の未解決事項なしなら `issue-implement` へ自動連鎖する。" -version: 1.1.0 +version: 2.0.0 --- # Worktree Start Skill From 840c22807eafb3fb2fd595b8519c92501623d06b Mon Sep 17 00:00:00 2001 From: Hiroki SAKABE <hiroki.sakabe@icloud.com> Date: Sun, 2 Aug 2026 00:55:32 +0900 Subject: [PATCH 5/7] fix: require exclusive worktree ownership --- skills/worktree-start/SKILL.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/skills/worktree-start/SKILL.md b/skills/worktree-start/SKILL.md index 16b4a6d..29ea824 100644 --- a/skills/worktree-start/SKILL.md +++ b/skills/worktree-start/SKILL.md @@ -106,7 +106,7 @@ issue URL / 番号が渡された場合は、本 skill 側で `gh issue view --c - **issue 入力から**: issue title から同形式の slug を生成し、末尾に `-<issue 番号>` を付与する。issue とブランチを後から照合できるようにする狙い。 - 例: issue #42「Slack 連携の OAuth フロー」 → `slack-oauth-flow-42` - **ユーザー明示指定**: 「ブランチ名は `xxx` にして」と渡された場合は LLM 命名を行わずそのまま採用する。 -- Claude Code の既定では `.claude/worktrees/<name>/` に `worktree-<name>` branch が作られる。この命名をそのまま許容する。既存名を再利用すると、状態に応じて既存 worktree が開かれるため、呼び出し前に `git worktree list` で意図した対象か確認する。 +- Claude Code の既定では `.claude/worktrees/<name>/` に `worktree-<name>` branch が作られる。この命名をそのまま許容する。既存名を指定すると既存 worktree が開かれる場合があるため、呼び出し前に `git worktree list` を確認する。runtime / session 文脈から現在の worker 専用と確認できる場合だけ再利用し、排他的な割り当てを確認できない場合は共有せず、衝突しない別名をユーザーへ求める。 ### 4. `EnterWorktree` の呼び出し @@ -157,6 +157,7 @@ step 2 で **issue URL / 番号 + `Status: Ready` + コメント上の未解決 - **切り替え後も linked worktree と確認できない**: 実装を開始せず停止し、`git worktree list` と Claude Code のエラーを確認する。既存 worktree ならその path で `claude` を開始し直す方法も案内する。 - **git リポジトリ外で呼ばれた**: `git rev-parse --is-inside-work-tree` で先に検知し、git repo 内で再実行するようユーザーへ案内する。 - **ブランチ名衝突**: `EnterWorktree` 側のエラー出力をそのままユーザーに見せ、別のブランチ名を提示してもらう（自動でサフィックス付与等は行わない。意図しない命名を避けるため）。 +- **既存名が別 session / worker に使用されている、または排他的な割り当てを確認できない**: その worktree を開かず停止し、衝突しない別名をユーザーへ求める。同じ worktree を複数の書き込み session で共有しない。 ## やらないこと From 020dac7a1f41f134a296fee931db42713d5d291b Mon Sep 17 00:00:00 2001 From: Hiroki SAKABE <hiroki.sakabe@icloud.com> Date: Sun, 2 Aug 2026 00:57:26 +0900 Subject: [PATCH 6/7] fix: bind reused worktrees to current task --- AGENTS.md | 2 +- README.md | 2 +- skills/issue-implement/SKILL.md | 2 +- skills/worktree-start/SKILL.md | 3 ++- 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index e7ec51e..587364f 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -64,7 +64,7 @@ These strings are not localizable in the current implementation. Forking is requ `issue-implement` step 4 is a mandatory isolation preflight. It resolves the default branch dynamically, checks `git rev-parse --git-common-dir` against `--git-dir`, and classifies the runtime/location before any implementation write or commit: -- A linked worktree continues without double creation. A non-default feature branch is preserved for a single implementation. A main working tree in detached HEAD stops as unclassifiable; a runtime-owned detached HEAD linked worktree (such as Codex App) is allowed. +- A linked worktree dedicated to the current issue/task continues without double creation. A worktree assigned to another task, or with unverifiable assignment, stops. A non-default feature branch is preserved for a single implementation. A main working tree in detached HEAD stops as unclassifiable; a runtime-owned detached HEAD linked worktree (such as Codex App) is allowed when its current-task assignment is established. - A write-capable parallel worker is evaluated first and requires **one worker = one worktree** even if it is already on a feature branch. Continue only when runtime/session context establishes that the linked worktree is dedicated to that worker; otherwise stop. - Default-branch execution must move to a dedicated worktree or stop before implementation. There is no skip-and-continue path. - Codex CLI stops and instructs the user to run ordinary `git worktree add`, then `codex -C <path>` in a new session. The running session is not assumed to migrate cwd. diff --git a/README.md b/README.md index 4c550a6..195d6a6 100644 --- a/README.md +++ b/README.md @@ -108,7 +108,7 @@ issuekit ships eight skills under `skills/`: ## 🌳 Worktree isolation -Before `issue-implement` writes files or commits, it classifies the current location as a linked worktree, a non-default feature branch, or the repository's default branch. An existing linked worktree is reused without creating another one. A single implementation on an existing feature branch is also preserved. A write-capable parallel worker is evaluated first and is stricter: **one worker must have one dedicated worktree**. If exclusive assignment cannot be established from runtime/session context, the worker stops instead of assuming a linked worktree is safe. +Before `issue-implement` writes files or commits, it classifies the current location as a linked worktree, a non-default feature branch, or the repository's default branch. An existing linked worktree dedicated to the current issue/task is reused without creating another one; a linked worktree assigned to another task, or with unverifiable assignment, is not reused. A single implementation on an existing feature branch is also preserved. A write-capable parallel worker is evaluated first and is stricter: **one worker must have one dedicated worktree**. If exclusive assignment cannot be established from runtime/session context, the worker stops instead of assuming a linked worktree is safe. [Codex subagent workflows](https://learn.chatgpt.com/docs/agent-configuration/subagents) are available in the CLI, IDE extension, and App, but orchestration does not itself isolate file writes. Keep parallel exploration and review read-only where possible; if multiple workers write, assign each worker a separate worktree. diff --git a/skills/issue-implement/SKILL.md b/skills/issue-implement/SKILL.md index bc1f11b..0ebf9c2 100644 --- a/skills/issue-implement/SKILL.md +++ b/skills/issue-implement/SKILL.md @@ -103,7 +103,7 @@ fi ここに到達した時点で、対象 issue は step 1 を通過した `Status: Ready` + 完了形 `PR` である。Draft / フォーマット不完全 / コメント上の未解決事項 / コメント完結型 / 要確認はすでに停止済みである。 -分類後は次の表を **上から順に**評価する。ここでいう「専用 worktree」は `GIT_COMMON_DIR` と `GIT_DIR` が異なるだけでなく、runtime の session / worker 情報または呼び出し文脈から、その worker に排他的に割り当てられたと確認できる linked worktree を指す。専用か確認できなければ共有されている可能性があるため停止する。 +分類後は次の表を **上から順に**評価する。ここでいう「専用 worktree」は `GIT_COMMON_DIR` と `GIT_DIR` が異なるだけでなく、runtime の session / worker 情報、branch / path、または呼び出し文脈から、その worker と対象 issue / task に排他的に割り当てられたと確認できる linked worktree を指す。現在の対象への割り当てを確認できない、または別 task 用なら停止し、別 worktree で再開する。 | 現在位置 / 呼び出し方 | 判定 | | --- | --- | diff --git a/skills/worktree-start/SKILL.md b/skills/worktree-start/SKILL.md index 29ea824..854b2ab 100644 --- a/skills/worktree-start/SKILL.md +++ b/skills/worktree-start/SKILL.md @@ -78,7 +78,7 @@ issue URL / 番号が渡された場合は、本 skill 側で `gh issue view --c - **上流 `issue-implement` からの slug / タスク説明**: worktree 切り替えだけを skip して呼び出し元へ戻る。上流はその worktree で実装を続ける。 - **直接渡されたタスク説明**: worktree 切り替えだけを skip し、この worktree で次に何をするか確認して終了する。 -- **直接渡された issue URL / 番号**: step 2 の Status / コメント / 完了形確認へ進む。step 3 / 4 の作成は skip し、Ready なら step 5 で対応 orchestrator へ引き継ぐ。Draft / 表記なし / blocker ありなら step 6 の報告へ進む。 +- **直接渡された issue URL / 番号**: runtime / session 情報、現在 branch / path、または呼び出し文脈から、この worktree が対象 issue に専用割り当てされていると確認できる場合だけ step 2 の Status / コメント / 完了形確認へ進む。step 3 / 4 の作成は skip し、Ready なら step 5 で対応 orchestrator へ引き継ぐ。別 issue 用、または割り当てを確認できない場合は連鎖せず停止し、対象 issue 用の別 worktree で再開するよう案内する。 判定は以下のいずれかで行う: @@ -158,6 +158,7 @@ step 2 で **issue URL / 番号 + `Status: Ready` + コメント上の未解決 - **git リポジトリ外で呼ばれた**: `git rev-parse --is-inside-work-tree` で先に検知し、git repo 内で再実行するようユーザーへ案内する。 - **ブランチ名衝突**: `EnterWorktree` 側のエラー出力をそのままユーザーに見せ、別のブランチ名を提示してもらう（自動でサフィックス付与等は行わない。意図しない命名を避けるため）。 - **既存名が別 session / worker に使用されている、または排他的な割り当てを確認できない**: その worktree を開かず停止し、衝突しない別名をユーザーへ求める。同じ worktree を複数の書き込み session で共有しない。 +- **現在の linked worktree が別 issue / task 用、または対象への割り当てを確認できない**: 直接渡された issue の orchestrator へ連鎖せず停止し、対象 issue 用の別 worktree で再開するよう案内する。 ## やらないこと From 221bf2307e272198741029381f30a36d00f96117 Mon Sep 17 00:00:00 2001 From: Hiroki SAKABE <hiroki.sakabe@icloud.com> Date: Sun, 2 Aug 2026 00:58:05 +0900 Subject: [PATCH 7/7] fix: clarify linked worktree routing guard --- skills/worktree-start/SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/skills/worktree-start/SKILL.md b/skills/worktree-start/SKILL.md index 854b2ab..bc7cfe5 100644 --- a/skills/worktree-start/SKILL.md +++ b/skills/worktree-start/SKILL.md @@ -162,7 +162,7 @@ step 2 で **issue URL / 番号 + `Status: Ready` + コメント上の未解決 ## やらないこと -- **既に worktree 内にいる session の別 worktree への移動**: primitive が可能でも、上記 step 1 で worktree 作成だけを issuekit 固有の no-op とする。直接 issue 入力の Status・完了形確認と対応 orchestrator への連鎖までは止めない。 +- **既に worktree 内にいる session の別 worktree への移動**: primitive が可能でも、上記 step 1 で worktree 作成だけを issuekit 固有の no-op とする。直接 issue 入力は、現在の worktree が対象 issue 専用と確認できる場合に限り、Status・完了形確認と対応 orchestrator への連鎖を続ける。 - **外部タブ / ペインの自動起動**: 並列タブの起動はユーザー操作のまま。skill から外部のターミナルマルチプレクサ等を直接操作しない。 - **Draft / フォーマット不完全 / 完了形が要確認な issue の着手連鎖**: worktree 作成までで止め、`issue-refine` を案内する。Status と完了形は `issue-create` の定義に従う。 - **タスク説明 (issue なし) 入力時の着手 orchestrator 連鎖**: issue 番号が文字列として登場しても、URL / 番号として明示入力されていなければ `gh issue view` を呼ばずタスク説明として扱う。連鎖は行わない。