OpenSkillIndex← back to search
claude-code

Agent-almanac create-github-issues

install
source · Clone the upstream repo
git clone https://github.com/pjt222/agent-almanac
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/ja/skills/create-github-issues" ~/.claude/skills/pjt222-agent-almanac-create-github-issues-01b879 && rm -rf "$T"
manifest: i18n/ja/skills/create-github-issues/SKILL.md
source content

GitHub Issueの作成

レビュー結果やタスク分解から構造的にGitHub Issueを作成する。

review-codebase
、
security-audit-codebase
、または手動分析による調査結果のリストを、ラベル・受け入れ条件・相互参照を持つ適切に整形されたGitHub Issueに変換する。

使用タイミング

  • コードベースレビューが追跡が必要な調査結果テーブルを生成した後
  • 計画セッションでIssueにすべき作業項目が特定された後
  • TODOリストやバックログをGitHubの追跡可能なIssueに変換するとき
  • 一貫したフォーマットとラベル付けが必要な関連Issueをまとめて作成するとき

入力

  • 必須: 
    findings
    — 各アイテムに最低限タイトルと説明を含む項目のリスト。理想的には深刻度、影響を受けるファイル、提案ラベルも含む
  • 任意: 
    • group_by
      — 調査結果をIssueにまとめる方法: 
      severity
      （深刻度）、
      file
      （ファイル）、
      theme
      （テーマ）（デフォルト: 
      theme
      ）
    • label_prefix
      — 自動作成ラベルのプレフィックス（デフォルト: なし）
    • create_labels
      — 存在しないラベルを作成するか（デフォルト: 
      true
      ）
    • dry_run
      — Issueを作成せずにプレビューする（デフォルト: 
      false
      ）

手順

ステップ1: ラベルの準備

リポジトリに必要なラベルがすべて存在することを確認する。

  1. 既存ラベルを一覧表示: 
    gh label list --limit 100
  2. 調査結果が必要とするラベルを特定（深刻度、フェーズ、または明示的なラベルフィールドから）
  3. 深刻度をラベルにマッピング（未マッピングの場合）: 
    critical
    、
    high-priority
    、
    medium-priority
    、
    low-priority
  4. フェーズ/テーマをラベルにマッピング: 
    security
    、
    architecture
    、
    code-quality
    、
    accessibility
    、
    testing
    、
    performance
  5. create_labels
    がtrueの場合、不足ラベルを作成: 
    gh label create "name" --color "hex" --description "desc"
  6. 一貫した色を使用: critical/securityは赤、highはオレンジ、mediumは黄、architectureは青、testingは緑

期待結果： 調査結果が参照するすべてのラベルがリポジトリに存在する。重複したラベルが作成されていない。

失敗時： 

gh
CLIが認証されていない場合、ユーザーに 
gh auth login
の実行を指示する。ラベル作成が拒否された場合（権限不足）、ラベルなしで続行し、不足しているラベルを記録する。

ステップ2: 調査結果のグループ化

関連する調査結果を論理的なIssueにまとめてIssueの増殖を防ぐ。

  1. group_by
    が 
    theme
    の場合: フェーズまたはカテゴリ別にグループ化（すべてのセキュリティ調査結果 → 1〜2件のIssue、すべてのa11y → 1件のIssue）
  2. group_by
    が 
    severity
    の場合: 深刻度レベル別にグループ化（すべてのCRITICAL → 1件のIssue、すべてのHIGH → 1件のIssue）
  3. group_by
    が 
    file
    の場合: 主に影響を受けるファイルでグループ化
  4. 各グループ内で調査結果を深刻度順に並べる（CRITICAL優先）
  5. グループに8件を超える調査結果がある場合、サブテーマ別にサブグループに分割する
  6. 各グループが1件のGitHub Issueになる

期待結果： 関連する1〜8件の調査結果を含むIssueグループのセットが作成される。Issueの総数が管理可能な範囲（コードベースの完全レビューで通常5〜15件）になる。

失敗時： 調査結果にグループ化メタデータがない場合、調査結果1件につき1件のIssueにフォールバックする。これは少数の調査結果（10件未満）では許容されるが、多数の場合はIssueが多くなりすぎる。

ステップ3: Issueの構成

標準テンプレートを使用して各Issueを作成する。

  1. タイトル: 
    [深刻度] テーマ: 簡単な説明
    — 例: 
    [HIGH] Security: Eliminate innerHTML injection in panel.js
  2. 本文の構造: 
    ## Summary
One-paragraph overview of what this issue addresses and why it matters.

## Findings
1. **[SEVERITY]** Finding description (`file.js:line`) — brief explanation
2. **[SEVERITY]** Finding description (`file.js:line`) — brief explanation

## Acceptance Criteria
- [ ] Criterion derived from finding 1
- [ ] Criterion derived from finding 2
- [ ] All changes pass existing tests

## Context
Generated from codebase review on YYYY-MM-DD.
Related: #issue_numbers (if applicable)
  3. ラベルを適用: 深刻度ラベル + テーマラベル + カスタムラベル
  4. 調査結果が特定のファイルを参照する場合、本文に記載する（アサインとしてではなく）

期待結果： 各Issueに明確なタイトル、深刻度バッジ付きの番号付き調査結果、チェックボックス形式の受け入れ条件、適切なラベルが含まれている。

失敗時： 本文がGitHubのIssueサイズ制限（65536文字）を超える場合、Issueを複数のパートに分割して相互参照する。

ステップ4: Issueの作成

gh
CLIを使用してIssueを作成し、結果を報告する。

  1. dry_run
    がtrueの場合、各Issueのタイトルと本文を作成せずに出力して停止する
  2. 各構成済みIssueを作成する: 
    gh issue create --title "title" --body "$(cat <<'EOF'
body content
EOF
)" --label "label1,label2"
  3. 作成された各IssueのURLを記録する
  4. すべてのIssueを作成した後、概要テーブルを出力する: 
    #番号 | タイトル | ラベル | 調査結果の件数
  5. Issueの順序付けが必要な場合、相互参照を追加する: 最初のIssueを編集して「Blocked by #X」または「See also #Y」を記載する

期待結果： すべてのIssueが正常に作成される。Issue番号とURLを含む概要テーブルが出力される。

失敗時： 個別のIssue作成が失敗した場合、エラーをログに記録して残りのIssueの処理を続ける。最後に失敗を報告する。一般的な失敗原因: 認証の期限切れ、ラベルが見つからない（

create_labels
がfalseの場合）、ネットワークタイムアウト。

バリデーション

  • すべての調査結果が少なくとも1件のIssueに含まれている
  • 各Issueに少なくとも1つのラベルがある
  • 各Issueにチェックボックス形式の受け入れ条件がある
  • 重複したIssueが作成されていない（タイトルを既存のオープンIssueと照合）
  • 調査結果の件数に対してIssue数が適切である（大規模なセットで1:1になっていない）
  • すべてのIssueのURLを含む概要テーブルが出力された

よくある落とし穴

  • Issueの増殖: 調査結果1件につき1件のIssueを作成すると20件以上のIssueが生まれ管理が困難になる。積極的にグループ化すること — 完全なレビューからは5〜10件のIssueが理想的
  • 受け入れ条件の欠如: チェックボックスのないIssueは完了を検証できない。すべての調査結果は少なくとも1つのチェックボックスに対応させる
  • ラベルの混乱: ラベルを多く作りすぎるとフィルタリングが意味をなさなくなる。深刻度とテーマのみに絞り、調査結果ごとのラベルは避ける
  • 古い参照: 古いレビューからIssueを作成する場合、Issue作成前に調査結果が依然として該当するか確認する。コードが変更されている可能性がある
  • dry run忘れ: 大量の調査結果の場合、必ず先に 
    dry_run: true
    でプレビューする。計画の編集は15件の誤ったIssueをクローズするよりはるかに簡単

関連スキル

  • review-codebase
    — このスキルが取り込む調査結果テーブルを生成する
  • review-pull-request
    — IssueにもなりえるPRスコープの調査結果を生成する
  • manage-backlog
    — 作成後のIssueをスプリントと優先度に整理する
  • create-pull-request
    — Issueを参照してクローズするPRを作成する
  • commit-changes
    — Issueを解決する修正をコミットする