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

GitHub アクセス

本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。

生成する description のスコープと分量

description は人間がレビューし、後続の exec-issue が実装スコープとして読む成果物である。引数のタスク説明にある要求を実装可能な形へ具体化するのが本スキルの仕事であり、要求を増やす場ではない。

• 依頼に無い要件・タスクを足さない: 分析中に気づいた別の改善（周辺のリファクタ、テスト整備など）を要件や実装プランへ混ぜない。実装スコープが膨らみ、exec-issue が依頼外の変更を行う起点になる。書くとしても「確認事項」に1行で挙げるに留める
• 各セクションは内容がある分だけ書く: 「概要」は1〜3行、「影響範囲」は主要ファイル最大10件、「参照情報」「直近関連変更」は該当があるものだけ。埋めるための無内容な行・言い換えを書かない
• 最終報告は結論から1〜3行（詳細は「4. 最終報告」）

フェーズ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. タスクの分析（参考情報の収集）

タスクの背景を理解するために、存在するもののみを読み込む。存在しないパスは黙ってスキップする。

• .claude/requirements/ 配下の要件ルール: 後述の「要件ルールの参照」に従って読み込む
• docs/ 配下のドキュメント: ls docs/ 2>/dev/null で存在確認した上で、タスクに関係しそうなファイルを読む
• design/ 配下の Pencil ファイル（.pen）: ls design/ 2>/dev/null で存在確認した上で、inspect-pencil-node スキルで対象Nodeの属性データとスクリーンショットを取得して確認する。編集が必要と判明した場合の扱いは「注意事項」の .pen 規定に従う（本スキル内では編集しない）
• 上記およびタスク説明中に現れる外部リンク: 後述の「外部リンクの参照」に従って内容まで読む

外部リンクの参照（gh とローカルファイルで完結させない）

タスク説明・docs/・README・.claude/requirements/・コード内コメント・設定ファイルには、判断の根拠がリポジトリ外にあるリンク（仕様書・API仕様・ライブラリ公式ドキュメント・別リポジトリのIssue/PR・デザインURLなど）が置かれていることがある。gh とローカルファイルだけで調べて「不明」「確認事項」に倒すと、リンク先に答えが書いてあるのに人へ差し戻すことになる。リンク先の内容まで読んで結論を確定させる。

1. 収集: ステップ1で読んだ範囲とステップ2で explore-agent が返した対象ファイルに現れる URL を洗い出す
2. 取捨選択: 全部は開かない。今回の要件・実装プラン・確認事項の結論が変わりうるリンクだけを対象にする（バッジ画像・ライセンス・無関係な記事は開かない）
3. 取得: 種類ごとに手段を使い分ける
   • 一般のWebページ・仕様書・記事 → WebFetch
   • ライブラリ/フレームワークの公式ドキュメント → check-library スキル（Next.js / shadcn / context7 MCP を使い分ける）。バージョン差のあるAPI仕様を検索結果の要約で代用しない
   • GitHub上のIssue・PR → GitHub MCP が使える場合は issue_read / pull_request_read（method: get）を使う。利用不可なら gh issue view / gh pr view / gh api へフォールバック（GitHubのURLは WebFetch より確実）
   • GitHub上のファイル参照リンク（blob URL 等、別リポジトリ含む） → issue_read / pull_request_read はファイル内容を取得できないため使わない。GitHub MCP が使える場合は get_file_contents を使う。利用不可なら gh api repos/<owner>/<repo>/contents/<path> または WebFetch（raw URL）へフォールバック
   • Figma URL → Figma MCP（mcp__claude_ai_Figma__*）
   • リンク切れ・URLが古い → WebSearch で現行の一次情報を探す（見つからなければ深追いしない）
4. 深さの上限: リンク先からさらに辿るのは1段まで。それ以上は追わず、必要なら確認事項に回す
5. 記録: 判断に使ったリンクは「参照情報」に <URL> — <参照した要点> の形で残す（後続の exec-issue / answer-issue-questions が同じ根拠を辿れるようにするため）
6. 取得失敗: 認証必須・404・タイムアウトは1回だけ再試行し、それでも読めなければ推測で埋めず「<URL> は取得不可（理由）」と参照情報に明記する。そのリンクでしか決まらない論点は確認事項に残す

要件ルールの参照

.claude/requirements/ には、過去のIssueで確定した仕様・要件レベルの判断ロジックが要件タイプ別に集約されている（update-requirement-rules スキルが生成・維持する）。同じ判断を毎回再検討して結論がブレたり、既に決着している論点を確認事項として人へ差し戻したりしないよう、分析の前提として先に読む。

1. ls .claude/requirements/ 2>/dev/null で存在を確認する。無ければ黙ってスキップする
2. .claude/requirements/README.md（カテゴリ一覧）を読み、今回のタスクに関係するカテゴリを選ぶ
3. 選んだカテゴリファイルだけを Read で読む（全ファイルを読まない。無関係なカテゴリは判断材料にならず、コンテキストを圧迫するだけ）

読み取った内容の使い方:

• 該当するルールがある論点は、ルールの結論を採用して description に反映し、確認事項として起こさない（ルールは既に人が決めた結論であり、再確認は着手を無駄に止める）
• ルールを判断根拠に使った場合は、「参照情報」に .claude/requirements/<file>.md の該当ルール名を1行添える
• タスク説明がルールと矛盾する場合はタスク説明を優先する。ルールは過去の一般解であり、今回の明示的な依頼を上書きしない。矛盾は確認事項にせず、description の該当箇所へ「本Issueでは〜のため既存ルール『〜』とは異なる扱いとする」と1行残す
• 本スキルは .claude/requirements/ を編集しない。ルールの追加・修正が要ると判明した場合もその旨を1行記すに留める（更新は update-requirement-rules の責務）

タスク内容

$ARGUMENTS

2. コードの分析（explore-agent サブエージェントを使用）

explore-agent サブエージェントを起動し、以下を取得する。Agent ツールの effort は毎回指定する（explore-agent は定義に effort を持たない。基準は ${CLAUDE_PLUGIN_ROOT}/references/agent-effort.md）。影響範囲と類似実装の洗い出しは medium、依頼が複数モジュールにまたがる・呼び出し関係を複数段たどらないと影響範囲が決まらない場合は high。

• 影響範囲となる主要ファイル・ディレクトリ（最大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 に載せず、後述の「確認事項の取捨選択」で絞り込む）

サブエージェントへのプロンプトには「ユーザーには質問せず、調査結果を返却して終了する」ことと、上記の出力フォーマットに加えて、対象コード・ドキュメント中に外部URLが現れ、それが結論を左右する場合は WebFetch 等でリンク先の内容まで確認し、URLと参照した要点を返すことを明示する。

確認事項の取捨選択（自明なものは載せない）

explore-agent が挙げた候補をそのまま confirmation_items へ流さない。確認事項コメントは人の回答待ち（cc-answer-issue-questions）を発生させ、調査で答えが出るものを混ぜると着手が無駄に止まる。投稿前に1件ずつ判定し、以下に該当するものは確認事項から外し、結論と根拠を description（要件・実装プラン・参照情報）側へ書く。

• コード・ドキュメント・git履歴・gh コマンドで調べれば一意に決まる（既存実装・既存パターン・設定値・命名規約から導ける）
• 本文・docs・コード中のリンク先（外部仕様書・ライブラリ公式ドキュメント・別リポジトリのIssue/PR など）を読めば一意に決まる — 「外部リンクの参照」に従って読みに行き、確認事項からは外す
• .claude/requirements/ の要件ルールが結論を与えている（過去に人が決着させた判断の再確認になる）
• 本文の結論を裏付け直すだけの確認（「〜という理解で合っているか」「〜の方針でよいか」）
• どちらを選んでも要求を満たす実装判断 — 既存実装に倣った安全側の既定を選び、選んだ理由を実装プランに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 を確認する（GitHub MCP が使える場合は list_pull_requests / search_pull_requests を使う。以下はフォールバック）
• 直近 commit に大規模リファクタ・共通ヘルパー追加などの大きな変更が含まれる場合や、未マージの関連 PR がある場合は、その内容を post-issue-body に渡す「直近関連変更」セクション（必要に応じて「参照情報」にも）に必ず記載し、実装プランが既存実装と重複していないか検証する
• git 履歴のない新規機能要求など確認が困難なケースでは「該当なし」と記載してスキップしてよい

参照デザインの特定（## UIデザイン セクションの要否）

依頼の時点で「どのデザインを参照して実装するか」が具体的に示されているUI変更タスクは、その参照を description の ## UIデザイン セクションとして残す。triage-created-issue のパターンE-1は、このセクションに .pen の実パス行があることだけを「デザイン確定済み」の根拠とし、無ければデザイン先行フロー（cc-create-ui-design）へ振り分けるため、確定しているのにここへ書かないと不要なデザインPRが1本挟まる。

書き出す条件（すべて満たす場合のみ）

1. 依頼本文（$ARGUMENTS / Issue本文 / 参照コメント）が、実装対象のデザインを具体的に指している（.pen のパス・デザインファイル名・デザインPR番号・「〇〇画面のデザインのとおり」など、対象を一意に特定できる記述）

2. 指されたデザインがリポジトリに実在する。git ls-files '*.pen' の出力と突き合わせて実パスを確定する

   git ls-files '*.pen'
   

3. 確定した実パスが < / > を含まない実在パスとして書ける（プレースホルダにならない）

満たす場合は、ステップの YAML に ui_design を含めて post-issue-body へ渡す（design_file は必須、スナップショット（snapshots/ 配下の対応PNG）とデザインPR番号は分かる場合のみ）。デザインの中身は inspect-pencil-node スキルで確認してよいが、.pen は編集しない。

書き出さない場合（ui_design ごと省略する）

• 依頼が「デザインを作って実装」「UIはいい感じに」などデザイン未確定
• 指されたデザインがリポジトリに見つからない（実パスを確定できない）。この場合は「参照情報」に「依頼が参照するデザイン <名称> はリポジトリに見つからなかった」旨を1行残す
• そもそもUIを変更しないタスク

省略すればトリアージがデザイン先行フローへ振り分けるため、推測でパスを書かない（誤ったパスを書くと、存在しないデザインを参照したまま実装へ進む）。

依存関係の特定（blockedBy / blocking）

作成する Issue が他の Open な Issue と依存関係を持つ場合、GitHub ネイティブ relationships（blocked-by / blocking）で明示する。依存関係は本文の ## 依存関係 セクションには書かず、post-issue-body の blocked_by / blocking 経由で GitHub ネイティブ relationships として貼る（GitHub UI で関係性が表示され、本文との二重管理によるズレも避けられる）。

推測で無関係な Issue を紐付けないよう、根拠が明確なものだけを対象にする。

1. タスク説明中の明示的な参照: $ARGUMENTS に他の Issue/PR への言及（#123・Issue URL・「〇〇 の後に」「〇〇 が前提」「〇〇 をブロックする」等）があれば抽出する。
2. explore-agent・直近関連変更からの示唆: ステップ2のコード分析・直近関連変更で、この Issue の前提として先に片付けるべき Open な作業（Issue、または未マージ PR に紐づく Issue）や、この Issue が完了しないと進められない既存 Open Issue が判明したら候補にする。関連しそうな Open Issue の探索には gh issue list --state open --search "<キーワード>" を使ってよい（GitHub MCP が使える場合は list_issues / search_issues を使う。以下はフォールバック）。
3. 現在状態の検証: 候補の Issue 番号は必ず gh issue view <番号> --json number,state,title で Open であることを確認する（GitHub MCP が使える場合は issue_read（method: get）を使う。以下はフォールバック）。CLOSED の Issue は relationship に含めない（gh issue create の検証で失敗する、または意味を成さないため）。
4. 方向の確定:
   • 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>` — <説明>
    - 外部: <URL> — <参照した要点>
    （ステップ1で読んだ参照・辿った外部リンク、無ければ "なし"）
  直近関連変更: |
    - `<commit hash>` <subject> — <影響>
    （ステップ2で確認した結果、無ければ "該当なし"）
  実装プラン: |
    1. フェーズ1
    2. フェーズ2
  影響範囲: |
    - `<path>` — <概略>
ui_design:  # 任意。「参照デザインの特定」で実パスまで確定できた場合のみ。確定できなければキーごと省略する
  design_file: <リポジトリに実在する `.pen` の実パス>
  snapshots:  # 任意。対応する snapshots/ 配下のPNGが分かる場合のみ
    - <PNG パス>
  design_pr: <デザインPR番号>  # 任意。分かる場合のみ
new_changelog_entry: 初版作成 — <タスクの概要を一言>
labels:
  - cc-triage-scope
  - cc-issue-created
confirmation_items:  # 「確認事項の取捨選択」を通過した項目のみ。0件ならキーごと省略
  - <人の意思決定でしか決まらない未確認事項1>
  - <人の意思決定でしか決まらない未確認事項2>
# 依存関係は GitHub ネイティブ relationships で表現する（「依存関係の特定」で洗い出した Open な既存Issue番号）。
# 依存が無ければ項目ごと省略する（空配列や null を入れない）。
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（上記2ラベルと assignee 付き）・確認事項のコメント投稿までを 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 を呼ばない
• .claude/requirements/ の要件ルールは仕様作成の前提として読み込むが、編集はしない（「要件ルールの参照」参照）
• 結論を左右する外部リンクは「外部リンクの参照」に従って中身まで読み、使ったURLと要点を「参照情報」に残す
• 作成する Issue には常に cc-triage-scope と cc-issue-created の2ラベルを付与する。post-issue-body への YAML から labels キーを落とさず、2件とも入っていることを毎回確認すること
• Open な既存Issueとの依存関係は「依存関係の特定」に従い blocked_by / blocking で渡す（本文に ## 依存関係 は書かない。根拠が明確な依存のみ、無ければ省略）
• 確認事項として渡すのは「確認事項の取捨選択」を通過した項目のみ（0件ならコメントは投稿しない）
• .pen は平文JSONなので Read / jq で読める（構造は ${CLAUDE_PLUGIN_ROOT}/references/pen-format.md）。レイアウト解決後の値やスクリーンショットが必要なら inspect-pencil-node スキルを使う。編集は本スキルでは絶対に行わず、cc-create-ui-design のデザイン先行フロー（create-ui-design → デザインPRのマージ → apply-ui-design）で対応する旨を post-issue-body 経由で「実装プラン」に明記する。既に実在するデザインを参照して実装する依頼の場合は、「参照デザインの特定」に従って ui_design を渡し、description に ## UIデザイン セクションを残す（デザイン先行フローを挟まずに実装へ進める唯一の経路）。.pen の新規作成・編集は同フローの専任であり、実装PR（exec-issue）では行わないため、「実装と同じPRで .pen を更新する」「pencil-design-updater エージェントで更新する」といった実装セッション向けの指示は書かない