Menu
GitHub Issueの内容を取得し、並列実行可能な単位に分解します。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | read-github-issue |
| description | GitHub Issueの内容を取得し、並列実行可能な単位に分解します。 |
| argument-hint | [issue-number] |
引数で指定された GitHub Issue（番号の確定手順は手順0）を読み取り、後続フェーズが機械的に扱える形へ構造化して返すスキル。 推測で穴埋めせず、Issueに書かれている事実と、書かれていない不確実性を分けて返すこと。
本スキルの入力は対象 Issue の番号1つ。下記の args 入力スロットに呼び出し時の args が展開される。Issue 番号（数字。#123 形式や Issue URL でもよい）として解釈できればそれを採用する。番号を得られない場合は、推測で番号を選ばず、理由を1-2行で出力して即中断する。
args 入力スロット:
$ARGUMENTS以降の手順では、確定した番号を <issue番号> と表記する。
呼び出し側への必須ルール: 呼び出し元（exec-issue 等）は、本スキルを Skill(skill='read-github-issue', args=<issue番号>) で起動すること。
本文・状態・ラベルをまとめて取得する。コメントは取得しない（本文のみを分析対象とする）。
gh issue view <issue番号> --json number,title,state,labels,assignees,milestone,url,body
以下も併せて確認：
gh-asset でダウンロードして内容を読む
gh-asset download <asset_id> ~/Downloads/
#123 形式や URL での参照は依存関係の手がかり。必要に応じて gh issue view <num> / gh pr view <num> で内容を確認explore-agent に委譲するIssueが CLOSED の場合、その旨を明記してそのまま返す（タスク分解は行わない）。
Issueから「やるべきこと」を抽出し、並列実行可能な単位に分解する。
Issue本文だけでは「どのファイルを触るか」「タスク間でファイルが衝突するか」を正確に判断できないため、コードベースの調査は explore-agent サブエージェントに委譲する。Issueに登場するファイルパス・関数名を起点に、関連実装・呼び出し元・テスト（ユニット・E2E）の所在を explore-agent に特定させ、その結論をもとに各タスクの対象範囲と衝突可能性を確定する（自前で Read を繰り返すより、ファイル横断の fan-out 探索を一度に行える explore-agent の方が速く正確なため）。調査観点が独立する場合は、複数の explore-agent を同一メッセージ内で並列に起動して待ち時間を圧縮する。explore-agent は読み取り専用でコードの所在特定に特化しており、タスクの切り分け判断そのものは本スキル側で行う。
1タスク = 「1つのサブエージェントが自己完結して完了条件まで到達できる作業」。 大きすぎる場合は分割し、小さすぎる（変更1行など）場合はまとめる。
上記に該当しないタスクは 並列グループ にまとめる。
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**: ...（先行）
- **task-b2**: ...（task-b1 の出力に依存）
## スキル実行ステップ
（該当するステップがなければ「該当なし」と明記）
- **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から判断できなかった点。空配列でもよい）
- <仕様が曖昧な点。どう解釈して進めるかの提案を添える>
- <受け入れ基準が不明な点>
不確実性セクションは、推測で埋めずに「決めきれない箇所」を明示するのが目的。 呼び出し元はここを見て、ユーザー確認の要否を判断する。
Re-analyze an existing GitHub Issue using its current title and body as input, refresh the implementation plan against the latest code state, and update the Issue in place. Use this when the user provides an Issue number (numeric, `#`-prefixed, or Issue URL) and wants to regenerate the code analysis via the explore-agent subagent. For reflecting comment-driven updates instead, use update-issue. For creating a brand-new Issue from a natural-language task description, use create-issue.
Create an implementation plan and a GitHub Issue based on the task description provided as an argument. Use this when the user supplies a natural-language task description (not an issue number) and wants a new implementation-ready Issue. If the input is an existing issue number, use create-issue-from-issue-number (re-analyze) or update-issue (reflect comments) instead.
GitHub Issueの確認事項に対して、コードベースやドキュメントを徹底的に調査し、根拠に基づいた回答を提供するスキル。Issueの最後のコメントに含まれる確認事項を調査・回答し、コメントに追記する。
ライブラリの情報を確認するためのスキル。Next.js、shadcn、その他のライブラリについて、適切なMCPサーバーを使用して最新のドキュメントと使用方法を取得します。
Create or update the Pencil (`.pen`) design for a UI implementation Issue before any code is written, then open a design-only PR. Takes the Issue number as argument, extracts the design requirements from the Issue description and comments, delegates `.pen` edits to the pencil-design-updater agent, exports snapshot PNGs, pushes them on the fixed `cc-ui-design-<Issue number>` branch, and opens a PR that references the Issue with `Refs #<N>` (never a closing keyword).
Execute tasks based on GitHub Issue content