GitHub Issueの確認事項（最後のコメント・descriptionの両方）を、コードベース・ドキュメント・そこから参照されている外部リンク（仕様書・ライブラリ公式ドキュメント等）まで調査し、根拠に基づいた回答をコメントに追記するスキル。
調査しても事実で決まらず人間の意思決定が必要な項目は、固定セクションで明示して後続のトリアージへ引き渡す。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
本スキルの 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 本文の前提でも決まらない場合に限り列挙してよい（判定基準は「人間判断が必要と判定してよい条件」を参照）。これは「問われた確認事項に答えられなかった」ことの申告であり、問われていない方針を再審議する口実にはならない。回答本文（## 回答 の各項目）側には方針の再審議・代替案の列挙を書かない理由: 回答コメントは後続の update-issue が description へ反映する入力になる。回答が方針を再審議すると、人間が与えた方針がAIのコメントで上書きされ、着手できたはずのIssueが「方針確定待ち」に差し戻される。
回答コメントは人間が読み、update-issue が description へ取り込む成果物。問われたことに答える分量に収める。
path:line の引用（外部情報なら URL と要点）で足りる。コードの長大な貼り付け・リンク先の全文転記・調査経過の逐次記録は載せない$0GitHub 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箇所から収集し、両方を回答対象にする。
## 確認事項 セクション、または箇条書きの問いかけ## 確認事項 セクションのほか、「確認したいこと」「要確認」「TBD」「未確定」などの形で本文に残っている未確定項目。コメント側に確認事項が無くても description 側だけで対象が成立しうる
## 回答 コメント、および人間のコメントで既に決着している項目は再回答しない（同じ問いへ二重に答えると update-issue が矛盾する記述を description へ取り込む）両方の収集源を合わせても未回答の確認事項が1件も無い場合は、その旨を報告して終了する（回答コメントは投稿しない）。
回答の基準となるベースブランチ（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 をマージすべき」等）を回答に含めない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=__unresolved__）は parent 不明として続行するが、未マージPRを根拠とした回答・注意点は書かない（安全側の倒し方）。その旨は最終報告に1行残す確認事項の背景・目的・関連する仕様を把握するため、以下を読み込む。
.claude/requirements/配下の要件ルール: 後述の「要件ルールの参照」に従うdocs/配下のドキュメントファイルdesign/配下のPencilファイル（.pen）: inspect-pencil-node スキルで対象Nodeの属性データとスクリーンショットを取得する（.pen は暗号化バイナリのため Read/Grep は使えない）本スキルはコードを変更しない（コメント編集のみ）。回答過程で .pen の編集が必要と判明した場合も編集せず、回答内で「対応には <対象 .pen> の更新が必要であり、cc-create-ui-design のデザイン先行フローで行う」と明示する。.pen の新規作成・編集は同フローの専任であり、実装PR（exec-issue）では行わないため、実装セッションに .pen を編集させる回答は書かない。
gh とローカルファイルで完結させない）確認事項の答えがリポジトリの外（仕様書・API仕様・ライブラリ公式ドキュメント・別リポジトリのIssue/PR・デザインURLなど）にあることがある。gh とローカルファイルだけで調べて「確認できなかった」と返すと、リンク先に書いてある答えを人へ差し戻すことになる。リンク先の内容まで読んで回答を確定させる。
WebFetchcheck-library スキル（Next.js / shadcn / context7 MCP を使い分ける）。バージョン差のあるAPI仕様を検索結果の要約で代用しないissue_read / pull_request_read（method: get）を使う。利用不可なら gh issue view / gh pr view / gh api へフォールバック（GitHubのURLは WebFetch より確実）mcp__claude_ai_Figma__*）WebFetch。URLを見て終わりにしない）。画像は Issue へ直接添付せず Drive 等へ上げてリンクする運用を前提とする — GitHub の添付ファイル（user-images.githubusercontent.com / github.com/user-attachments/...）は認証付きの実体取得が必要でクラウドセッションからは読めないため、直接添付されていて読めない場合は推測で埋めず「取得不可（Issue への直接添付のため）」と根拠に明記するWebSearch で現行の一次情報を探す（見つからなければ深追いしない）<URL> — <参照した要点> の形で残す（path:line の引用と同格の根拠として扱う）<URL> は取得不可（理由）」と根拠に明記したうえで、確認済みの範囲で答えられる分を回答する.claude/requirements/ には、過去のIssueで確定した仕様・要件レベルの判断ロジックが要件タイプ別に集約されている（update-requirement-rules スキルが生成・維持する）。決着済みの判断をゼロから調べ直すと回答がブレるため、コード調査（ステップ3）より先に読む。
ls .claude/requirements/ 2>/dev/null で存在を確認する。無ければ黙ってスキップする.claude/requirements/README.md（カテゴリ一覧）を読み、確認事項に関係するカテゴリを選ぶRead で読む（全ファイルを読まない。無関係なカテゴリは回答材料にならず、コンテキストを圧迫するだけ）使い方:
.claude/requirements/<file>.md の該当ルール名を明記する（コード調査で裏取りできるならあわせて引用してよい）.claude/requirements/ を編集しない（更新は update-requirement-rules の責務）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 でコンソール・ネットワークを確認する。確認結果はスクリーンショットやログの抜粋を含めて回答の根拠として引用する。
ステップ1で収集した確認事項の全件に回答を作成する。コメント由来・description由来を問わず、未回答の項目を残さない。
投稿先:
## 回答 を追記するgh issue comment で新規コメントとして ## 回答 を投稿する## 回答 にまとめて投稿・追記する（update-issue が拾う入力を一本化するため、投稿口を複数に分けない）。description由来の項目には見出しに （description由来） を添えて出所を明示するdescriptionは編集しない。回答内容のdescriptionへの反映は後続の update-issue の責務であり、本スキルはコメントのみを書く。
各確認事項への回答に含める要素:
調査を尽くしても答えが決まらない項目だけを ## 人間判断が必要な確認事項（自動回答不能） に列挙する。以下を1つでも満たさないなら列挙してはならない（＝通常の回答として決着させる）。
.claude/requirements/・外部リンク（「外部リンクの参照」に従う）・gh による関連Issue/PRの現在状態を実際に調査済みである。「調べれば分かりそう」は列挙の理由にならない以下は列挙の理由にならない典型:
## 回答
### 確認事項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を対象に含めないこと処理結果を以下の形式で返す：
## 人間判断が必要な確認事項（自動回答不能） に列挙した項目の数と項目名（0件ならその旨。0件なら後続トリアージは cc-need-human-check を付けずに着手判定へ進む）まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Write the merged Pencil design reference back into a UI implementation Issue's description. Takes the Issue number as argument, resolves the merged design PR on the `cc-ui-design-<Issue number>` branch, collects the `.pen` and snapshot paths it added, and appends (or replaces) the `## UIデザイン` section at the end of the Issue body using a lost-update-safe edit.
依頼された内容（自然言語の説明、または既存のIssue番号）を要件とTODOに分解し、タスクごとにGitHub Issueを作成するスキル。タスクの整理・分解、複数Issueの一括作成、依存関係の明示が必要な場合に使用する。「この機能をIssueに分けて」「タスクを洗い出してIssueにして」「PRDのIssue #123 を分解して」といったリクエストで発動する。
claude-task-worker のカスタムワーカー（`workerFiles` に登録する TS 定義）を、`AskUserQuestion` で要件を全項目確定させてから生成し、`claude-task-worker list-workers` でロード検証までするスキル。「カスタムワーカーを作って」「独自のワーカーを追加したい」「新しいラベルで動くワーカーを定義したい」といったリクエストで使用する。
claude-task-workerプラグインのバージョンをインクリメントし、commit-pushでコミット・プッシュしたうえでPRを作成する。引数で `major` / `minor` / `patch` を受け取り、対応する部分をインクリメントする（省略時は `patch`）。「バージョンを上げて」「バージョンアップ」「bump version」「メジャーバージョンを上げて」などのリクエストで使用する。
指定されたPR番号のDependabot PRを確認し、依存ライブラリのバージョンアップ内容をCHANGELOGとcontext7から取得して、コード修正が必要かを判定します。修正が必要な場合は修正を行い、pushまで実施します。
ライブラリの情報を確認するためのスキル。Next.js、shadcn、その他のライブラリについて、適切なMCPサーバーを使用して最新のドキュメントと使用方法を取得します。