GitHub Issueの内容を取得し、並列実行可能な単位に分解します。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
引数で指定された GitHub Issue（番号の確定手順は手順0）を読み取り、後続フェーズが機械的に扱える形へ構造化して返すスキル。推測で穴埋めせず、Issueに書かれている事実と、書かれていない不確実性を分けて返すこと。
本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。
本スキルの入力は対象 Issue の番号1つ。下記の args 入力スロットに呼び出し時の args が展開される。Issue 番号（数字。#123 形式や Issue URL でもよい）として解釈できればそれを採用する。番号を得られない場合は、推測で番号を選ばず、理由を1-2行で出力して即中断する。
args 入力スロット:
<args-input> $ARGUMENTS </args-input>以降の手順では、確定した番号を <issue番号> と表記する。
呼び出し側への必須ルール: 呼び出し元（exec-issue 等）は、本スキルを Skill(skill='read-github-issue', args=<issue番号>) で起動すること。
本文・状態・ラベルをまとめて取得する。コメントは取得しない（本文のみを分析対象とする）。
GitHub MCP の issue_read（method: get）を第一手段とする。MCP が利用不可（未設定・未認証・呼び出し失敗）な場合のみ、以下の gh コマンドへフォールバックする。
gh issue view <issue番号> --json number,title,state,labels,assignees,milestone,url,body
以下も併せて確認：
WebFetch、Google Drive はドライブ用の MCP、Figma は Figma MCP）。直接添付された画像は bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh fetch-attachments <issue番号> "$(mktemp -d)" でダウンロードしてから Read で見る（添付 URL を直接開かない。クラウドでは 403。詳細は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md の「画像・添付ファイル」）。取得に失敗した場合は、その旨を明記して確認できた範囲で続行する#123 形式や URL での参照は依存関係の手がかり。必要に応じて GitHub MCP の issue_read（method: get）/ pull_request_read（method: get）を優先し、利用不可なら gh issue view <num> / gh pr view <num> へフォールバックして内容を確認explore-agent に委譲するIssueが CLOSED の場合、その旨を明記してそのまま返す（タスク分解は行わない）。
Issueから「やるべきこと」を抽出し、並列実行可能な単位に分解する。
Issue本文だけでは「どのファイルを触るか」「タスク間でファイルが衝突するか」を判断できないため、コードベースの調査は explore-agent サブエージェントに委譲する（ファイル横断の fan-out 探索を一度に行えるため、自前で Read を繰り返すより速く正確）。Issueに登場するファイルパス・関数名を起点に、関連実装・呼び出し元・テスト（ユニット・E2E）の所在を特定させ、その結論をもとに各タスクの対象範囲と衝突可能性を確定する。調査観点が独立する場合は、複数の explore-agent を同一メッセージ内で並列に起動して待ち時間を圧縮する。explore-agent は読み取り専用でコードの所在特定に特化しており、タスクの切り分け判断そのものは本スキル側で行う。Agent ツールの effort は毎回指定する（explore-agent は定義に effort を持たない。基準は ${CLAUDE_PLUGIN_ROOT}/references/agent-effort.md）。関連実装・呼び出し元・テスト・E2E基盤の所在特定は medium、Issue が複数モジュールにまたがりタスク間のファイル衝突を判断するのに呼び出し関係を複数段たどる必要がある観点は high。
1タスク = 「1つのサブエージェントが自己完結して完了条件まで到達できる作業」。大きすぎる場合は分割し、小さすぎる（変更1行など）場合はまとめる。
上記に該当しないタスクは 並列グループ にまとめる。
UI変更を含むタスクは、「デザインのマークアップ」と「配線」を別タスクに分ける。呼び出し元（exec-issue）はマークアップタスクだけを frontend-implementer（マークアップ専任エージェント）へ、配線タスクを general-purpose-assistant へ委譲するため、混ざったままだと専任エージェントに担当外の実装が渡る。
.pen / スナップショット / DESIGN.md / Issue本文の視覚的な指定）をマークアップ・スタイル・視覚的な状態（hover / focus / disabled / エラー / ローディング / 空状態）へ変換する作業。完了条件は「デザインとの視覚的一致」と「表示に必要な props のシグネチャ（名前・型・意味）が定義されていること」に閉じ、データ取得やロジックの動作を含めない分離したタスクは同一のコンポーネントファイルを編集するため、逐次グループにまとめ「マークアップ → 配線」の順を明記する。異なる画面のマークアップタスク同士は並列でよい。
分離しない例外: マークアップ側の変更が数行で収まる場合（既存コンポーネントへの表示条件追加、文言差し替え、既存トークンでのスタイル微修正など）は分割コストが上回るため1タスクにまとめ、その旨を種別に明記する。
デザインマークアップ / 配線 / 通常（UI変更を含まないタスクは 通常）explore-agent への調査観点に「E2Eテスト基盤の有無と所在」を必ず含める。判定基準は、E2Eフレームワークの設定ファイル（playwright.config.* / cypress.config.* / wdio.conf.* / nightwatch.conf.* など）、e2e/ / tests/e2e/ / cypress/ 等のE2Eテスト用ディレクトリ、package.json の scripts にある test:e2e / e2e 系コマンドのいずれかが存在すること。
E2Eテストが存在するプロジェクトでは、ユーザー操作フロー（画面遷移・フォーム入力・API連携・CLIの入出力など）に影響するタスクについて、完了条件に「該当フローのE2Eテストの追加・更新」を含め、対象範囲に該当E2Eテストのパスを含める。E2Eテストが存在しない場合は、Issueが明示的に要求しない限りE2Eテスト基盤の新規導入をタスク化しない（スコープ外）。
実装プランのステップの中で、「特定のスキル（claude-task-worker/skills/○○/SKILL.md）の実行を要求するもの」は、通常タスクと分けてスキル実行ステップとして明示的に扱う。呼び出し元（exec-issue 等）はこれを見て、サブエージェントへの委譲ではなく Skill ツールで直接発火する経路に振り分ける（サブエージェントに委譲するとスキル固有の副作用 — フック・ガードレール・PR作成・ラベル遷移・スナップショット出力等 — が保証されないため）。
以下の兆候をもつステップが該当する：
○○スキルを実行する」「/○○ を呼ぶ」「claude-task-worker/skills/○○/SKILL.md を発火する」等の明示的な呼び出し指示があるcreate-pr、「コミットしてpushする」→ commit-push）該当するステップは通常タスクの並列/逐次グループから除外し、返却フォーマット（手順3）の「## スキル実行ステップ」セクションに集約する。各ステップに以下の情報を保持する：
claude-task-worker/skills/○○/SKILL.md のディレクトリ名、または frontmatter の name）判定が微妙な場合は、「スキル実行ステップ候補」として通常タスクとは別に列挙し、呼び出し元で最終判定できるように判定根拠と判定に迷った理由を添える（推測で通常タスクに寄せない）。
以下の構造で返却する。呼び出し元はこの構造に依存するため、セクション見出しを変えないこと。
## 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**: ...（先行。UI変更の場合は種別 `デザインマークアップ`。完了条件に「デザインとの視覚的一致」「props シグネチャの定義」を含める）
- **task-b2**: ...（task-b1 の出力に依存。UI変更の場合は種別 `配線`。task-b1 が定義した props を埋める作業として書く）
## スキル実行ステップ
（該当するステップがなければ「該当なし」と明記）
- **skill-step-1**: <ステップ名>
- 呼び出すべきスキル: `<スキル名>`（例: `commit-push`, `create-pr`）
- 引数: `<引数>`（例: Issue番号 `<issue番号>`。なければ「なし」）
- 目的: ...
- 完了条件: ...（スキル固有の副作用が発生していることを含める）
- 依存関係: <先行タスク・先行スキルがあれば列挙。なければ「なし」>
- 判定根拠: <なぜスキル実行ステップと判定したか。「明示指示あり」「副作用要件」等を1行で>
### スキル実行ステップ候補（判定が微妙なもの）
（該当なしなら「該当なし」と明記）
- **skill-candidate-1**: <ステップ名>
- 呼び出す可能性のあるスキル: `<スキル名>`
- 判定に迷った理由: <本文が曖昧／副作用要件がスキル固有か通常タスクでも満たせるか判別不能／等>
- 呼び出し元への申し送り: <どちらに寄せるかを最終判定するための追加情報>
## タスク間の依存関係
- 並列グループA と 逐次グループB は独立 / Aの完了後にBを開始 など
- 図示が有用な場合は箇条書きで「X が Y に依存」と明記
## 参考情報
- Issue: <URL>
- 関連Issue/PR: #..., #...
- 画像/添付: ローカルパス
- コード参照: `path/to/file:line`
## 不確実性・確認事項
（Issueから判断できなかった点。空配列でもよい）
- <仕様が曖昧な点。どう解釈して進めるかの提案を添える>
- <受け入れ基準が不明な点>
不確実性セクションは、推測で埋めずに「決めきれない箇所」を明示するのが目的。呼び出し元はここを見て、ユーザー確認の要否を判断する。
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
GitHub Issueの確認事項（最後のコメント・descriptionの両方）を、コードベース・ドキュメント・そこから参照されている外部リンク（仕様書・ライブラリ公式ドキュメント等）まで調査し、根拠に基づいた回答をコメントに追記するスキル。調査しても事実で決まらず人間の意思決定が必要な項目は、固定セクションで明示して後続のトリアージへ引き渡す。
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
依頼された内容（自然言語の説明、または既存のIssue番号）を要件とTODOに分解し、タスクごとにGitHub Issueを作成するスキル。タスクの整理・分解、複数Issueの一括作成、依存関係の明示が必要な場合に使用する。「この機能をIssueに分けて」「タスクを洗い出してIssueにして」「PRDのIssue #123 を分解して」といったリクエストで発動する。
The English summary is being prepared. Showing the original description.
claude-task-worker のカスタムワーカー（`workerFiles` に登録する TS 定義）を、`AskUserQuestion` で要件を全項目確定させてから生成し、`claude-task-worker list-workers` でロード検証までするスキル。「カスタムワーカーを作って」「独自のワーカーを追加したい」「新しいラベルで動くワーカーを定義したい」といったリクエストで使用する。
The English summary is being prepared. Showing the original description.
claude-task-workerプラグインのバージョンをインクリメントし、commit-pushでコミット・プッシュしたうえでPRを作成する。引数で `major` / `minor` / `patch` を受け取り、対応する部分をインクリメントする（省略時は `patch`）。「バージョンを上げて」「バージョンアップ」「bump version」「メジャーバージョンを上げて」などのリクエストで使用する。
The English summary is being prepared. Showing the original description.
指定されたPR番号のDependabot PRを確認し、依存ライブラリのバージョンアップ内容をCHANGELOGとcontext7から取得して、コード修正が必要かを判定します。修正が必要な場合は修正を行い、pushまで実施します。
The English summary is being prepared. Showing the original description.