read-github-issue

name	read-github-issue
description	GitHub Issueの内容を取得し、並列実行可能な単位に分解します。
argument-hint	[issue-number]
model	sonnet
effort	high
context	fork

Read GitHub Issue

GitHub Issue $1 を読み取り、後続フェーズが機械的に扱える形へ構造化して返すスキル。 推測で穴埋めせず、Issueに書かれている事実と、書かれていない不確実性を分けて返すこと。

呼び出し側への必須ルール: 本スキルを絶対にバックグラウンド実行しないこと。Agent ツール経由で呼び出す場合は 既定が run_in_background: true（バックグラウンド） のため、必ず run_in_background: false を明示指定 すること。Skill ツール経由の場合も run_in_background: true を指定してはならない（既定は同期）。呼び出し元は本スキルの構造化サマリ（手順3の返却フォーマット）を同期的に受け取って初めて後続のタスク実行・並列実装フェーズに進める設計であり、バックグラウンド化すると分解結果を待たずに制御が戻って後続処理が空振りする。他スキル（create-issue / create-plan / exec-issue 等）や上位エージェントから呼ぶ際もこの制約を守ること。

Instructions

実行モードの制約

本スキルは context: fork のサブエージェントとして起動されるが、内部で呼び出す Bash・Skill・Agent も絶対にバックグラウンド実行しないこと。

• Bash に run_in_background: true を指定しない。既定の同期実行（フォアグラウンド）でstdoutを受け取ってから次の処理に進む
• コマンド末尾に & を付けない。nohup / disown / setsid 等でのデタッチも禁止
• Agent ツールは既定が run_in_background: true（バックグラウンド）。呼び出しごとに 必ず run_in_background: false を明示指定 し、フォアグラウンドで同期的に結果を受け取ってから次の処理に進む。指定を省略した場合はバックグラウンドで走り、本スキルが未完のまま終了する。手順2で並列起動する Explore サブエージェントも、同一メッセージ内で並列に投げるだけであり「バックグラウンド」ではない（各 Agent 呼び出しは run_in_background: false で個別発火する）
• Skill にも run_in_background: true を渡さない（既定は同期）
• ScheduleWakeup 等で処理を後回しにしない。呼び出し元は本スキルの返却値を同期的に受け取る前提で待機している

理由: 本スキルは「Issueを分解した構造化サマリ」を同期返却する契約であり、バックグラウンド化するとサマリ生成前に制御が戻り、後続のタスク実行が空振りするため。

1. Issueと付随情報の取得

本文・状態・ラベルをまとめて取得する。コメントは取得しない（本文のみを分析対象とする）。

gh issue view $1 --json number,title,state,labels,assignees,milestone,url,body

以下も併せて確認：

• 画像/添付: 本文に画像URLがある場合、gh-asset でダウンロードして内容を読む

  gh-asset download <asset_id> ~/Downloads/
  

  参考: https://github.com/YuitoSato/gh-asset
• リンクされたIssue/PR: #123 形式や URL での参照は依存関係の手がかり。必要に応じて gh issue view <num> / gh pr view <num> で内容を確認
• コード参照: 本文に登場するファイルパス・関数名は対象範囲特定の起点。実際の所在・周辺実装の確認は手順2で Explore に委譲する

Issueが CLOSED の場合、その旨を明記してそのまま返す（タスク分解は行わない）。

2. タスクの分解

Issueから「やるべきこと」を抽出し、並列実行可能な単位に分解する。

Issue本文だけでは「どのファイルを触るか」「タスク間でファイルが衝突するか」を正確に判断できないため、コードベースの調査は Explore サブエージェントに委譲する。Issueに登場するファイルパス・関数名を起点に、関連実装・呼び出し元・テストの所在を Explore に特定させ、その結論をもとに各タスクの対象範囲と衝突可能性を確定する（自前で Read を繰り返すより、ファイル横断の fan-out 探索を一度に行える Explore の方が速く正確なため）。調査観点が独立する場合は、複数の Explore を同一メッセージ内で並列に起動して待ち時間を圧縮する。Explore は読み取り専用でコードの所在特定に特化しており、タスクの切り分け判断そのものは本スキル側で行う。

1タスクの粒度

1タスク = 「1つのサブエージェントが自己完結して完了条件まで到達できる作業」。 大きすぎる場合は分割し、小さすぎる（変更1行など）場合はまとめる。

逐次にすべき条件（いずれか該当 → 同一グループで逐次）

• 同じファイル/同じ関数を編集する可能性がある
• 一方の出力（型・関数シグネチャ・スキーマ・APIレスポンス）に他方が依存する
• DBマイグレーションやスキーマ変更を含む（変更を確定させてから利用側を直す）

上記に該当しないタスクは 並列グループ にまとめる。

各タスクに必ず含める情報

• 目的: なぜこのタスクが必要か（Issueのどの記述に対応するか）
• 対象範囲: 編集可能なファイル/ディレクトリの具体パス
• 完了条件: Issueの受け入れ基準から導いた検証可能な条件。書かれていない場合はその旨を明記
• 触れてはいけないファイル: 並列実行する他タスクが触る予定のファイル

スキル実行ステップの識別

実装プランのステップの中で、「特定のスキル（base-tools/skills/○○/SKILL.md）の実行を要求するもの」は、通常タスクと分けてスキル実行ステップとして明示的に扱う。呼び出し元（exec-issue 等）はこれを見て、サブエージェントへの委譲ではなく Skill ツールで直接発火する経路に振り分ける（サブエージェントに委譲するとスキル固有の副作用 — フック・ガードレール・PR作成・ラベル遷移・スナップショット出力等 — が保証されないため）。

以下の兆候をもつステップが該当する：

• ステップ本文または受け入れ基準に「○○スキルを実行する」「/○○ を呼ぶ」「base-tools/skills/○○/SKILL.md を発火する」等の明示的な呼び出し指示がある
• ステップの完了条件が「スキル固有の副作用（PR作成・ラベル遷移・スナップショット出力・フック実行等）」を要求している
• ステップ名または目的が既存スキル名と一対一で対応する（例: 「PRを作成する」→ create-pr、「コミットしてpushする」→ commit-push）

該当するステップは通常タスクの並列/逐次グループから除外し、返却フォーマット（手順3）の「## スキル実行ステップ」セクションに集約する。各ステップに以下の情報を保持する：

• 呼び出すべきスキル名（base-tools/skills/○○/SKILL.md のディレクトリ名、または frontmatter の name）
• 引数（Issue番号・ブランチ名・PR番号など。存在しなければ「なし」と明記）
• 依存関係（先行タスク・先行スキル。並列実行可否の判定に使う）
• 判定根拠（なぜスキル実行ステップと判定したか。「明示指示あり」「副作用要件」等を1行で）

判定が微妙な場合は、「スキル実行ステップ候補」として通常タスクとは別に列挙し、呼び出し元で最終判定できるように判定根拠と判定に迷った理由を添える（推測で通常タスクに寄せない）。

3. 返却フォーマット

以下の構造で返却する。呼び出し元はこの構造に依存するため、セクション見出しを変えないこと。

## Issue概要
- Number: #<番号>
- Title: <タイトル>
- State: <OPEN/CLOSED>
- URL: <URL>
- 目的/背景: <1-3行の要約>
- 受け入れ基準（Issue記載の原文 or 要約）:
  - <条件1>
  - <条件2>

## 分解タスク一覧

### 並列グループA
- **task-a1**: <タスク名>
  - 目的: ...
  - 対象範囲: `path/to/file`, `path/to/dir/`
  - 完了条件: ...
  - 触れてはいけないファイル: ...
- **task-a2**: ...

### 逐次グループB（task-b1 → task-b2 の順）
- **task-b1**: ...（先行）
- **task-b2**: ...（task-b1 の出力に依存）

## スキル実行ステップ
（該当するステップがなければ「該当なし」と明記）

- **skill-step-1**: <ステップ名>
  - 呼び出すべきスキル: `<スキル名>`（例: `commit-push`, `create-pr`）
  - 引数: `<引数>`（例: Issue番号 `$1`。なければ「なし」）
  - 目的: ...
  - 完了条件: ...（スキル固有の副作用が発生していることを含める）
  - 依存関係: <先行タスク・先行スキルがあれば列挙。なければ「なし」>
  - 判定根拠: <なぜスキル実行ステップと判定したか。「明示指示あり」「副作用要件」等を1行で>

### スキル実行ステップ候補（判定が微妙なもの）
（該当なしなら「該当なし」と明記）

- **skill-candidate-1**: <ステップ名>
  - 呼び出す可能性のあるスキル: `<スキル名>`
  - 判定に迷った理由: <本文が曖昧／副作用要件がスキル固有か通常タスクでも満たせるか判別不能／等>
  - 呼び出し元への申し送り: <どちらに寄せるかを最終判定するための追加情報>

## タスク間の依存関係
- 並列グループA と 逐次グループB は独立 / Aの完了後にBを開始 など
- 図示が有用な場合は箇条書きで「X が Y に依存」と明記

## 参考情報
- Issue: <URL>
- 関連Issue/PR: #..., #...
- 画像/添付: ローカルパス
- コード参照: `path/to/file:line`

## 不確実性・確認事項
（Issueから判断できなかった点。空配列でもよい）
- <仕様が曖昧な点。どう解釈して進めるかの提案を添える>
- <受け入れ基準が不明な点>

不確実性セクションは、推測で埋めずに「決めきれない箇所」を明示するのが目的。 呼び出し元はここを見て、ユーザー確認の要否を判断する。