create-issue

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 を紐付けないよう、根拠が明確なものだけを対象にする。

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 "<キーワード>" を使ってよい。
3. 現在状態の検証: 候補の Issue 番号は必ず gh issue view <番号> --json number,state,title で Open であることを確認する。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>` — <説明>
    （ステップ1で読んだ参照、無ければ "なし"）
  直近関連変更: |
    - `<commit hash>` <subject> — <影響>
    （ステップ2で確認した結果、無ければ "該当なし"）
  実装プラン: |
    1. フェーズ1
    2. フェーズ2
  影響範囲: |
    - `<path>` — <概略>
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（--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 等で代用したりしない）