Create Issue Skill | Agent Skills

Create Issue

引数で受け取った内容をもとに要件を整理し、GitHub Issueを作成（または更新）するためのスキルです。 Instructionsの順に最後まで自律的に実行してください。

自律実行原則: このスキルはユーザーへの確認を行わず、判断はすべて本スキル内のルールに従って自動で決定する。途中で質問せず、確認したいことがあれば最後にIssueへのコメントとして残す。中断条件に該当した場合のみ、理由を出力して終了する。

Instructions

フェーズ0: 引数判定と事前チェック

0-1. 引数の分類

$ARGUMENTS を以下のいずれかに分類する。判定は機械的に行い、ユーザーに確認しない。

既存Issue更新: 引数が「数値のみ」「#付き数値」「GitHubのIssue URL（.../issues/<番号>）」のいずれかにマッチする場合 → Issue番号を抽出して「既存Issue更新フロー」へ
新規Issue作成: それ以外（タスク説明文と解釈）→「新規Issue作成フロー」へ

0-2. 作業ディレクトリの確認

pwd を実行し、結果に応じて以下を判定する。worktreeを新たに作成しないこと。

.claude/worktrees/ 配下にいる → そのworktree内で作業
それ以外（リポジトリのルート等）→ その場で作業

0-3. デフォルトブランチの安全な同期（fail-safeにスキップ可）

以下を順に試行し、失敗しても中断せずスキップして続行する。本スキルはコード変更を伴わないため、最新化に失敗しても作業継続できる。

git fetch --prune || true

git rebase や git pull は実行しない（未コミット変更や conflict による中断を避けるため）。

完了条件: 引数の分類結果（新規 or 既存）と Issue番号（既存の場合）が確定し、作業ディレクトリが特定されていること。

新規Issue作成フロー

1. タスクの分析（参考情報の収集）

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

docs/ 配下のドキュメントファイル: ls docs/ 2>/dev/null で存在確認した上で、タスクに関係しそうなファイルを読む
design/ 配下の Pencil ファイル（.pen）: ls design/ 2>/dev/null で存在確認した上で、pencil MCP（mcp__pencil__open_document 等）で読む。Pencilファイルは encrypted のため Read/Grep は使わない

タスク内容

$ARGUMENTS

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

Explore サブエージェントを起動し、以下を取得する。

影響範囲となる主要ファイル・ディレクトリ（最大10件）
既存の類似実装の参照先（最大5件、ファイルパスと役割の1行説明）
タスク達成に必要な変更の概略（フェーズ分け可能なら3段階以内）
不確実性・確認事項のリスト（推測で埋めず、Issueに残す前提）

サブエージェントへのプロンプトには「ユーザーには質問せず、調査結果を返却して終了する」ことと、上記の出力フォーマットを明示する。

完了条件: 上記4項目が揃っていること。揃わない場合でも追加調査せず、不足分は「不明」として次に進む。

3. GitHub Issue の作成

Issue 本文のテンプレート

以下の構造で本文を組み立てる。

## 概要
（タスクの目的と達成すべきゴール）

## 要件
- （機能要件・非機能要件を箇条書き）

## 参照情報
- ドキュメント: `<path>` — <関連箇所の説明>
- デザイン: `<path>` — <関連箇所の説明>

## 実装プラン
1. （フェーズ1）
2. （フェーズ2）
3. （フェーズ3）

## 影響範囲
- `<path>` — <変更の概略>

作成コマンド（heredoc で本文を渡す）

--body "..." 形式は本文中のバッククォート・$・!・改行で頻繁にエスケープに失敗するため、必ず --body-file - + heredoc を使う。'EOF' のようにクォートで囲み、シェル展開を抑止する。

ME=$(gh api user --jq '.login')

gh issue create \
  --title "<タイトル>" \
  --assignee "$ME" \
  --label "cc-issue-created" \
  --body-file - <<'EOF'
## 概要
...

## 要件
- ...

## 参照情報
- ...

## 実装プラン
1. ...

## 影響範囲
- ...
EOF

作成成功時、コマンドが返す Issue URL を保持する（後続のコメントで使う）。

完了条件: gh issue create が成功し、Issue URL が取得できていること。失敗した場合はエラーメッセージを最終報告に含めて中断する。

4. 確認事項のコメント投稿

ステップ2で抽出した「不確実性・確認事項」が1件以上ある場合のみ、Issue にコメントする。0件ならスキップする。

gh issue comment <Issue番号> --body-file - <<'EOF'
## 確認事項
- <質問1>
- <質問2>
EOF

完了条件: 確認事項が0件か、もしくはコメント投稿が成功していること。

5. 最終報告

作成した Issue の URL と、確認事項コメントの有無を1-3行で報告して終了する。

既存Issue更新フロー

1. 既存Issueの取得

gh issue view <Issue番号> --json number,title,state,labels,body,url

state が CLOSED の場合は更新せず、その旨を報告して終了する。

2. タスクの分析

新規作成フローのステップ1と同じ手順で docs/ と design/ を読み込む（存在するもののみ）。

3. コードの分析

新規作成フローのステップ2と同じ手順で Explore サブエージェントを起動する。スコープは「既存Issueのtitle/bodyに記述されている内容」を基準にする。

4. GitHub Issue の更新

既存の Issue 構造を尊重しつつ、分析結果を反映したタイトルと本文に更新する。本文テンプレートは新規作成フローのステップ3と同じ。

更新コマンド（heredoc で本文を渡す）

gh issue edit <Issue番号> \
  --title "<更新後タイトル>" \
  --add-label "cc-issue-created" \
  --body-file - <<'EOF'
## 概要
...

## 要件
- ...

## 参照情報
- ...

## 実装プラン
1. ...

## 影響範囲
- ...
EOF

--remove-label は使用しない（既存ラベルは保持する）。

完了条件: gh issue edit が成功していること。

5. 確認事項のコメント投稿

新規作成フローのステップ4と同じ手順でコメントする。0件ならスキップ。

6. 最終報告

更新した Issue の URL と、確認事項コメントの有無を1-3行で報告して終了する。

中断条件

以下のいずれかに該当する場合のみ、理由を出力して即中断する。それ以外は自律的に判断して続行する。

引数が空、または Issue番号も意味のあるタスク説明も含まない
gh issue view（既存Issue更新フロー時）で対象 Issue が見つからない
gh issue view の結果が CLOSED
gh issue create / gh issue edit が失敗し、再試行しても解消しない

注意事項

このスキルはコードを一切変更しない。Issue の作成・更新・コメントのみを行う
gh コマンドの本文渡しは必ず --body-file - + heredoc（<<'EOF' ... EOF）を使う。--body "..." は本文中の特殊文字でエスケープが頻繁に壊れるため使わない
途中でユーザーに質問しない。確認したいことは Issue へのコメントとして最後に残す
Pencil ファイル（.pen）は pencil MCP 経由でのみ読む。Read/Grep は使わない

Agent Skills: Create Issue

Install this agent skill to your local

Skill Files