| name | create-issue |
| description | 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. |
| argument-hint | [task-description] |
Create Issue
引数で受け取ったタスク説明をもとに要件を整理し、GitHub Issueを新規作成するスキル。Instructionsの順に最後まで自律的に実行する。
自律実行原則: ユーザーへの確認は行わず、判断はすべて本スキル内のルールで自動決定する。途中で質問せず、確認したいことは最後にIssueへのコメントとして残す。中断条件に該当した場合のみ、理由を出力して終了する。
入力範囲: 引数は「自然言語のタスク説明」のみ。Issue 番号（数値のみ・#付き数値・Issue URL）の場合は扱わず、既存 Issue のコード再分析は /create-issue-from-issue-number、コメント由来の反映は /update-issue を案内して終了する。
責務の分担: 本スキルは「分析（タスク内容理解・コード分析）」までを担い、「本文整形・投稿前チェック・gh issue create 実行」は post-issue-body スキルへ委譲する。本文テンプレート・変更ログ追記ルール・投稿前チェックリスト・heredoc 投稿コマンドはすべて post-issue-body 側に集約されているため、本スキル内では再記述しない。
Instructions
フェーズ0: 事前チェック
0-1. 引数の妥当性確認
$ARGUMENTS が以下に該当する場合は中断する（このスキルは新規作成専用）。判定は機械的に行い、ユーザーへの確認は不要。
- 数値のみ（例:
123）
#付き数値（例: #123）- GitHubのIssue URL（
.../issues/<番号>）
該当時は、「このスキルは新規作成専用です。既存Issueを起点に再分析するには /create-issue-from-issue-number <番号> を、コメントから未反映事項を反映するには /update-issue <番号> を使ってください」と出力して終了する。
引数が空、または意味のあるタスク説明を含まない場合も中断する。
0-2. 作業ディレクトリの確認
pwd を実行し、結果に応じて以下を判定する。worktreeを新たに作成しないこと。
.claude/worktrees/ 配下にいる → そのworktree内で作業- それ以外（リポジトリのルート等）→ その場で作業
0-3. デフォルトブランチの安全な同期（fail-safeにスキップ可）
以下を試行し、失敗しても中断せずスキップして続行する（本スキルはコード変更を伴わないため、最新化に失敗しても作業継続できる）。
git fetch --prune || true
git rebase や git pull は実行しない（未コミット変更や conflict による中断を避けるため）。
完了条件: 引数がタスク説明として有効と確認でき、作業ディレクトリが特定されていること。
1. タスクの分析（参考情報の収集）
タスクの背景を理解するために、存在するもののみを読み込む。存在しないパスは黙ってスキップする。
docs/ 配下のドキュメントファイル: ls docs/ 2>/dev/null で存在確認した上で、タスクに関係しそうなファイルを読むdesign/ 配下の Pencil ファイル（.pen）: ls design/ 2>/dev/null で存在確認した上で、inspect-pencil-node スキルで対象Nodeの属性データとスクリーンショットを取得して内容を確認する（.pen は暗号化バイナリのため Read/Grep は使わない）。.pen の編集が必要と判明した場合は本スキル内では編集せず、post-issue-body へ渡す「実装プラン」「確認事項」に「pencil-design-updater エージェントで <対象 .pen> を更新する」旨を明記して後続タスクへ委譲する
タスク内容
$ARGUMENTS
2. コードの分析（explore-agent サブエージェントを使用）
explore-agent サブエージェントを起動し、以下を取得する。
- 影響範囲となる主要ファイル・ディレクトリ（最大10件）
- 既存の類似実装の参照先（最大5件、ファイルパスと役割の1行説明）
- タスク達成に必要な変更の概略（フェーズ分け可能なら3段階以内）
- E2Eテスト基盤の有無と所在（
playwright.config.* / cypress.config.* / wdio.conf.* / nightwatch.conf.* 等の設定ファイル、e2e/ / tests/e2e/ / cypress/ 等のディレクトリ、package.json の test:e2e / e2e 系 scripts のいずれかが存在すれば「あり」と判定。関連する既存E2Eテストのパスも特定する）
- 不確実性・確認事項の候補リスト（推測で埋めない。ただしこのリストはそのまま Issue に載せず、後述の「確認事項の取捨選択」で絞り込む）
サブエージェントへのプロンプトには「ユーザーには質問せず、調査結果を返却して終了する」ことと、上記の出力フォーマットを明示する。
確認事項の取捨選択（自明なものは載せない）
explore-agent が挙げた候補をそのまま confirmation_items へ流さない。確認事項コメントは人の回答待ち（cc-answer-issue-questions）を発生させるため、調査で答えが出るものを混ぜると着手が無駄に止まる。
投稿前に1件ずつ判定し、以下に該当するものは確認事項から外す。外した項目は、結論と根拠を description（要件・実装プラン・参照情報）側へ書く。
- コード・ドキュメント・git履歴・
gh コマンドで調べれば一意に決まる（既存実装・既存パターン・設定値・命名規約から導ける）
- 本文の結論を裏付け直すだけの確認（「〜という理解で合っているか」「〜の方針でよいか」）
- どちらを選んでも要求を満たす実装判断 — 既存実装に倣った安全側の既定を選び、選んだ理由を実装プランに1行書く
残すのは「人の意思決定でしか決まらず、選択次第で成果物が変わる」項目だけ（仕様の分岐、スコープの線引き、外部要因の可否など）。判定に迷い、かつ調査で答えを出せるなら調べて確定させ、確認事項からは外す。
絞り込んだ結果0件なら confirmation_items をキーごと省略する（確認事項コメントは投稿されない）。
E2Eテストが存在し、かつタスクがユーザー操作フロー（画面遷移・フォーム入力・API連携・CLIの入出力など）に影響する場合は、post-issue-body に渡す「実装プラン」に「該当フローのE2Eテストの追加・更新」ステップを含め、「影響範囲」に該当E2Eテストのパスを含める。E2Eテストが存在しない場合は、タスク説明が明示的に要求しない限りE2Eテスト基盤の新規導入をプランに含めない。
直近関連変更の確認（必須）
進行中・直近完了済みの関連作業を見落とし、既存実装と重複するゴーストタスクを含んだ Issue を起票しないため、explore-agent が特定した対象ファイル一覧について直近の commit 履歴と関連 PR を必ず確認する。
- 対象ファイルごとに
git log --oneline -10 <file> を実行し、直近 commit のサマリを把握する
gh pr list --search "<file>" で未マージの関連 PR を確認する- 直近 commit に大規模リファクタ・共通ヘルパー追加などの大きな変更が含まれる場合や、未マージの関連 PR がある場合は、その内容を
post-issue-body に渡す「直近関連変更」セクション（必要に応じて「参照情報」にも）に必ず記載し、実装プランが既存実装と重複していないか検証する
- git 履歴のない新規機能要求など確認が困難なケースでは「該当なし」と記載してスキップしてよい
依存関係の特定（blockedBy / blocking）
作成する Issue が他の Open な Issue と依存関係を持つ場合、それを GitHub ネイティブ relationships（blocked-by / blocking）で明示する。依存関係は本文の ## 依存関係 セクションには書かず、post-issue-body の blocked_by / blocking 経由で gh issue create --blocked-by / --blocking として貼る（GitHub UI で関係性が表示され、本文との二重管理によるズレも避けられる）。
以下の手順で依存先・依存元を洗い出す。推測で無関係な Issue を紐付けないよう、根拠が明確なものだけを対象にする。
- タスク説明中の明示的な参照:
$ARGUMENTS に他の Issue/PR への言及（#123・Issue URL・「〇〇 の後に」「〇〇 が前提」「〇〇 をブロックする」等）があれば抽出する。
- explore-agent・直近関連変更からの示唆: ステップ2のコード分析・直近関連変更で、この Issue の前提として先に片付けるべき Open な作業（Issue、または未マージ PR に紐づく Issue）や、この Issue が完了しないと進められない既存 Open Issue が判明したら候補にする。関連しそうな Open Issue の探索には
gh issue list --state open --search "<キーワード>" を使ってよい。
- 現在状態の検証: 候補の Issue 番号は必ず
gh issue view <番号> --json number,state,title で Open であることを確認する。CLOSED の Issue は relationship に含めない（gh issue create の検証で失敗する、または意味を成さないため）。
- 方向の確定:
- blocked_by（この新Issueをブロックする＝先に片付けるべき既存Issue）: この新Issueに着手する前に完了している必要がある Open Issue の番号。
- blocking（この新Issueがブロックする＝後続で待たせる既存Issue）: この新Issueが完了しないと進められない既存 Open Issue の番号。
依存関係が1件も無ければ、ステップ3の YAML から blocked_by / blocking を省略する（無理に紐付けない）。
完了条件: 上記5項目が揃い、対象ファイルの直近関連変更と依存関係（blockedBy / blocking の有無）が把握できていること。揃わない場合でも追加調査せず、不足分は「不明」として次に進む。
3. post-issue-body スキルで Issue を作成
ステップ1・2の分析結果を 以下の YAML ブロックの形でそのまま args として Skill tool で post-issue-body を起動する（post-issue-body は args を YAML として機械的にパースする規約）。
mode: create
title: <タスクの目的が分かる簡潔なタイトル>
sections:
概要: |
（1-3行）
要件: |
- ...
（無ければ "なし"）
参照情報: |
- ドキュメント: `<path>` — <説明>
（ステップ1で読んだ参照、無ければ "なし"）
直近関連変更: |
- `<commit hash>` <subject> — <影響>
（ステップ2で確認した結果、無ければ "該当なし"）
実装プラン: |
1. フェーズ1
2. フェーズ2
影響範囲: |
- `<path>` — <概略>
new_changelog_entry: 初版作成 — <タスクの概要を一言>
labels:
- cc-triage-scope
- cc-issue-created
confirmation_items:
- <人の意思決定でしか決まらない未確認事項1>
- <人の意思決定でしか決まらない未確認事項2>
blocked_by: [<この新Issueをブロックする＝先に片付けるべき既存Issue番号>, ...]
blocking: [<この新Issueがブロックする＝後続で待たせる既存Issue番号>, ...]
labels には cc-triage-scope と cc-issue-created の2つを必ず入れる（このスキルで作成する Issue は「explore-agent 分析済み（cc-issue-created）」かつ「人間の triage 待ち（cc-triage-scope）」の両方の性質を持つため、後続スキルが両方のラベルで拾えるようにする）。assignee は post-issue-body が gh api user --jq '.login' で取得した gh ログインユーザーを自動で紐づけるため、本スキルから渡す必要はない。
Skill tool 呼び出しは Skill(skill='post-issue-body', args=<上記YAML文字列>)（必要なら plugin namespace 付きで claude-task-worker:post-issue-body）。args は改行を含む複数行文字列としてそのまま渡す。本文整形・投稿前チェック・gh issue create（--label cc-triage-scope --label cc-issue-created --assignee <gh ログインユーザー> 付き）の実行、確認事項があればコメント投稿までを post-issue-body が担う。完了後、Issue URL と確認事項コメントの有無が返ってくる。
post-issue-body の失敗（gh コマンド失敗・本文チェック不通過の解消不能等）はそのまま本スキルの中断条件となる。エラーメッセージを最終報告に含めて中断する。
4. 最終報告
post-issue-body から返ってきた Issue URL と、確認事項コメントの有無を1-3行で報告して終了する。
中断条件
以下のいずれかに該当する場合のみ、理由を出力して即中断する。それ以外は自律的に判断して続行する。
- 引数が空、または意味のあるタスク説明を含まない
- 引数がIssue番号（数値のみ・
#付き数値・Issue URL）→ /create-issue-from-issue-number または /update-issue を案内して終了
post-issue-body が失敗し、再試行しても解消しない
注意事項
- このスキルはコードを一切変更しない。Issue の作成・コメントは
post-issue-body 経由で行い、本スキル内で直接 gh issue create を呼ばない
- 作成する Issue には常に
cc-triage-scope と cc-issue-created の2ラベルを付与する。post-issue-body への YAML から labels キーを落とさず、2件とも入っていることを毎回確認すること
- 作成する Issue が Open な既存Issueと依存関係を持つ場合は、「依存関係の特定」で洗い出した番号を
post-issue-body の blocked_by / blocking に渡し、GitHub ネイティブ relationships として貼る（本文に ## 依存関係 は書かない）。根拠が明確な依存のみを対象にし、無ければ省略する
- 途中でユーザーに質問しない。確認したいことは
post-issue-body へ「確認事項」として渡し、コメントとして残す。ただし渡すのは「確認事項の取捨選択」を通過した項目だけで、調査で自明に決まる点は確認事項にせず description 側へ結論を書く（0件ならコメントは投稿しない）
- Pencil ファイル（
.pen）の読み込みは inspect-pencil-node スキル経由でのみ行う（暗号化バイナリのため Read/Grep は使えない）
.pen の編集は本スキルでは絶対に行わない。必要と判明した場合は pencil-design-updater エージェントで対応する旨を post-issue-body 経由で「実装プラン」または「確認事項」に明記して後続タスクへ委譲する（.pen 編集は pencil-design-updater 専任・edit-pencil-design スキル経由の運用に集約されており、手で pencil コマンドを直接組み立てたり frontend-implementer/general-purpose-assistant 等で代用したりしない）
