Answer Issue Questions

Instructions

GitHub アクセス

本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。

本スキルの位置づけ（確認事項の回答責任はここにある）

triage-created-issue は確認事項の調査を行わず、未回答の確認事項を内容を問わず本スキルへ委任する。「gh コマンドだけでは答えが決まらない項目」が回るのは正常であり、それを理由に回答を放棄して人へ差し戻さない。コードベース・ドキュメント・.claude/requirements/・外部リンク（仕様書・ライブラリ公式ドキュメント・関連Issue/PR）まで調査し、事実で決まる項目は本スキルで決着させる。

調査を尽くしても事実で決まらず、人間の意思決定（優先度・ビジネス判断・不可逆な選択など）が必要な項目だけを、固定セクション ## 人間判断が必要な確認事項（自動回答不能） に列挙する。このセクションは triage-created-issue が cc-need-human-check を付与する唯一の根拠で、無ければ「全項目を回答済み」として後続フロー（cc-update-issue → 再トリアージ → 着手）へ進む。安易に列挙すると人の手が止まり、怠ると未決の判断が実装へ流れるため、後述の判定基準に厳密に従うこと。

実行モードの制約

本スキル固有のリスク: 本スキルは claude-task-worker の cc-answer-issue-questions ラベルをトリガーに自動起動され、ワーカーはスキルプロセスの同期完了を根拠に cc-answer-issue-questions の除去や cc-update-issue の付与を進める。処理が未完のままターンを終えると、回答コメントの投稿前に cc-update-issue が付与されて update-issue ワーカーが未反映のIssueをそのまま update してしまうなど、Issue のライフサイクルが壊れる。

Issue本文の方針・前提の尊重（回答スコープの制約）

本スキルの責務は「確認事項に答えること」であり、「Issueの方針自体を再審議すること」ではない。

• Issue本文（タイトル・概要・要件・実装プラン）が確定方針として示している事項（統合先・採用アプローチ・対象範囲・技術選定など、依頼者が所与として与えた判断）は動かせない前提として扱い、その前提の中で回答する
• 方針の変更提案、代替案（A案/B案などの選択肢）の提示、「方針確定をお願いしたい」といった人間への意思決定の差し戻しを回答に含めない
  • 例外は ## 人間判断が必要な確認事項（自動回答不能） セクションだけ。確認事項として明示的に問われている項目が、調査を尽くしても事実でも Issue 本文の前提でも決まらない場合に限り列挙してよい（判定基準は「人間判断が必要と判定してよい条件」を参照）。これは「問われた確認事項に答えられなかった」ことの申告であり、問われていない方針を再審議する口実にはならない。回答本文（## 回答 の各項目）側には方針の再審議・代替案の列挙を書かない
• 調査の過程で前提と矛盾する事実（例: 前提と逆方向の実装状況・コスト差）を発見した場合は、握りつぶさず回答末尾に「参考: 前提に関わる調査結果」として事実のみを記載する。方針転換の推奨や選択肢の列挙へ展開せず、重大と考える場合も「前提の再検討は別Issueとして起票を推奨」と1行添えるに留める

理由: 回答コメントは後続の update-issue が description へ反映する入力になる。回答が方針を再審議すると、人間が与えた方針がAIのコメントで上書きされ、着手できたはずのIssueが「方針確定待ち」に差し戻される。

回答スコープと分量の規律

回答コメントは人間が読み、update-issue が description へ取り込む成果物。問われたことに答える分量に収める。

• 確認事項に列挙されていない論点を足さない: 調査中に気づいた別の懸念や、問われていない設計の是非を書かない
• 1確認事項あたり結論1〜3行 + 根拠を基本形にする。言い換え・埋め草・定型の前置きを書かない。「リスク・注意点」「推奨アクション」は該当がある場合のみ書き、無ければ節ごと省略する（「特になし」の行も不要）
• 根拠は path:line の引用（外部情報なら URL と要点）で足りる。コードの長大な貼り付け・リンク先の全文転記・調査経過の逐次記録は載せない
• 最終報告（Slack通知に載る）は結論から1〜3行で書く。回答本文の再掲はしない

入力

• Issue番号: $0

実行ステップ

ステップ1: Issueとコメントの取得・確認事項の収集

GitHub MCP が使える場合は issue_read（method: get。コメント取得は get_comments）を使う。以下は MCP 利用不可時のフォールバック。

gh issue view $0 --json number,title,body,labels
gh issue view $0 --json comments --jq '.comments[-1]'
gh issue view $0 --json comments --jq '.comments[] | select(.body | test("## 確認事項|## 回答")) | {createdAt, body}'

確認事項は2箇所から収集し、両方を回答対象にする。

1. 最後のコメント: ## 確認事項 セクション、または箇条書きの問いかけ
2. description（Issue本文）: ## 確認事項 セクションのほか、「確認したいこと」「要確認」「TBD」「未確定」などの形で本文に残っている未確定項目。コメント側に確認事項が無くても description 側だけで対象が成立しうる
   • 実装プラン中の「〜を確認する」「〜を検証する」といった実行担当の作業手順は確認事項ではない。回答対象に含めない
   • description に既に回答・結論が併記されている項目は回答済みとして扱う
3. 回答済み判定: 過去の ## 回答 コメント、および人間のコメントで既に決着している項目は再回答しない（同じ問いへ二重に答えると update-issue が矛盾する記述を description へ取り込む）

両方の収集源を合わせても未回答の確認事項が1件も無い場合は、その旨を報告して終了する（回答コメントは投稿しない）。

ステップ1.5: ベースブランチ（調査のターゲットブランチ）の確定

回答の基準となるベースブランチ（BASE_BRANCH）を確定する。サブIssue（parent を持つIssue）の作業ブランチは cc-epic-<parent番号> から派生し実装PRもそこへ向くため、デフォルトブランチではなく epic ブランチが調査のターゲットになる。デフォルトブランチ基準では、epic ブランチへマージ済みの兄弟サブIssueの実装が「未実装」に見え、「Epic PR が未マージだがどうするか」といった本来不要な検討事項が回答へ混入する（exec-issue / create-pr と同じ確定的導出を用いる）。

parent の取得は Issue Dependencies（sub-issue）系のフィールドであり、MCP 側の対応が不定のため gh に据え置く（対応表の「gh のまま残す操作」参照）。

git fetch --prune || true

BASE_BRANCH=""
PARENT=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh issue-parent "$0") || PARENT="__unresolved__"
if [ "${PARENT}" != "__unresolved__" ] && [ -n "${PARENT}" ] \
  && git rev-parse --verify --quiet "refs/remotes/origin/cc-epic-${PARENT}" >/dev/null; then
  BASE_BRANCH="cc-epic-${PARENT}"
fi

# parent が無い場合は upstream（ワーカーが worktree 作成時に --track で記録した分岐元）を使う
if [ -z "${BASE_BRANCH}" ]; then
  CURRENT=$(git rev-parse --abbrev-ref HEAD)
  UPSTREAM=$(git rev-parse --abbrev-ref --symbolic-full-name '@{upstream}' 2>/dev/null || true)
  UPSTREAM=${UPSTREAM#origin/}
  if [ -n "${UPSTREAM}" ] && [ "${UPSTREAM}" != "${CURRENT}" ] \
    && git rev-parse --verify --quiet "refs/remotes/origin/${UPSTREAM}" >/dev/null; then
    BASE_BRANCH="${UPSTREAM}"
  fi
fi

if [ -z "${BASE_BRANCH}" ]; then
  BASE_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
fi
echo "BASE_BRANCH=${BASE_BRANCH} PARENT=${PARENT}"

git rebase / git pull は実行しない（本スキルはコードを変更しないため、同期に失敗しても中断せず続行する）。

以降のステップ2〜4は BASE_BRANCH を調査・回答のターゲットブランチとして扱う。

• 現在の作業ディレクトリのコード状態（＝BASE_BRANCH 由来）が調査対象。「この実装はデフォルトブランチにまだ入っていない」ことを問題として扱わず、回答の前提にもしない
• BASE_BRANCH が cc-epic-<N> の場合、Epic PR（cc-epic-<N> → デフォルトブランチ）が未マージであることは Epic フローの正常状態。これを根拠としたリスク・注意点・推奨アクション（「先に Epic PR をマージすべき」等）を回答に含めない
• epic ブランチへマージ済みの兄弟サブIssueの実装は「既に存在するコード」として扱い、根拠として引用してよい
• 未マージPRに言及する場合は base が BASE_BRANCH のPRだけを対象にする（GitHub MCP が使える場合は list_pull_requests / search_pull_requests を使う。利用不可時のフォールバックは gh pr list --state open --json number,title,baseRefName --jq ".[] | select(.baseRefName == \"${BASE_BRANCH}\")"）。base が異なるPR（Epic PR 自身など）は回答対象外
• parent の取得に失敗した場合（PARENT=__unresolved__）は parent 不明として続行するが、未マージPRを根拠とした回答・注意点は書かない（安全側の倒し方）。その旨は最終報告に1行残す

ステップ2: タスクの分析

確認事項の背景・目的・関連する仕様を把握するため、以下を読み込む。

• .claude/requirements/配下の要件ルール: 後述の「要件ルールの参照」に従う
• docs/配下のドキュメントファイル
• design/配下のPencilファイル（.pen）: inspect-pencil-node スキルで対象Nodeの属性データとスクリーンショットを取得する（.pen は平文JSONなので属性だけなら Read / jq でも読める。構造は ${CLAUDE_PLUGIN_ROOT}/references/pen-format.md）
• Issue本文・コメント・上記ドキュメントに現れる外部リンク: 後述の「外部リンクの参照」に従って内容まで読む

本スキルはコードを変更しない（コメント編集のみ）。回答過程で .pen の編集が必要と判明した場合も編集せず、回答内で「対応には <対象 .pen> の更新が必要であり、cc-create-ui-design のデザイン先行フローで行う」と明示する。.pen の新規作成・編集は同フローの専任であり、実装PR（exec-issue）では行わないため、実装セッションに .pen を編集させる回答は書かない。

外部リンクの参照（gh とローカルファイルで完結させない）

確認事項の答えがリポジトリの外（仕様書・API仕様・ライブラリ公式ドキュメント・別リポジトリのIssue/PR・デザインURLなど）にあることがある。gh とローカルファイルだけで調べて「確認できなかった」と返すと、リンク先に書いてある答えを人へ差し戻すことになる。リンク先の内容まで読んで回答を確定させる。

1. 収集: Issue本文・確認事項を含む全コメント・ステップ2で読んだドキュメント・ステップ3で調査したコードに現れる URL を洗い出す
2. 取捨選択: 全部は開かない。確認事項への結論が変わりうるリンクだけを対象にする（バッジ画像・ライセンス・無関係な記事は開かない）
3. 取得: 種類ごとに手段を使い分ける
   • 一般のWebページ・仕様書・記事 → WebFetch
   • ライブラリ/フレームワークの公式ドキュメント → check-library スキル（Next.js / shadcn / context7 MCP を使い分ける）。バージョン差のあるAPI仕様を検索結果の要約で代用しない
   • GitHub上のIssue・PR・ファイル（別リポジトリ含む） → GitHub MCP が使える場合は issue_read / pull_request_read（method: get）を使う。利用不可なら gh issue view / gh pr view / gh api へフォールバック（GitHubのURLは WebFetch より確実）
   • Figma URL → Figma MCP（mcp__claude_ai_Figma__*）
   • 画像・資料へのリンク → リンク先を開いて内容を確認する（Google Drive はドライブ用の MCP、それ以外は WebFetch。URLを見て終わりにしない）。Issue に直接添付された画像（user-images.githubusercontent.com / github.com/user-attachments/...）は bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh fetch-attachments <Issue番号> "$(mktemp -d)" でダウンロードしてから Read で見る（添付 URL を直接開かない。クラウドでは 403）。取得に失敗した場合は推測で埋めず「添付は取得不可（理由）」と根拠に明記する
   • リンク切れ・URLが古い → WebSearch で現行の一次情報を探す（見つからなければ深追いしない）
4. 深さの上限: リンク先からさらに辿るのは1段まで。それ以上は追わず、必要なら「確信度と追加調査の必要性」として回答に明示する
5. 記録: 判断に使ったリンクは回答の「根拠」に <URL> — <参照した要点> の形で残す（path:line の引用と同格の根拠として扱う）
6. 取得失敗: 認証必須・404・タイムアウトは1回だけ再試行し、それでも読めなければ推測で埋めず「<URL> は取得不可（理由）」と根拠に明記したうえで、確認済みの範囲で答えられる分を回答する

要件ルールの参照

.claude/requirements/ には、過去のIssueで確定した仕様・要件レベルの判断ロジックが要件タイプ別に集約されている（update-requirement-rules スキルが生成・維持する）。決着済みの判断をゼロから調べ直すと回答がブレるため、コード調査（ステップ3）より先に読む。

1. ls .claude/requirements/ 2>/dev/null で存在を確認する。無ければ黙ってスキップする
2. .claude/requirements/README.md（カテゴリ一覧）を読み、確認事項に関係するカテゴリを選ぶ
3. 選んだカテゴリファイルだけを Read で読む（全ファイルを読まない。無関係なカテゴリは回答材料にならず、コンテキストを圧迫するだけ）

使い方:

• 確認事項に該当するルールがあれば、その結論を回答の結論として採用し、根拠に .claude/requirements/<file>.md の該当ルール名を明記する（コード調査で裏取りできるならあわせて引用してよい）
• Issue本文の確定方針がルールと矛盾する場合はIssue本文を優先する（ルールは過去の一般解であり、依頼者が今回与えた前提を上書きしない）。矛盾に気づいた場合は回答末尾に「参考: 既存ルール『〜』とは異なる扱いになっている」と事実のみ1行残す
• 本スキルは .claude/requirements/ を編集しない（更新は update-requirement-rules の責務）

ステップ3: コードの分析

explore-agent サブエージェントで確認事項に関連するコードベースを調査する。確認事項に答えるのに必要な範囲が揃った時点で回答作成へ進む（網羅的な棚卸しは目的ではない）。Agent ツールの effort は毎回指定する（explore-agent は定義に effort を持たない。基準は ${CLAUDE_PLUGIN_ROOT}/references/agent-effort.md）。確認事項ごとの所在・現状確認は medium、回答に呼び出し関係や影響範囲を複数段たどる必要がある確認事項は high。

分析の観点: 言及されている機能・コンポーネントの実装状況、関連する設定ファイルの内容、必要に応じたgit履歴、コードベース内の関連パターン。調査対象のコード・設定に外部URLが現れ、それが結論を左右する場合は「外部リンクの参照」に従う（explore-agent へ委譲する場合も、この方針とURL・要点を返すことをプロンプトに明示する）。

UIや画面挙動に関する確認事項は、Playwright MCP（browser_* ツール群。プレフィックス付きで現れるため末尾の名前で判定する）で実際の画面上の動作を確認する。browser_navigate で該当ページへアクセスし、browser_snapshot / browser_take_screenshot / browser_click / browser_type / browser_fill_form でレンダリング結果の確認とインタラクション（クリック・入力・遷移）の検証を行い、browser_console_messages / browser_network_requests でコンソール・ネットワークを確認する。確認結果はスクリーンショットやログの抜粋を含めて回答の根拠として引用する。

ステップ4: 回答の作成とコメント編集

ステップ1で収集した確認事項の全件に回答を作成する。コメント由来・description由来を問わず、未回答の項目を残さない。

投稿先:

• 最後のコメントが確認事項コメントである場合は、そのコメントを編集して ## 回答 を追記する
• description由来の確認事項しか無い場合、または最後のコメントが確認事項コメントでない場合は、gh issue comment で新規コメントとして ## 回答 を投稿する
• 両方に確認事項がある場合は、1つの ## 回答 にまとめて投稿・追記する（update-issue が拾う入力を一本化するため、投稿口を複数に分けない）。description由来の項目には見出しに （description由来） を添えて出所を明示する

descriptionは編集しない。回答内容のdescriptionへの反映は後続の update-issue の責務であり、本スキルはコメントのみを書く。

回答の構造

各確認事項への回答に含める要素:

• 結論: 質問に対する直接的な回答
• 根拠: 結論を裏付けるエビデンスと推論（コードはファイルパスと行番号、外部ドキュメントはURLと参照箇所の要点）
• リスク・注意点: リスク、注意事項、エッジケース（該当する場合のみ）
• 推奨アクション: 推奨される次のステップ（該当する場合のみ。Issue本文の確定方針の範囲内に限る — 方針変更・代替案の提示、ステップ1.5のとおり Epic PR の未マージを理由にした「マージ待ち」「先にマージが必要」は書かない）

品質基準

• 推測する場合は必ずその旨を明示する
• 不確実な場合は確信度と追加調査の必要性を明示し、事実（コード・ローカルドキュメント・リンク先の外部ドキュメントで確認済み）と仮定を区別する

人間判断が必要と判定してよい条件

調査を尽くしても答えが決まらない項目だけを ## 人間判断が必要な確認事項（自動回答不能） に列挙する。以下を1つでも満たさないなら列挙してはならない（＝通常の回答として決着させる）。

1. コードベース・ローカルドキュメント・.claude/requirements/・外部リンク（「外部リンクの参照」に従う）・gh による関連Issue/PRの現在状態を実際に調査済みである。「調べれば分かりそう」は列挙の理由にならない
2. Issue本文の確定方針を適用しても答えが一意に決まらない（本文が結論を示しているなら、それを結論として採用する）
3. 判断が事実ではなく選好・優先度・ビジネス判断・不可逆な選択（破壊的変更の可否、データ移行の方針、課金・外部公開の判断など）に依存している

以下は列挙の理由にならない典型:

• 調査に手間がかかる／確信度がやや低い（→ 確信度を明示したうえで結論を書く）
• 複数の実装手段があるが、どれでも要件を満たす（→ 既存パターンに沿う案を推奨として1つ選び、根拠を書く）
• Epic PR が未マージ、デフォルトブランチとの差分がある（→ ステップ1.5のとおり正常状態。列挙しない）

回答の追記フォーマット

## 回答

### 確認事項1
（回答内容）

### 確認事項2（description由来）
（回答内容）

...（未回答の確認事項があれば同様に追加）

自動回答不能な項目が1件以上ある場合のみ、## 回答 の末尾に以下の固定セクションを追加する。1件も無い場合はセクションごと省略する（空のセクションや「該当なし」を書かない — triage-created-issue はセクションの有無で cc-need-human-check の要否を判定するため、空セクションでも人の手が止まる）。

## 人間判断が必要な確認事項（自動回答不能）

1. **<確認事項の問いをそのまま／人がそのまま回答できる形で>**
   - 調査済みの事実: <調査で判明した範囲。`path:line` やURLを添える>
   - 決まらない理由: <上記「人間判断が必要と判定してよい条件」のどれに該当するか>
   - 選択肢: <想定される選択肢と、それぞれを選んだ場合の影響。想定できない場合は省略>

セクション名・見出しレベルはこの固定文字列のとおりに書く（triage-created-issue が文字列一致で検出する）。

コメントの投稿・編集コマンド

既存の確認事項コメントへ追記する場合:

gh api repos/{owner}/{repo}/issues/comments/<コメントID> -X PATCH -f body="<編集後のコメント全文>"

description由来のみ、または最後のコメントが確認事項コメントでない場合（新規投稿）:

gh issue comment $0 --body-file -   # ヒアドキュメントで `## 回答` 全文を渡す

重要な制約

• cc-triage-scopeラベルがIssueに付与されている場合、いかなる操作においても絶対に削除しないこと
• gh issue editで--remove-labelを使用する際はcc-triage-scopeを対象に含めないこと

出力形式

処理結果を以下の形式で返す：

• Issue番号
• 回答した確認事項の数（コメント由来／description由来の内訳）
• 自動回答不能として ## 人間判断が必要な確認事項（自動回答不能） に列挙した項目の数と項目名（0件ならその旨。0件なら後続トリアージは cc-need-human-check を付けずに着手判定へ進む）
• 実行したアクション（コメント編集／新規コメント投稿など）