answer-issue-questions

name	answer-issue-questions
description	GitHub Issueの確認事項に対して、コードベースやドキュメントを徹底的に調査し、根拠に基づいた回答を提供するスキル。Issueの最後のコメントに含まれる確認事項を調査・回答し、コメントに追記する。
argument-hint	[issue-number]
hooks	{"Stop":[{"matcher":"","hooks":[{"type":"command","command":"node \"${CLAUDE_PLUGIN_ROOT}/scripts/stop-servers.mjs\""}]}]}

Answer Issue Questions

GitHub Issueの最後のコメントに含まれる確認事項を調査し、根拠に基づいた回答を提供するスキルです。

Instructions

実行モードの制約

本スキル固有のリスク: 本スキルは 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として起票を推奨」と1行添えるに留める

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

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

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

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

入力

• Issue番号: $0

実行ステップ

ステップ1: Issueとコメントの取得

対象Issueの情報と最後のコメントを取得する。

gh issue view $0 --json number,title,body,labels
gh issue view $0 --json comments --jq '.comments[-1]'

最後のコメントに確認事項が含まれているか確認する。確認事項がない場合はその旨を報告して終了する。

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

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

git fetch --prune || true

BASE_BRANCH=""
PARENT=$(gh issue view "$0" --json parent --jq '.parent.number // empty') || 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だけを対象にする（gh pr list --state open --json number,title,baseRefName --jq ".[] | select(.baseRefName == \"${BASE_BRANCH}\")"）。base が異なるPR（Epic PR 自身など）は回答対象外
• gh issue view --json parent に失敗した場合（PARENT=__unresolved__）は parent 不明として続行するが、未マージPRを根拠とした回答・注意点は書かない（安全側の倒し方）。その旨は最終報告に1行残す

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

確認事項の内容を理解するために、以下のドキュメントを読み込み、確認事項の背景・目的・関連する仕様を把握する。

• docs/配下のドキュメントファイル
• design/配下のPencilファイル（.pen）: inspect-pencil-node スキルで対象Nodeの属性データとスクリーンショットを取得して内容を確認する（.pen は暗号化バイナリのため Read/Grep は使えない）

本スキルはコードを変更しない（コメント編集のみ）ため、回答過程で .pen の編集が必要と判明した場合は本スキル内では編集せず、確認事項への回答内で「対応には pencil-design-updater エージェントによる <対象 .pen> の更新が必要」と明示して後続タスクへ委譲する。

.pen 編集は pencil-design-updater 専任で、手で pencil コマンドを直接組み立てたり frontend-implementer / general-purpose-assistant 等で代用したりしない（edit-pencil-design スキルに集約された運用ルール — 同パス上書き・差分Node特定・snapshots/ 出力 — を逸脱させないため）。

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

explore-agent サブエージェントで確認事項に関連するコードベースを調査する。確認事項に答えるのに必要な範囲を調べ、それが揃った時点で回答作成へ進む（網羅的な棚卸しは目的ではない）。

分析の観点：

• 確認事項で言及されている機能やコンポーネントの実装状況
• 関連する設定ファイルの内容
• 必要に応じたgit履歴の確認
• コードベース内の関連パターンの検索

UIや画面挙動に関する確認事項の場合は、claude-in-chrome MCP（mcp__claude-in-chrome__* ツール群）を使用して実際の画面上での動作を確認する。利用前に claude-in-chrome スキルを呼び出してツール群をロードすること。

• mcp__claude-in-chrome__tabs_create_mcp / navigate で該当ページにアクセスし、computer や read_page でレンダリング結果やレイアウトをスクリーンショット・テキストとして確認する
• computer や form_input でインタラクション（クリック、入力、遷移など）を実際に操作して検証する
• read_page / read_console_messages / read_network_requests でDOM構造・コンソールログ・ネットワーク通信を確認して問題の有無を調査する
• 確認結果は回答の根拠として引用する（スクリーンショットやログの抜粋を含める）

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

ステップ2・3の分析結果をもとに、各確認事項に対して回答を作成し、最後のコメントを編集して追記する。 回答が必要な確認事項が複数ある場合は、全ての項目に対して回答を追記する。

回答の構造

各確認事項への回答は以下の要素を含める：

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

品質基準

• 推測する場合は必ずその旨を明示する
• 回答は簡潔かつ網羅的にする
• 不確実な場合は、確信度と追加調査の必要性を明示する
• 事実（コードやドキュメントで確認済み）と仮定を区別する
• 回答はIssue本文の確定方針を前提に書く。方針の再審議・代替案の提示はしない（詳細は「Issue本文の方針・前提の尊重」を参照）

回答の追記フォーマット

## 回答

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

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

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

コメントの編集コマンド

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

重要な制約

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

出力形式

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

• Issue番号
• 回答した確認事項の数
• 実行したアクション（コメント編集など）