Menü
依頼された内容を要件とTODOに分解し、タスクごとにGitHub Issueを作成するスキル。タスクの整理・分解、複数Issueの一括作成、依存関係の明示が必要な場合に使用する。「この機能をIssueに分けて」「タスクを洗い出してIssueにして」「要件を整理してチケット化して」といったリクエストで発動する。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
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
| name | breakdown-issues |
| description | 依頼された内容を要件とTODOに分解し、タスクごとにGitHub Issueを作成するスキル。タスクの整理・分解、複数Issueの一括作成、依存関係の明示が必要な場合に使用する。「この機能をIssueに分けて」「タスクを洗い出してIssueにして」「要件を整理してチケット化して」といったリクエストで発動する。 |
| argument-hint | [task-description] |
| model | opus |
| effort | high |
依頼された内容を requirement-todo-organizer エージェントで要件・TODOに分解し、各タスクをGitHub Issueとして作成するスキルです。
デフォルトブランチに移動し、git pull originで最新状態にする。
requirement-todo-organizer サブエージェントを使用して、以下の依頼内容を要件定義・TODO分解する。
$ARGUMENTS
ステップ2で分解した要件・TODOに不明点や曖昧な点があれば、AskUserQuestionツールを使用してユーザーに質問する。
子Issueを作る前に、ステップ2で分解した全TODOを束ねる「親Issue（Epic）」を1つ作成する。子Issueは後段でこの親Issueの sub-issue として作成するため、先に親番号を確定させる。親Issueは「この一連のタスク群が何を達成するためのものか」のサマリとして機能し、全体像と進捗を1つの番号で追えるようにする。
cc-epic-issue（親 Epic Issue であることを示す。必ず付与）$ME）gh issue edit で追記してもよいが、GitHub UI の sub-issue 表示で十分追えるので必須ではない）post-scope-issue-body のフォーマットは個別TODO用のスコープIssue向け（要件・参照情報・優先度・見積もり規模）であり、Epicサマリには合わないため、親Issueはこのスキル内で直接 gh issue create する。
ME=$(gh api user --jq '.login')
EPIC_ISSUE_URL=$(gh issue create \
--title "<Epicタイトル>" \
--assignee "$ME" \
--label "cc-epic-issue" \
--body-file - <<'EOF'
## 概要
（依頼内容の全体像を1-3段落で）
## 背景・ゴール
（このEpicが達成すべきゴール、なぜ必要か）
EOF
)
EPIC_ISSUE_NUMBER=$(basename "$EPIC_ISSUE_URL")
gh issue create が失敗した場合は本ステップでそのまま中断する（親Issueが無い状態で子Issueだけ作っても sub-issue 関係が貼れず、本スキルの趣旨を満たさないため）。
ステップ2で洗い出した各TODOに対して、ステップ4で作った親Issueの sub-issue として GitHub Issue を作成する。
本文整形・投稿前チェック・gh issue create の実行は post-scope-issue-body スキルに委譲する。本文テンプレート・投稿前チェックリスト・heredoc 投稿コマンドはすべて post-scope-issue-body 側に集約されているため、本スキル内では再記述しない。本スキルでは「TODOの整理」「作成順序の制御」「親Issue番号と依存先Issue番号の確定と YAML への受け渡し」のみを担う。
依存関係は本文の ## 依存関係 セクションには書かず、GitHub ネイティブの relationships（blocked-by）を使う。post-scope-issue-body の YAML 入力に blocked_by: を渡して gh issue create --blocked-by 経由で貼る（GitHub UI で関係性が表示され、本文との二重管理によるズレも避けられる）。
依存関係のないタスク（依存先が「なし」のもの）から先に作成し、依存先のIssue番号が確定してから依存タスクのIssueを作成する。post-scope-issue-body は1回の呼び出しで1つのIssueを作成して URL と Issue 番号を返すので、順に呼び出し、後続TODOの blocked_by: リストに先行Issueの番号を入れてから次の呼び出しを行う。
TODO 1件ごとに、以下の YAML ブロックをそのまま args として Skill tool で post-scope-issue-body を起動する（post-scope-issue-body は args を YAML として機械的にパースする規約）。
mode: create
title: <TODOのタスク名をそのまま>
sections:
概要: |
（1-3行）
要件: |
- ...
（無ければ "なし"）
参照情報: |
- ドキュメント: `<path>` — <説明>
（無ければ "なし"）
優先度: High # High / Medium / Low のいずれか
見積もり規模: M # S / M / L / XL のいずれか
# ステップ4で確定した親Issue番号。全TODOで同じ値を渡す。
parent: <EPIC_ISSUE_NUMBER>
# 依存先がある場合のみ書く。先行して作成済みのIssue番号を入れる。依存先が無い場合は項目ごと省略。
blocked_by: [<先行TODOで確定済みのIssue番号>, ...]
Skill tool 呼び出しは Skill(skill='post-scope-issue-body', args=<上記YAML文字列>)（必要なら plugin namespace 付きで claude-task-worker:post-scope-issue-body）。args は改行を含む複数行文字列としてそのまま渡す。完了後、作成された Issue URL と Issue 番号が返ってくるので、番号は次以降のTODOの blocked_by: に入れる用途で保持する。
post-scope-issue-body の失敗（gh コマンド失敗・本文チェック不通過・--parent/--blocked-by の検証エラー等）はそのまま本ステップの中断条件となる。エラーメッセージを最終報告に含め、既に作成済みのIssue（親Issueと作成済みの子Issue）は残したまま中断する。
全Issueの作成が完了したら、以下を報告する：