Smithery is now a part of Arcade.dev! Read more in our announcement here
Issueの調査から実装完了までを一貫して対応
/issue-handle 99 # Issue番号、現在ブランチをベース
/issue-handle --file spec.md # ファイル
/issue-handle 99 --worktree # Issue番号 + worktree で隔離（並列開発時）
/issue-handle --file spec.md --worktree # ファイル + worktree
/issue-handle 99 --base develop --worktree # ベースブランチを明示指定
!gh issue view $0 --json title,body,labels,assignees,comments 2>/dev/null || echo "Issue情報の取得をスキップ（--file指定時）"
!ccx issue tree $0 2>/dev/null || echo "Issue階層の取得をスキップ（--file指定時、または取得失敗 — Issue番号指定時は要件確認で再実行する）"
<issue-number>: 対応するIssue番号（--fileと排他）--file FILE_PATH: 仕様ファイルのパス（<issue-number>と排他）--base BRANCH: ベースブランチを明示指定。省略時は起動時の現在ブランチ--worktree: 実装作業を専用の git worktree で隔離（並列開発時に推奨）。手順は references/worktree.mdgh CLIがインストール・認証済みであること--base BRANCH で明示指定 or 省略時は起動時の現在ブランチ--worktree 指定時: worktree はベースブランチ（origin/<base> 優先）から作成し、メインツリーの現在ブランチ・dirty 状態に依存しないgh issue view <issue-number> --comments）Issue と PR の対応は、Skill ツールで github-sub-issues を起動し、その「運用規約」に従う。親本文の節をキーで引く手順は同スキルの「本文の節の読み取り」に従う。起動時に取得した ccx issue tree の出力の kind で分岐する（出力の読み方は ccx issue tree --help）。取得できていなければ ccx issue tree <issue-number> を実行する。本節と references/parent.md が実行する ccx issue tree はいずれも、非ゼロ exit したら stderr を提示して停止する（取得できなかった分岐を飛ばして進めない）。warnings[] が空でなければ内容を報告し、以下の自動判定に頼らずユーザー確認へ倒す。
standalone: 単独の Issue として進めるsub（親あり・Sub なし）: 実装対象。以下を要件確認に加えるgh issue view <parent.number> --comments で親の本文・コメントを取得し、親の横断ルール・確定事項を本 Issue の要件と同格に扱う（運用規約「仕様の配置」）release_manual_steps 節（github-sub-issues の「本文の節の読み取り」の手順で引く）から PR で閉じてよい（「なし」マーカー）/ PR で閉じない（作業あり）を決めて計画ファイルに記録する（下記「計画完了」）。節が無い親は、この時点で all_siblings_closed: true なら推定 + 推奨を添えて AskUserQuestion で確認し、そうでなければ 未確定 と記録して PR 作成時に持ち越すblocked_by[]（運用規約「Sub 間の順序」）。open の blocker があれば、その旨と影響（ベースブランチに依存先の PR head を使う stacked 構成になり、依存先マージ後に PR の base を付け替える必要がある）を示し、AskUserQuestion で続行可否とベースブランチの選択を確認する。続行時の選択を Step 1 のベースブランチに反映する。停止はしないsame_repo: false か、gh issue view <blocker.url> --json closedByPullRequestsReferences が空かblocked_by が空 = 依存が 1 件も登録されていない → 散文へフォールバックする（運用規約の例外）。本 Issue の depends_on 節（または親の composition 節。いずれも同手順で引く）にある先行 Sub が siblings[] で open かを見るparent / parent_and_sub（Sub あり）: 実装対象ではない。references/parent.md に従う（着手可能な Sub の提示、または親の充足検証 → close）以下は Plan モード移行前に必ず実行する。--worktree 指定時は Step 0-7 すべて、非 --worktree 時は Step 0/1/2/7 のみ実行（Step 3-6 はスキップ）。
--worktree 指定時は、Step 0 の前に references/worktree.md を読む（以降のステップの行では読み直さない）。
Step 0. 要件確認・調査（最小限）
!gh issue view で取得済み）を読み、続く Step 4 の worktree 名（type + description）判断に必要な範囲で関連コードを Read/GrepisMinimized: true）は読み飛ばすStep 1. ベースブランチの確定
--base BRANCH 指定時: その値を使用git branch --show-current の値を使用Step 2. リモート最新化: git fetch origin <base-branch> を常に実行
Step 3. 既存 worktree の残骸判定（--worktree 指定 & Issue番号指定時のみ）
Step 4. worktree 名確定（--worktree 指定時のみ）
<type>/<issue-number>-<description>--file 指定時）: <type>/<description>add-, update-, remove-, refactor- 等）null-pointer, race-condition 等）feature/99-add-oauth-login, fix/42-null-pointer, feature/add-login-validation（--file 指定時）/ を - に置換した sanitized 形式（例: feature/99-add-oauth-login → feature-99-add-oauth-login。worktree-resolution の「共通規約」）Step 5. worktree 作成（--worktree 指定時のみ）
Step 6. EnterWorktree 実行（--worktree 指定時のみ）
Step 7. EnterPlanModeツールでPlanモードに移行（auto mode中でも必ず実行。/issue-handle の明示的な呼び出しが「explicitly asks」を満たす）
計画ファイル（Planモード開始時に指定されたパス）に実装方針を記述する。
--worktree 指定時: 冒頭で references/worktree.md の「Planモード内」に従って報告する。
参照文書の読込
ccx plan docs を、Issue の affected_code 節が挙げるパスを引数にして実行する（出力の読み方は ccx plan docs --help）。渡すのはバッククォートで囲まれたパスだけにする。--file 指定時は仕様ファイルが挙げるパスを同じ形で渡すloaded[] と documents[] の両方が空なら、この読込は対象なしとして飛ばすdocuments[] の各パスを Read で読み、warnings[] の各項目を報告して続行する（loaded[] は読み直さない）ユーザーとの対話
計画完了
PR で閉じてよい（release_manual_steps が「なし」マーカー、または節なしでユーザーが可と回答）/ PR で閉じない（手動作業あり、またはユーザーが否と回答）/ 未確定（節なしで他の Sub が open のため未確認）--worktree 指定時 true）--worktree 指定時のみ。Step 4 の sanitized 名）git log / gh pr list --limit 5、コードコメントは既存コードのコメント）:--worktree 時のみ）/simplify で品質チェック・修正Closes #<issue-number> を含める。Sub の場合は Part of #<parent> と、最後の Sub なら親の Closes も — 実装完了処理の規則に従う）/deep-review 実行（subagent_type: "independent-reviewer" のサブエージェント経由）→ 親で自動修正 → プッシュがあれば同じレビュアーへ 1 回差し戻して再レビュー・修正check-plan-compliance を引数 --no-exit で起動するccx plan check <計画ファイルパス> を実行する(new) または （新規） を注記する / コマンドを実行して結果を記録する（実行できないなら理由を記録する。形式は ccx plan check --help）。直したら再実行し、clean になるまで繰り返すdeep-plan-review を起動する（引数: 計画ファイルパス）ExitPlanMode は deep-plan-review だけが呼ぶ。本スキルは finding が残っていても呼ばない実装フェーズへ（承認後）
開始前の同期点: deep-plan-review の承認後の同期点が完了して同スキルが返るまで、以下のステップを 1 つも開始しない。同期点で「打ち切り」が選ばれた場合は本 run をそこで終え、この時点で作られているもの（worktree・ブランチ・計画ファイル）はそのまま残す。
作業ブランチ確定
--worktree 指定時: 本ステップ全体をスキップして次のステップへ--worktree 時のみ以下を実施:--file 指定時の分岐を含め、すべて --worktree 有無に関わらず共通）git switch -c feature/99-xxx origin/<base-branch>（事前準備の fetch 成功時）git switch -c feature/99-xxx <base-branch>（fetch 失敗時のフォールバック）実装・テスト修正
test-implementation を起動し、その3原則に従うgit-commit を起動して行うTest, Lint成功確認
run_in_background: true で実行make all, npm test && npm run lint, go test ./... && golangci-lint run品質チェック
/simplify を実行し、変更コードの再利用性・品質・効率性を確認・修正model を指定せず（親継承）、isolation: "worktree" で隔離し、4 角度（reuse / simplification / efficiency / altitude）を 4 エージェントのまま起動する。diff が小さいことを理由に角度を統合・削減しない（角度の構成が変わっていたら組み込み側が正で、統合・削減しない点だけが不変）finding-severity を起動し（写像: /simplify の finding = 推奨修正）、その「判断基準」と「対応リストの出力」に従って対応リストを出す。「Issue 側の修正が要る指摘」が空でなければ references/issue-conflict.md を読んでユーザーに確認し、回答で適用する指摘を「対応する指摘」へ、適用しない指摘を「対応しない指摘」へ移す。そのうえで区分を下記の一覧の扱いへ移す: 「対応する指摘」→ 適用、「対応しない指摘」→ 見送り/simplify の要約には、各角度が返したすべての finding を 1 件 1 行で、次の扱いのいずれか 1 つとともに列挙する（列: finding / 角度 / 扱い / 根拠）。一覧はステップ5の開始前に完成させる/simplify の要約とユーザーの回答はターンの終わりではない。finding の一覧の完成と修正のコミットまで済ませたら、それ以上のユーザー確認を待たず同一ターンでステップ5へ進む実装完了処理
git-commit を起動してコミットgit-pr を引数 --draft --base <base-branch> で起動し、プッシュ・PR作成を行う（<base-branch> は計画ファイルに記録したベースブランチ。Ready 化は 6-5 のみが行う）Closes #<issue-number> を含めるPart of と親の Closes を書く。PR 作成直前に ccx issue tree <issue-number> を再実行し、その値と計画の親 close 方針で判定する。方針が 未確定 なら、ここで親本文からの推定と推奨を添えて AskUserQuestion で確認してから決める。warnings[] が空でなければ Closes #<parent> は付けず、その旨を報告するgh pr view --json number,isDraft と gh repo view --json nameWithOwner -q .nameWithOwner で <pr-number> / <owner/repo> を確定し、6-1・6-5 でも取り直さず使い回す）:isDraft が false なら gh pr ready --undo <pr-number> -R <owner/repo> で draft に戻し、戻した旨を1行報告する（ユーザー確認は取らない）独立セッションでのレビュー → 親での自動修正
6-1. サブエージェントでレビュー実行
subagent_type: "independent-reviewer" のサブエージェントを起動する（model パラメータは指定しない）fork は使わないdeep-review を引数 <pr-number> --issue <issue-number> --no-autofix で起動すること<pr-number>: ステップ5で確定した PR 番号<issue-number>: Issue 番号（--file 指定時は --issue <issue-number> 部分を省略）--worktree は付けない6-2. 親セッションで自動修正
git rev-parse HEAD を控えるfinding-severity を起動し、その判断基準・対応リストの形式に従って対応要否を判断し、対応リストを出力するgit-pr を引数 --base <base-branch> で起動してプッシュ・PR更新git-pr）で反映する6-3. 同じレビュアーへの差し戻し
SendMessage で次を送る:<控えた HEAD>..<現在の HEAD> と、6-2 の対応リスト（対応する / 対応しない とその根拠。質問・確認事項への回答はその行に書き、ユーザー判断待ちのものはその旨を書く）deep-review を 6-1 と同じ引数で再度起動することSendMessage がレビュアーに届かない場合は、independent-reviewer を 6-1 と同じ指示で新規起動し、プロンプトに前回のレビュー結果・その時刻と上記 1・2 を加え、3 は「プロンプトで渡したレビュー結果を自分の過去レビューとして扱うこと」に読み替える6-4. 差し戻しの結果の処理
finding-severity・Issue 側の確認・分岐・ユーザーが求めた変更の反映）で処理する。時刻と HEAD は控え直さず、終えたら 6-5 へ進む6-5. PR を Ready 化
ccx pr ready <pr-number> を実行する（出力の読み方は ccx pr ready --help）status が ready / already_ready → PR が Ready である旨を報告するstatus → 落ちた検査と、PR が draft のまま残ることを報告して停止する以下をすべて満たした時点で完了:
/deep-review を実施し、結果を親セッションで表示済みindependent-reviewer）の再レビューを 1 回実施し、その結果を 6-4 で処理済み--worktree 指定時の前提・挙動: references/worktree.md の「注意事項」