fix-github-issue reference

fix-github-issue は、既存の GitHub Issue 1 件を実装し、検証、review、PR 作成まで進める skill です。

PR・GitHub reviewer・E2E の定型指定には fix-issue-preset を使えます。個別の指定で上書きでき、展開後はこの skill へ引き継ぎます。

対象読者と使いどころ

まず何が起きるか

1. Issue の担当者、依存関係、受け入れ条件、非ゴールを確認します。
2. 実装範囲と検証方法を決め、必要な場合だけユーザーに質問します。
3. 追加するファイルや処理を計画に列挙し、Issue の受け入れ条件や契約へ紐付けます。根拠のない追加物などがある場合だけ採否を確認し、実装、通常検証、PR 前 simplify へ進みます。
4. 指定された review を行い、PR を作成または更新して review と CI を確認します。
5. 指定された E2E を行い、結果を PR と完了記録へ反映します。

subagent への委譲

任意の委譲は、独立していて並列化できる大きな作業に限ります。数回の tool 呼び出しで終わる作業は直接処理し、探索ディレクトリ数だけでは委譲しません。基準の編集元は claude/CLAUDE.md の「Subagent 委譲」節です。

調査だけを任せる子と編集する子の責務を分け、同じファイルを競合して編集しないようにします。親は応答待ちの間も独立した許可済み作業を進め、子と同じ調査を繰り返しません。

ユーザーの明示並列実行 / Agent 指定と、skill が要求する独立 review / validation は維持します。利用不能時の停止条件や外部 AI 許可も変わりません。具体的な引き継ぎは共通手順に従います。

停止条件

• 別の担当者が claim 済み、または依存 Issue が未完了の場合。
• 受け入れ条件、非ゴール、公開 API、設定形式、画面上の挙動に複数の完了形がある場合。
• readiness gate、review、CI、E2E の required action が残る場合。
• Issue と linked Cosense design doc が矛盾する場合。
• dirty worktree や branch 衝突があり、安全に作業を続けられない場合。

標準規模の変更では、コードを書く前に implementation-plan.v1 で追加物を確認します。確認が必要なのは、根拠がない項目、禁止挙動に紐付く項目、Agent 判断による新しいファイル・option・error path、受け入れ条件に紐付かない公開宣言です。該当しなければ質問せず実装へ進みます。trivial の変更では計画を省略します。

採用を選んでも根拠の不足は免除しません。必要なら Issue を改訂し、計画の参照を更新します。実装中に計画外の新規ファイルが増えた場合も確認に戻ります。禁止挙動 section のない旧形式 Issue では、受け入れ条件と契約だけを参照します。

作業途中の仕様訂正

途中で条件を削除・置換したり、対象を狭めたりした場合は、Agent が新旧の要求と影響箇所を既存の作業記録へ残します。今回触った Issue / plan、実装、migration、テスト、コメント、PR説明を確認し、未反映と対象外を区別します。

Issue や design doc の外部更新が未許可なら、差分案と残件を報告して、許可済みの作業を続けます。PR本文の人手追記保護と、変更後の検証・レビュー証跡の更新規則は維持します。実行手順は共有契約を参照してください。

詳細 contract

人間判断 gate

• 既存回答と明示許可を同じ対象・操作・scope で再利用し、意味や範囲が変わる場合は再判断します。必要な回答を使用可能な入力手段で得て再評価が通れば、同一ターンでも続行します。詳細は共通の確認・停止条件を参照してください。
• human action が必要な場合は次の該当経路へ戻す。Issue 不明点 / drift 確認 の選択可能な項目は decision-doc の HTML レビューで確定し、readiness-checkpoint と implementation plan check の差分は項目ごとに 削除 / 採用 / Issue 改訂 から選びます(acceptance_diffs は採用を選べません)。Issue 改訂 / split / spike を要する項目と、E2E・PR mode・review profile の経路には使いません。RHW 未導入の環境と非対話 worker では質問を報告して停止します。

PR mode

• PR 作成後は最新 HEAD の review と CI を確認する。billing、runner、GitHub Actions service の障害は infrastructure failure として分けて報告する。
• PR 作成後に review / CI / E2E の結果で本文を変える場合は、update-pr skill を経由し、skill の外から review-orchestrator pr-publication update --body-file を直接実行しない。title-only 更新と、create-pr ステップ7 / update-pr フェーズ8 の body_findings[] 修正に伴う同一 body の再実行は例外とする。
• drift-check で「変更してはいけない契約」と受け入れ条件を確認する。unmet は required action とする。
• surplus[] は report_only の観測として残す。実装者の accepted / rejected は既存の record-action で記録する。手順と昇格条件は 余剰な追加物の観測 を参照する。
• design doc は作成時点のスナップショットとし、進捗と PR は GitHub Issue 側を source of truth とする。design doc 本文にも readability gate を適用する。

research packet

• packet が古い、複数ある、または対象 Issue と一致しない場合は自動採用しない。

design doc の記録

• Issue に design doc の実 URL がある場合は、repo-scoped record、flat compatibility record、page 本文の legacy record の順で authoring 記録を探す。
• 対象 Issue の record を先に探し、見つからない場合だけ Parent の共有 record を探す。flat record は repository、Cosense project、page title も一致する場合だけ使う。
• 同じ優先順位の候補が複数ある場合や記録同士が矛盾する場合は、readiness で停止する。
• Issue に design doc の実 URL がない場合は、flat record を推測で採用しない。
• 承認済みの省略理由には auto 判定と明示 off の省略を含む。auto 判定の省略理由は、満たさない作成条件を 1 行で列挙したものを受理する。
• Issue 本文は <details> 内の実装契約も旧形式（NOTE alert 境界より後）の領域も同じ契約 section として読み、## 見出しの契約 section があれば drift-check もどちらの形式にも実行する。

triage skip

• implementation brief が change_scale=trivial で、risk と未確定事項がない。
• acceptance、validation_commands、candidate_files がそれぞれ1件以上ある。
• Design doc section に実 URL または承認済みの省略理由がある。
• design doc を正当に省略した Issue に link は要求しない。
• 変更行数が 20 を超える（lines_added+lines_deleted<=20 を満たさない）、または変更ファイル数が 2 件を超える場合は通常の triage に戻る。
• readiness と drift 確認は省略しない。

review mode

local reviewer と GitHub reviewer

• agents= と reviewers= は別の selector とする。
• task ledger 開始時は pr_mode、review_mode、agents、e2e_mode、smoke_mode を同じ durable state revision に保存する。resume 時は保存済み selector を優先し、部分的な legacy state だけ不足分を補完する。
• implementation-status は live binding の再検証結果を selector backfill と同じ revision に保存してから判定する。selector mismatch または保存失敗時は後続へ進まない。
• issue completion-check は実行のたびに fix-code-comments の run record を照合し、comment-check-observation.v1 を state root の repository 単位 path へ保存して、stdout に summary を additive に含める。この観測は report_only で、required_action を追加せず完了判定と exit code を変えない。base は optional な --base-ref で明示でき、省略時は origin/main との merge-base を使う。
• PR 前 simplify commit 後、review / push / PR 作成の前に、各 implementation agent が非 test・非 generated Go の追加 hunk を確認する。理由、制約、外部契約をコードだけで残せない hunk にはコメントを書く。コメントを書いた場合は通常検証を再実行して commit し、commit 後の diff で行範囲を更新した comment-intent-input.v1 を review-orchestrator issue comment-intent record で記録する。修正で HEAD が変わった場合は再判定して再記録する。
• completion-check は comment_intent_check summary を追加する。record で --repo-remote を指定した場合、completion-check にも同じ値を渡す。record の欠落、HEAD 不一致、missing、stale、読み取りエラーは report_only であり、完了判定と exit code を変えない。
• review=once の agents= は codex、claude、copilot のいずれか 1 件だけを指定する。
• review=on で local reviewer と GitHub reviewer のどちらも実行できない組み合わせは停止する。
• no-copilot-bot は旧互換の Copilot bot opt-out とする。

E2E option

• e2e=final|both では、final E2E の成功またはユーザーが明示した skip がなければ完了扱いにしない。通常検証や review の成功は E2E の代わりにしない。
• e2e-apply=confirmed は handoff / checkpoint に保持し、resume command に e2e-apply=confirmed を復元する。
• 承認として使えるのは、ユーザーの直接入力と、その入力から同じ task 内で作成した handoff / checkpoint に限る。
• 単独の e2e_apply 値や handoff_context は承認根拠にしない。needs_user_decision として停止する。
• 未指定時は従来どおり実行前にユーザー確認する。

worktree option

• 既存 worktree を再利用する場合も、編集前に branch と clean state を確認する。

stacked PR の親

stack=<PR number|PR URL> は同じ repository の open PR を親として指定します。stack=auto または stack=true は、対象 Issue の親 Issue にある実装順序表と依存 Issue の PR から、親 PR が一意な場合だけ自動解決します。

解決した親 PR、base branch、base OID は worktree、review、PR 作成へ引き継ぎます。PR 作成直前に再検査し、親 PR の更新、複数候補、PR 未作成、fork、別 repository、既存 stack の途中への挿入が見つかった場合は停止します。

stack=auto は logical dependency PR と、検証済みの effective_tail_candidate を区別して返します。途中の sibling PR を観測しても legacy parent_pr_not_top を維持し、後続 coordinator が使う publication_order_snapshot、chain_root_status、stack_members を追加 evidence として残します。

publication coordinator を使う経路では、ready intent を凍結順に lease します。required mode は clean かつ未 push の branch だけを effective tail 上へ積み直し、restack 後の HEAD で validation、review、E2E をやり直します。conflict、tail drift、期限切れ、effect 不明では push せず、保存済みの resume または abort action に戻ります。

親 Issue の表が更新された場合は、未公開 intent の row と相対順を再確認します。相対順が同じなら snapshot と Phase を更新し、並び替えまたは row 消失なら publication_order_stale で lease と branch の変更前に停止します。

復旧するときは、親 Issue の表で元の相対順と欠けた row を復元してから、resolver と intent 登録をやり直します。順序変更を維持する場合は、既存 intent を resume または abort の手順で解決してから、新しい順序で登録します。

standalone の auto stack は、対象になる resolution を root owner の publication intent として登録します。commit 後に current branch と HEAD を ready にし、先行 intent がある間は status と heartbeat を続けます。順番が来たら prepare から同じ session で再開し、restack 後の HEAD が変わった場合だけ validation、simplify、review、E2E を再実行します。

計測と独立 review を通過したため、明示 stack=auto|true の publication gate と closing Issue gate は required です。generic resolver と selector 未指定経路の legacy 既定値は変更しません。

false stop、unsafe pass、duplicate publication、順序違反、closing Issue の誤停止または見逃しが 1 件でも観測された場合は、両 gate を report-only に rollback します。残存 publication intent は計測 artifact に記録して abort し、required registry へ持ち越しません。

required coordinator の worker は implementation と publication-finalization を分けます。implementation は commit までで止まり、finalization は保存済み intent から prepare を再開します。gate timeout は validation、simplify、review、E2E の有限上限を lease 用に合算するもので、gate 自体の実行時間を打ち切りません。

PR 作成前の再検査では legacy parent_pr_not_top artifact も読み直せます。ただし candidate の変化だけで resolved や stale に読み替えず、resolved artifact の parent PR、branch、OID が変わった場合だけ parent_pr_stale にします。

stack と stack-base は同時に指定できません。どちらも未指定なら default branch 起点の既存手順を維持します。

branch を直接指定する互換経路

stack-base=<branch> を指定すると、先に対象 branch を fetch し、origin/<stack-base> を worktree または branch の起点にします。同じ branch を review-profile-plan、local review、create-pr にも渡します。

既存 linked worktree は、clean で origin/<stack-base> が HEAD の祖先になっている場合だけ再利用します。条件を満たさない場合は、自動 rebase や追加 worktree の作成を行わず、必要な操作を案内して停止します。

関連: Issue workflow skill guide、task-research reference github-issue-breakdown からの review=once も単一Agent指定を保持する。Agent未指定は未指定のまま受け取り、直接実行と同じ runtime 別既定に従う。既存の model / effort 指定も再開時に引き継ぐ。