github-issues

GitHub Issues の管理

包括的なコンテキスト統合と構造化されたワークフローで、GitHub の Issue を作成、取得、更新、管理します。

前提条件

• gh（GitHub CLI）：すべての Issue 操作に必要です。https://cli.github.com または brew install gh からインストールしてください。

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

次の場合にこのスキルを有効にします：

• ユーザーが新しい GitHub Issue の作成を希望している
• ユーザーが Issue の詳細の表示または取得を求めている
• ユーザーが既存の Issue の更新を必要としている
• ユーザーがリポジトリ内の Issue の一覧表示を希望している
• ユーザーが GitHub での Issue、バグ報告、機能リクエストの管理に言及している
• ユーザーが Issue のクローズ、再オープン、またはプロパティの変更を希望している
• ユーザーが Issue へのコメントやラベルの追加を必要としている
• ユーザーが Issue の検索を希望している

重要なルール

重要：Issue を作成または変更する前に、必ず owner/repo を確認してください

常にわかりやすい Issue のタイトルを付け、構造化された説明を記載してください

Issue の重複作成は避けてください。適切な場合は、まず既存の Issue を検索してください

利用可能な CLI コマンド

コマンド	用途
gh issue create	新しい Issue を作成
gh issue edit <number>	既存の Issue を更新
gh issue view <number>	Issue の詳細を取得
gh search issues "<query>"	Issue を検索
gh issue comment <number>	コメントを追加
gh issue list	リポジトリの Issue を一覧表示

ワークフロー

1. コンテキストの収集

まず、現在のリポジトリとコンテキストに関する情報を収集します：

• リポジトリを特定します（owner と repo の名前）
• Issue の種類を把握します（バグ、機能、タスクなど）
• 該当する場合は、関連するラベル、マイルストーン、担当者を収集します

2. リポジトリの確認

操作を行う前に、正しいリポジトリ識別子であることを確認します：

• リポジトリが存在することを確認します
• リポジトリの構造を把握します
• 利用可能なラベルとマイルストーンを確認します

3. Issue の操作

新しい Issue の作成

Issue を作成する際は、必要なコンテキストをすべて収集します：

必須情報：

• owner：リポジトリの所有者（組織またはユーザー）
• repo：リポジトリ名
• title：明確でわかりやすい Issue のタイトル

任意ですが推奨される情報：

• body：Markdown 形式の詳細な説明
• labels：ラベル名（例：「bug,enhancement」）
• assignees：割り当てるユーザー名
• milestone：マイルストーン番号（整数）

人間が介在するプロセス — コンテキストを確認する

Issue の詳細を明確にするため、必ず質問してください：

Question: "What type of issue is this?"
Options:
- "Bug report - something is not working correctly"
- "Feature request - new functionality needed"
- "Task - work item to complete"
- "Documentation - documentation needs update"
- "Other - let me describe it"

タイトルのガイドライン：

• 有用な場合は、種類を示す接頭辞から始めます：[Bug]、[Feature]、[Docs]
• 具体的で、実行可能な内容にします
• 72 文字以内に収めます
• 例：
  • [Bug] Login fails with SSO enabled
  • [Feature] Add dark mode support
  • Add unit tests for auth module

Issue の説明テンプレート：

説明をわかりやすく構成します：

## Summary
[Brief description of the issue]

## Current Behavior
[What is happening now - for bugs]

## Expected Behavior
[What should happen - for bugs]

## Steps to Reproduce
[For bugs - numbered steps]

## Acceptance Criteria
[For features/tasks - what defines "done"]

## Additional Context
[Screenshots, logs, related issues, etc.]

Issue の詳細の取得

gh issue view <number> を次の情報とともに使用します：

• <number>：Issue 番号（例：42）

次の情報を含む、Issue の詳細がすべて返されます：

• タイトルと本文
• 状態（オープン／クローズ）
• ラベルとマイルストーン
• 担当者と作成者
• 作成日時／更新日時

Issue の一覧表示

gh issue list を次のフィルターとともに使用します：

• --state：「open」、「closed」、または「all」
• --label：ラベルで絞り込み（カンマ区切り）
• --assignee：担当者のユーザー名で絞り込み
• --search：タイトルと説明を検索
• --sort：「created」、「updated」、「comments」で並べ替え
• --order：「asc」または「desc」
• --limit：ページあたりの結果数（デフォルトは 30）

Issue の検索

高度なクエリには gh search issues "<query>" を使用します：

• 複数のリポジトリをまたいで検索します
• GitHub の検索修飾子を使用します（is:open、label:bug など）
• タイトルと本文を全文検索します

Issue の更新

Issue を更新する際は、変更するフィールドのみを指定します：

更新するフィールドのフラグ（--title、--body、--add-label、--remove-label、--add-assignee、--milestone など）を付けて gh issue edit <number> を使用します。

状態の変更：

• gh issue reopen <number> - Issue をオープン／再オープンします
• gh issue close <number> - Issue をクローズします

コメントの追加

gh issue comment <number> --body "<comment>" を使用します。

• <number>：Issue 番号
• <comment>：Markdown 形式のコメント内容

4. 操作を実行する（確認が必要です）

重要：Issue を作成または変更する前に、必ずユーザーに確認してください

必要な情報をすべて集めたら、ユーザーの承認を得るために概要を提示します。

Creating issue in repository: owner/repo
Title: [title]
Description: [summary]
Labels: [labels]
Assignee: [assignee]

Proceed with issue creation?

Issue の種類ごとのテンプレート

バグ報告

## Description
The [component] is experiencing [issue] when [condition].

## Steps to Reproduce
1. [First step]
2. [Second step]
3. [See error]

## Expected Behavior
[What should happen]

## Actual Behavior
[What actually happens]

## Environment
- Application Version: [version]

## Screenshots/Logs
[Attach relevant files]

## Possible Solution
[Optional: if you have ideas]

機能リクエスト

## Summary
[One-line description of the feature]

## Motivation
[Why is this feature needed? What problem does it solve?]

## Proposed Solution
[How should this work?]

## Acceptance Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]

## Alternatives Considered
[Other approaches considered]

## Additional Context
[Mockups, examples, references]

タスク

## Task Description
[What needs to be done]

## Background
[Why is this needed?]

## Requirements
- [ ] [Requirement 1]
- [ ] [Requirement 2]

## Definition of Done
- [ ] [Criterion 1]
- [ ] [Criterion 2]

## Dependencies
[Related issues, blockers]

例

例 1：バグ報告の作成

ユーザー：「バグの Issue を作成してください。SSO を使うとログインページがクラッシュします」

AI ワークフロー：

1. リポジトリ（owner/repo）が不明な場合は確認する
2. バグについて уточ認する質問をする
3. 構造化された説明を作成する
4. 確認のために概要を提示する
5. gh issue create --title "[Bug] Login page crashes when using SSO" --body "<description>" --label "bug" で Issue を作成する

結果：

gh issue create \
  --title "[Bug] Login page crashes when using SSO" \
  --body "## Description
The login page crashes when users attempt to authenticate using SSO.

## Steps to Reproduce
1. Navigate to login page
2. Click 'Sign in with SSO'
3. Page crashes

## Expected Behavior
SSO authentication should complete and redirect to dashboard.

## Actual Behavior
Page becomes unresponsive and displays error.

## Environment
- Browser: [To be filled]
- OS: [To be filled]" \
  --label "bug"

例 2：優先度を指定した機能リクエスト

ユーザー：「ダークモードの機能リクエストを高優先度で作成してください」

AI ワークフロー：

1. 機能の詳細を集める
2. リクエストを構成する
3. 適切なラベルを追加する
4. 確認して作成する

結果：

gh issue create \
  --title "[Feature] Add dark mode support" \
  --body "## Summary
Add dark mode theme option for improved user experience and accessibility.

## Motivation
- Reduces eye strain in low-light environments
- Increasingly expected by users
- Improves accessibility

## Proposed Solution
Implement theme toggle with system preference detection.

## Acceptance Criteria
- [ ] Toggle switch in settings
- [ ] Persists user preference
- [ ] Respects system preference by default
- [ ] All UI components support both themes" \
  --label "enhancement,high-priority"

例 3：Issue の一覧表示と絞り込み

ユーザー：「自分に割り当てられている未解決のバグをすべて表示してください」

AI ワークフロー：

1. gh issue list --state open --label bug --assignee @me を使用する

結果：

Found 3 open bug issues assigned to you:

#142 - [Bug] API timeout on large file uploads
      Labels: bug, priority-medium
      Created: 2024-01-15

#138 - [Bug] Dashboard graphs not rendering on Safari
      Labels: bug, frontend
      Created: 2024-01-12

#125 - [Bug] Email notifications delayed by 30+ minutes
      Labels: bug, priority-high
      Created: 2024-01-08

例 4：コメントを付けて Issue をクローズする

ユーザー：「Issue #142 をクローズして、v2.4.0 で修正されたとコメントしてください」

AI ワークフロー：

1. まず、Issue にコメントを追加します：gh issue comment 142 --body "Fixed in v2.4.0. Closing this issue."
2. 次に、Issue をクローズします：gh issue close 142

結果：

Issue #142 has been commented and closed.

よく使われるラベル

該当する場合は、次の標準ラベルを使用します。

ラベル	用途
bug	正常に動作していないもの
enhancement	新機能または改善
documentation	ドキュメントの更新
good first issue	初心者に適したもの
help wanted	追加の支援が必要なもの
question	追加情報が求められているもの
wontfix	対応しないもの
duplicate	すでに存在するもの
invalid	有効な Issue ではないもの

重要な注意事項

• リポジトリへのアクセス権を必ず確認する - Issue を作成・変更する権限があることを確認します
• ラベルを一貫して使用する - リポジトリのラベル付け規則に従います
• タイトルを具体的にする - 明確にするため、[Bug]、[Feature]、[Task] を先頭に付けます
• 再現手順を含める - バグ報告では不可欠です
• 受け入れ条件を定義する - 機能やタスクの明確な「完了の定義」を示します
• 関連する Issue にリンクする - 説明に「Related to #XX」または「Blocks #XX」を使用します
• @username でユーザーにメンションする - 可視性と通知のために使用します
• マイルストーンを使用する - 該当する場合は、Issue をリリースに関連付けます

GitHub Issue のベストプラクティス

効果的なタイトルを書く

• 簡潔でありながら、内容がわかるようにします
• Issue の種類を示す接頭辞を含めます：[Bug]、[Feature]、[Task]、[Docs]
• 該当する場合は、影響を受けるコンポーネントを記載します
• 「バグを修正」「コードを更新」のような曖昧なタイトルは避けます

説明を構成する

• 読みやすさのために Markdown 形式を使用します
• 関連する背景情報を冒頭にすべて含めます
• 役立つ場合は、スクリーンショットやログを追加します
• 関連する Issue、PR、ドキュメントにリンクします
• 追跡可能なサブ項目にはタスクリストを使用します

ラベルの方針

• 種類を示すラベル（bug、enhancement）と領域を示すラベル（frontend、api）を組み合わせます
• 必要に応じて、優先度ラベル（priority-high、priority-low）を使用します
• リポジトリ間でラベル体系に一貫性を持たせます

割り当てとワークフロー

• Issue を特定のチームメンバーに割り当てます
• リリース計画にはマイルストーンを使用します
• 作業の進行に合わせて Issue のステータスを更新します
• 修正する PR を参照して Issue をクローズします：「Fixes #XX」