issue-create

Issue Create スキル

AI によるラベルの提案、コンテンツタイプの検出、テンプレートの書式設定、関連する issue のリンクなど、インテリジェントな自動化を活用して、書式の整った GitHub issue を作成します。

自己進化型スキル：このスキルは使用を通じて改善されます。指示が間違っている場合、パラメーターにずれが生じた場合、または回避策が必要になった場合は、先送りせず、このファイルをすぐに修正してください。実際に再現できる問題がある場合にのみ更新してください。

このスキルを使うタイミング

次の場合にこのスキルを使います。

• バグ報告、機能リクエスト、質問、ドキュメントに関する issue を作成するとき
• リポジトリに既存の分類体系に基づく AI によるラベルの提案が必要なとき
• 重複の自動検出や関連する issue のリンクを行いたいとき
• 複数のリポジトリで一貫した issue の書式が必要なとき

呼び出し方法

スラッシュコマンド：/gh-tools:issue-create

自然言語でのトリガー：

• 「〜について issue を作成して」
• 「〜のバグを報告して」
• 「機能リクエストを送信して」
• 「この問題を〜に報告して」
• 「GitHub に issue を投稿して」

機能

1. リポジトリの検出

• 現在の Git ディレクトリからリポジトリを自動検出します
• 明示的な --repo owner/repo フラグをサポートします
• 作成を試みる前に権限を確認します

2. コンテンツタイプの検出

• AI による検出（gh-models 経由の gpt-4.1）
• キーワードマッチングによるフォールバック
• タイプ：バグ、機能、質問、ドキュメント

3. タイトルの抽出

• 内容から情報量の多いタイトルを抽出します
• タイプのプレフィックスを追加します（Bug:、Feature: など）
• 情報量の多いタイトルにできるよう、GitHub の256文字制限を最大限に活用します

4. 本文の最大文字数（65,536文字）

GitHub の issue 本文は65,536文字まで対応しています（バイト数ではありません。UTF-8 のマルチバイト文字も1文字として数えます）。複数の issue やコメントに分割せず、1つの投稿に収めることを常に目指してください。

基本方針：断片的な投稿を複数作るより、包括的な投稿を1つ作る方が有益です。分析、背景、経緯、複数の観点からの推論を、できるだけ1つの issue 本文またはコメントに盛り込んでください。

長文の issue 内容を作成する場合：

• 残り容量を確認する：echo "$BODY" | wc -m（バイト数ではなく文字数）
• GFM のレンダリングにおける特殊なケースに備えて余裕を残すため、約60,000文字を目標にします
• 折りたたみ可能なセクション（<details><summary>）を、密度の高い参考資料に使います。文字数の上限は変わりませんが、読みやすさが向上します
• すべての観点を含める：issue で意思決定を記録する場合は、検討した代替案、トレードオフ、賛否を裏付ける根拠、採用した案が選ばれた理由を含めます
• 経緯を埋め込む：時系列、先行事例、関連する issue へのリンク、セッションの来歴などは、すべて1つの投稿に含めます
• 事前に分割しない：実際に65,536文字を超える場合にのみ分割します（まれなケースです）

投稿前のサイズ確認パターン：

# Build body, then verify it fits
BODY=$(cat <<'EOF'
... your content ...
EOF
)
CHARS=$(echo "$BODY" | wc -m | tr -d ' ')
echo "Body size: ${CHARS}/65536 chars"
if [ "$CHARS" -gt 65536 ]; then
  echo "WARNING: Exceeds limit by $((CHARS - 65536)) chars — trim or split"
fi

5. テンプレートの書式設定

• コンテンツタイプに基づいてテンプレートを自動選択します
• バグ：再現手順、期待される動作／実際の動作
• 機能：ユースケース、提案する解決策
• 質問：背景、試したこと
• ドキュメント：場所、変更案

5. ラベルの提案

• リポジトリに既存のラベルを取得します
• AI が関連するラベルを2～4個提案します
• 実在するラベルのみを提案します（分類体系を考慮）
• パフォーマンス向上のため、24時間キャッシュします

6. 関連する issue

• 類似する issue を検索します
• 本文に関連する issue へのリンクを追加します
• 重複の可能性がある場合に警告します

7. プレビューと確認

• 作成前に全体をプレビューできます
• ドライランモードを利用できます
• 修正のための編集オプションがあります

使用例

基本的な使い方

# From within a git repository
bun ~/eon/cc-skills/plugins/gh-tools/scripts/issue-create.ts \
  --body "Login page crashes when using special characters in password"

リポジトリを明示して指定

bun ~/eon/cc-skills/plugins/gh-tools/scripts/issue-create.ts \
  --repo owner/repo \
  --body "Feature: Add dark mode support for better accessibility"

ドライラン（プレビューのみ）

bun ~/eon/cc-skills/plugins/gh-tools/scripts/issue-create.ts \
  --repo owner/repo \
  --body "Bug: API returns 500 error" \
  --dry-run

カスタムタイトルとラベルを指定

bun ~/eon/cc-skills/plugins/gh-tools/scripts/issue-create.ts \
  --repo owner/repo \
  --title "Bug: Login fails with OAuth" \
  --body "Detailed description..." \
  --labels "bug,authentication"

AI 機能を無効化

bun ~/eon/cc-skills/plugins/gh-tools/scripts/issue-create.ts \
  --body "Question: How to configure..." \
  --no-ai

CLI オプション

オプション	短縮形	説明
--repo	-r	owner/repo 形式のリポジトリ
--body	-b	Issue の本文（必須）
--title	-t	Issue のタイトル（任意）
--labels	-l	カンマ区切りのラベル
--dry-run		作成せずにプレビュー
--no-ai		AI 機能を無効化
--verbose	-v	詳細な出力を有効化
--help	-h	ヘルプを表示

依存関係

• gh CLI（必須） - GitHub CLI ツール
• gh-models 拡張機能（任意） - AI 機能を有効化します

gh-models のインストール

gh extension install github/gh-models

権限の処理

レベル	動作
WRITE/ADMIN	すべての機能を利用できます
TRIAGE	ラベルを適用できます
READ	手動コピー用に整形された内容を表示します
NONE	フォークのワークフローを提案します

ログ

ログの保存先：~/.claude/logs/gh-issue-create.jsonl

記録されるイベント：

• preflight - 初期チェック
• type_detected - コンテンツタイプの検出
• labels_suggested - ラベルの提案
• related_found - 関連 Issue の検索
• issue_created - 作成成功
• dry_run - ドライランの完了

関連ドキュメント

• コンテンツタイプのリファレンス
• ラベル戦略のリファレンス
• AI プロンプトのリファレンス

Issue への画像の埋め込み

GitHub Issues には、プログラムで画像をアップロードする API がありません。Web UI のドラッグ＆ドロップでは、API クライアントには意図的に公開されていない内部 S3 ポリシーのフローが使用されます（cli/cli#1895）。

事前確認：画像にアクセスできることを確認する

?raw=true URL は github.com 経由で解決されます。リモート上のそのパスに画像が存在しない場合、エラーを出さずに 404 を返します（画像が表示されず、エラーもありません）。Issue を作成する前に、次の事前確認を実行してください。

# 1. Detect repo context
OWNER_REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
BRANCH=$(git rev-parse --abbrev-ref HEAD)
VISIBILITY=$(gh repo view --json visibility -q '.visibility')

# 2. Verify images are git-tracked (not gitignored)
IMG_DIR="path/to/images"
for f in ${IMG_DIR}/*.png; do
  git ls-files --error-unmatch "$f" >/dev/null 2>&1 \
    || echo "WARNING: $f is NOT tracked by git (check .gitignore)"
done

# 3. Verify images are committed (not just staged or untracked)
UNCOMMITTED=$(git diff --name-only HEAD -- "${IMG_DIR}/" 2>/dev/null)
UNTRACKED=$(git ls-files --others --exclude-standard -- "${IMG_DIR}/" 2>/dev/null)
if [[ -n "$UNCOMMITTED" || -n "$UNTRACKED" ]]; then
  echo "FAIL: Images not committed — commit and push first"
  echo "  Uncommitted: ${UNCOMMITTED}"
  echo "  Untracked:   ${UNTRACKED}"
  exit 1
fi

# 4. Verify commit is pushed to remote (local commits invisible to github.com)
LOCAL_SHA=$(git rev-parse HEAD)
REMOTE_SHA=$(git rev-parse "origin/${BRANCH}" 2>/dev/null)
if [[ "$LOCAL_SHA" != "$REMOTE_SHA" ]]; then
  echo "FAIL: Local commits not pushed — run: git push origin ${BRANCH}"
  exit 1
fi

# 5. Build image base URL
IMG_BASE="https://github.com/${OWNER_REPO}/blob/${BRANCH}/${IMG_DIR}"
echo "Image base URL: ${IMG_BASE}/<filename>.png?raw=true"
echo "Repo visibility: ${VISIBILITY}"
if [[ "$VISIBILITY" == "PRIVATE" ]]; then
  echo "NOTE: Images only visible to authenticated collaborators"
fi

事前確認のチェックリスト（各手順で確認できること）：

手順	確認項目	失敗時の状態
1	リポジトリのコンテキストが存在する	URL の構築に必要な OWNER_REPO がありません
2	画像が Git で追跡されている	.gitignore によって気づかないまま除外されています
3	画像がコミットされている	ステージ済み／未追跡のファイルはリモートに存在しません
4	コミットがプッシュされている	ローカルのみのコミットは github.com から見えません
5	URL の構築	ブランチ名が間違っていると 404 になります

URL 形式：?raw=true と raw.githubusercontent.com の違い

コミットしてプッシュ済みの画像には、raw.githubusercontent.com ではなく、github.com/blob/...?raw=true URL を使用してください。

![img](https://raw.githubusercontent.com/owner/repo/main/path/image.png)



![img](https://github.com/owner/repo/blob/main/path/image.png?raw=true)

スクリプトのパターン（複数の画像から Issue の本文を作成）：

IMG_BASE="https://github.com/${OWNER_REPO}/blob/${BRANCH}/${IMG_DIR}"

gh issue create --title "Feedback with screenshots" --body "$(cat <<EOF
## Item 1
![description](${IMG_BASE}/01-screenshot.png?raw=true)

## Item 2
![description](${IMG_BASE}/02-screenshot.png?raw=true)
EOF
)"

技術的な説明の全文は、GFM のアンチパターンの AP-07を参照してください。

リポジトリに含まれていない画像

ディスク上にのみある画像（コミットされていない画像）には、次の4つの方法があります。

方法	手順	永続性	事前チェック
先にコミットしてプッシュ	画像を git add してプッシュし、事前チェックを実行してから ?raw=true の URL を使用します	あり（リポジトリでホスト）	あり（5段階）
Web UI に貼り付け	ブラウザーで issue を開き、Ctrl/Cmd+V でコメント欄に画像を貼り付けます	あり（user-attachments CDN）	なし
Web UI にドラッグ＆ドロップ	画像ファイルをコメント欄にドラッグします	あり（user-attachments CDN）	なし
Playwright による自動化	スクリプトでブラウザーのファイル添付フローを自動化します	あり（user-attachments CDN）	なし

Playwright による自動化（CDN へのプログラムによるアップロード）

GitHub には画像アップロード用の API がありませんが、Playwright でブラウザーのファイル添付フローを自動化することで、コミットやプッシュ前の事前チェックなしに、永続的な user-attachments CDN URL を取得できます。

ブラウザールート全般については、chrome-profiles を参照してください。

仕組み：

1. scripts/gh-issue-image-upload.ts は、永続プロファイル（~/.local/share/gh-issue-image-upload/profile。GH_ISSUE_IMAGE_PROFILE で変更可能）を使い、Playwright の Chromium で issue ページを開きます。次のコマンドで実行します：bun "$(cc-plugin-root gh-tools)/skills/issue-create/scripts/gh-issue-image-upload.ts" <issue-url> <image>...
2. 初回実行時のみ、ユーザーが GitHub にログインします（Google SSO、パスキー、パスワードなど、どの方法でも可）。Cookie は保持されます。
3. スクリプトが「Paste, drop, or click to add files」をクリックし、ファイル選択ダイアログを捕捉して、画像ファイルを指定します。
4. GitHub が S3 バックエンドにアップロードし、user-attachments CDN URL を含む <img> タグをコメント用テキストエリアに挿入します。
5. スクリプトが CDN URL を抽出し、テキストエリアをクリアします（コメントは実際には投稿されません）。

実装の主な詳細（GitHub の 2026 年版 React コメント作成画面）：

• コメント用テキストエリアのセレクター：textarea[placeholder="Use Markdown to format your comment"]（React の ID は動的に生成されるため、id では照合しないでください）
• ファイルアップロードのトリガー：「Paste, drop, or click to add files」のテキストをクリックし、page.waitForEvent("filechooser") で捕捉します
• アップロード結果の形式：<img width="W" height="H" alt="Image" src="https://github.com/user-attachments/assets/UUID" />（![](...) の Markdown ではなく、HTML の <img> タグ）
• 古い textarea#new_comment_field と file-attachment input[type='file'] のセレクターは、現在は存在しません
• 複数画像のアップロード：アップロードの間に textarea.fill("") でテキストエリアをクリアします

ブラウザールート：これは chrome-profiles の段階のうち2番目にあたります（Playwright 独自の Chromium を使用し、一度ログインします）。普段使っている Chrome から独立して動作します。GitHub に普段使いのプロファイルですでにログインしている場合は、代わりにそのプラグインの setup <email> で操作できます。デバッグポートと Chrome-136 の仕組みについては、ここではなく該当ドキュメントに記載されています。

---

トラブルシューティング

「リポジトリのコンテキストがありません」

git ディレクトリから実行するか、--repo owner/repo フラグを使用してください。

ラベルが候補に表示されない

• gh-models がインストールされているか確認します：gh extension list
• リポジトリにラベルがあることを確認します：gh label list --repo owner/repo
• ラベルのキャッシュを確認します：ls ~/.cache/gh-issue-skill/labels/

AI 機能が動作しない

gh-models 拡張機能をインストールします：

gh extension install github/gh-models

実行後の振り返り

このスキルの実行後、終了する前に次の点を確認してください。

1. コマンドは成功しましたか？ — 成功していない場合は、失敗の原因となった手順またはエラーテーブルを修正します。
2. パラメーターや出力に変更はありましたか？ — 基盤となるツールのインターフェースに変更があった場合は、使用例とパラメーターテーブルを更新して一致させます。
3. 回避策が必要でしたか？ — 別のフラグや追加手順など、その場で工夫する必要があった場合は、次回の実行で同じ回避策が不要になるよう、この SKILL.md を更新します。

問題が実際に発生し、再現可能な場合にのみ更新してください。推測で更新しないでください。