github-issues

GitHub（または GitLab）のイシューを作成、更新、照会し、コメントを追加します。

ルールの概要

ルール	影響度	ファイル
イシューのタイトル	HIGH	rules/issue-title.md
テンプレートの遵守	MEDIUM	rules/template-adherence.md
チェックリストの禁止	MEDIUM	rules/no-checklists.md

CLI と MCP の優先順位

ネイティブで対応しているすべての操作には CLI（gh/glab）を使用してください。このスキルでは、CLI をデフォルトのインターフェースとします。ネイティブの CLI サブコマンドがない操作（現在はイシューフィールド — イシューに設定する優先度、工数、日付、カスタムメタデータなど）については、次の順にフォールバックします。

1. 接続されている場合は GitHub MCP サーバーのツールを使用します。Claude Code では通常、ツール名は mcp__github__*（list_issue_fields、issue_read、issue_write）ですが、名前はサーバーの登録方法によって異なります。特定の ID ではなく、機能を基準に検出してください。サーバーが利用可能だと決めつけないでください。このスキルでは MCP ツールの使用を事前承認しません。ホストが許可を求めるため、許可するかどうかはユーザーが決定します。
2. REST API に対して gh api を実行し、-H "X-GitHub-Api-Version: 2026-03-10" を送信します。
   • フィールドの一覧表示：gh api orgs/{org}/issue-fields（read:org が必要）。各フィールドの数値の id、name、data_type（text、number、date、single_select、multi_select）、および options[].name が返されます。
   • イシューの値の読み取り：gh api repos/{owner}/{repo}/issues/{number}/issue-field-values
   • 他の値に触れずに値を追加または更新するには、同じパスに --input - と本文 {"issue_field_values":[{"field_id":1,"value":"High"}]} を指定して POST します。単一選択ではオプションの名前、複数選択では名前の配列、数値では数値、日付では YYYY-MM-DD を指定します。
   • 同じパスに対する PUT は、イシューのすべてのフィールド値を置き換えます。意図した操作でない限り、使用を避けてください。
   • 1 つのフィールドをクリアするには、DELETE repos/{owner}/{repo}/issues/{number}/issue-field-values/{field_id} を実行します（フィールドに値がない場合は 404）。
3. 問題がない範囲でスキップする：残りの操作を完了し、設定できなかったフィールドを報告して、GitHub MCP サーバーを接続すると型付きイシューフィールドを利用できることを伝えます。

ワークフロー

1. アクションを判断します：作成、更新、照会、またはコメント
2. git remote get-url origin からリモートホストを検出し（github.com → gh、gitlab.com → glab、デフォルトは GitHub）、以降はその CLI を使用します。オーナー／リポジトリ（またはグループ／プロジェクト）の情報を取得します。GitHub のみの機能である組織の Issue タイプ、Issue フィールド、サブ Issue、.github/ISSUE_TEMPLATE/ は GitLab にはありません。GitLab では Issue タイプ、Issue フィールド、サブ Issue の手順を省略し、.gitlab/issue_templates/ と説明内のチェックリストを使用してください
3. ホストで標準的な場所にある Issue テンプレートを確認します：GitHub では .github/ISSUE_TEMPLATE/ または .github/、GitLab では .gitlab/issue_templates/
4. 利用可能な組織の Issue タイプを一覧表示します（ユーザー所有のリポジトリでは失敗しますが、想定内なので、そのまま続行してください）
5. 上記の CLI と MCP の優先順位に従って、CLI にはネイティブのサブコマンドがないため、MCP サーバーまたは gh api を使用し、利用可能な Issue フィールド（組織レベルで、リポジトリに継承されます）を一覧表示します（ユーザー所有のリポジトリでは失敗しますが、想定内なので、そのまま続行してください）。組織には次の 4 つのデフォルトがあります：Priority（単一選択：Urgent、High、Medium、Low）、Effort（単一選択：High、Medium、Low）、Start date、Target date。存在する可能性が高いものとして扱いつつ、実行時に確認してください。組織によって名前が変更されたり、削除されたり、選択肢が追加されたりしている場合があります
6. 作成または更新の場合：
   • 更新の場合：まず現在の Issue を取得します
   • Issue タイプが利用可能な場合は、最も適切なタイプを選択します（例：不具合には Bug、新機能には Feature、一般的な作業には Task）
   • ユーザーがフィールド値（優先度、作業量、日付、カスタム値）を指定した場合は、上記の CLI と MCP の優先順位に従って設定します。値はフィールドで宣言された型（単一選択のオプション名、テキスト、数値、YYYY-MM-DD 形式の日付）に一致させる必要があります
   • Priority と Effort が存在し、ユーザーが指定していない場合は、Issue の内容からそれぞれの値を提案します。Priority は重大度と影響範囲、Effort は変更に必要な作業の想定範囲に基づき、選択した値を伝えてください。Issue の内容が曖昧すぎて判断できない場合は、推測せずにフィールドを未設定のままにします。ユーザーから依頼がない限り、日付は設定しないでください
   • rules/issue-title.md に従ってタイトルを生成します
   • テンプレートが見つかった場合はそれに従って本文を生成し（rules/template-adherence.md を参照）、見つからない場合は明確で構造化された形式を使用します
   • 作成の場合：現在認証されているユーザーを取得し、担当者に含めます
   • ユーザーが親 Issue を指定した場合は、作成または更新した Issue をサブ Issue としてリンクします（Issue の番号ではなく、node ID を使用してください）
7. 親 Issue／サブ Issue の管理の場合：
   • サブ Issue を一覧表示するには：親 Issue のサブ Issue を取得します
   • サブ Issue を追加するには：親の Issue 番号と子の node ID を渡します
   • サブ Issue を削除するには：親から子のリンクを解除します
   • サブ Issue の順序を変更するには：after_id または before_id を指定して優先順位を変更します
   • 関連する Issue を複数作成する場合は、個別の Issue として並べるのではなく、親 Issue とサブ Issue の構成にすることを優先します
8. 照会の場合：
   • 番号を指定して特定の Issue を取得します
   • 親 Issue のサブ Issue 階層を調べます
   • フィルター、キーワード、リポジトリをまたぐ検索には Issue を検索します
   • Issue フィールドの値で絞り込みます（MCP の field_filters または API を使用します。ネイティブの CLI 相当機能はありません。上記の優先順位に従って、利用できない場合は適切に対応してください）
   • リポジトリの Issue を一覧表示します
9. コメントの場合：
   • 必要に応じて、まず Issue のコンテキストを取得します
   • Issue にコメントを追加します
10. Issue へのリンクと変更内容を含む概要を表示します

検証

• タイトル：rules/issue-title.md に従います
• テンプレートがある場合の本文：rules/template-adherence.md に従います
• ラベル：リポジトリに既に存在するラベルのみを使用します
• フィールド：組織またはリポジトリに既に存在するフィールドのみを設定します。フィールド名や単一選択のオプションを決して新たに作り出さないでください
• 担当者：リポジトリで有効なコラボレーターのみを割り当てます