issue-looplisted

## Purpose GitHub issue 1 件を、shift-left 調査から振り返りまでの 10 ステップで対応する**プロジェクト非依存の** dev process。品質担保の核は (1) 設計前の独立インパクト調査、(2) 実装とレビューの文脈分離 (クリーンなサブエージェント)、(3) レビュー finding の独立検証 (メタレビュー)、(4) 振り返りによるチェックリストへのフィードバック。 ## 引数 issue 番号 or issue URL。省略された場合は対象 issue を確認してから開始する。 ## サブエージェント運用の原則 - 委譲先は常に**クリーンな Sonnet 5 (`claude-sonnet-5`) サブエージェント**。メイン loop (主担当) の仮説・文脈を持ち込ませないことで、確証バイアスを避ける。 - brief は本 SKILL.md のテンプレから生成する。**issue 番号と対象ファイルを埋めるだけで brief が完成する**状態を保つ。 - メイン loop は orchestration と判断に徹し、調査・実装・レビューの実作業はサブエージェントに出す。 - **バックグラウンドサブエージェントの orphan 防止**: バックグラウンド委譲したエージェントは、セッションがアイドル化 (ユーザー離席等) すると一緒に停止し、完了通知も失われうる。長時間 (数分超) のエージェントを起動したターンでは必ずフォールバックタイマー等の完了待ち機構を併設してセッションを起こし続けるか、同期実行にする。再開時に停滞を疑う場合は、経過時間ではなくトランスクリプトの更新時刻・サイズで「実働中 / 停止済み」を判別し、死んでいた場合は部分トランスクリプトから完了済みの検証結果を回収してから (全部やり直さず) 差分だけ再委譲する。委譲先が**さらに子エージェントへ再委譲して自分は停止する**ケースもある — その場合は委譲先へ追加メッセージを送って再開させ、「子の結果がもし揃っているなら統合、揃っていないならこれ以上再委譲せず自分で完遂」を指示するのが復旧の定石。API エラー (session limit 等) で途中死したエージェントは、リセット時刻を確認してから同一 brief で作り直してよい。 ## ユーザー判断のエスカレーション メイン loop が自律で下してよいのは**技術判断**まで。以下の 3 点は**ユーザー (プロダクトオーナー) の判断領域**であり、自律実行の明示的な許可 (「確認なしで進めて」等) がない限り、質問ツール等で確認してから先へ進む: 1. **設計選択 (Step 0)**: 実装方針の候補が複数あり trade-off が非自明な場合 (issue に複数案が併記されている場合を含む)。Step 0-pre report の要点と推奨案 + 根拠を添えて選択を仰ぐ。 2. **プロダクト意図の変更**: spec の要件文言の改訂、既存保証の縮小、既知限界の accept (修正せず文書化) など、機能の意図そのものに触れる判断。技術的整合性だけでは決められない。 3. **main への merge (Step 8)**: CI green と E2E 完了を確認した上で、merge 実行の**直前**に確認する。 確認時は、判断に必要な文脈 (選択肢 / 推奨 / 影響範囲) を質問自体に含め、ユーザーが過去ログ