gitlab-issue

GitLab イシュー管理

包括的なコンテキスト連携と構造化されたワークフローにより、GitLab イシューの作成、取得、更新、管理を行います。

前提条件

• glab（GitLab CLI）：すべてのイシュー操作に必要です。https://gitlab.com/gitlab-org/cli または brew install glab からインストールしてください。

GitLab インスタンスの設定

このスキルはセルフホストの GitLab インスタンス用に設定されています。

• GitLab URL： https://gitlab-erp-pas.dedalus.lan
• プロジェクト識別子、URL、参照先はすべて、このセルフホストインスタンスを使用してください。
• この GitLab サーバーにアクセスするための適切な認証情報が設定されていることを確認してください。

このスキルを使用するタイミング

以下の場合にこのスキルを有効にしてください。

• ユーザーが新しい GitLab イシューの作成を希望している
• ユーザーがイシューの詳細の表示または取得を依頼している
• ユーザーが既存のイシューの更新を必要としている
• ユーザーがプロジェクト内のイシューの一覧表示を希望している
• ユーザーが GitLab のイシュー、チケット、タスクの管理について言及している
• ユーザーがイシューのクローズ、再オープン、またはプロパティの変更を希望している
• ユーザーがイシューをマージリクエストにリンクする必要がある

重要なルール

重要：イシューを作成または変更する前に、必ず project_id を確認してください。

常に説明的なイシュータイトルを使用し、構造化された説明を記載してください。

重複したイシューを作成しないでください。適切な場合は、まず既存のイシューを検索してください。

ワークフロー

1. コンテキストの収集

まず、現在のプロジェクトとコンテキストに関する情報を収集します。

• プロジェクトを特定します（project_id または URL エンコードされたパス）。
• イシューの種類（バグ、機能、タスクなど）を把握します。
• 該当する場合は、関連するラベル、マイルストーン、担当者を確認します。

2. プロジェクトの確認

操作を行う前に、プロジェクトが存在し、正しい識別子を使用していることを確認します。

セルフホスト GitLab インスタンス： https://gitlab-erp-pas.dedalus.lan

glab repo view を使用して、以下を行います。

• プロジェクトがセルフホストの GitLab インスタンス上に存在することを確認します。
• プロジェクトの詳細（デフォルトブランチ、公開範囲など）を取得します。
• プロジェクトの構造を把握します。
• プロジェクトパスの形式（例：「namespace/project」）を確認します。

3. イシュー操作

新しいイシューの作成

イシューを作成する際は、必要なコンテキストをすべて収集します。

必須情報：

• project_id：プロジェクト識別子（例：「namespace/project」または数値 ID）
• title：明確で説明的なイシューのタイトル

任意ですが、記載を推奨する情報：

• description：Markdown 形式の詳細な説明
• labels：ラベル名の配列（例：["bug", "priority::high"]）
• assignee_ids：割り当てるユーザー ID の配列
• milestone_id：関連付けるマイルストーン ID
• due_date：YYYY-MM-DD 形式の期限
• confidential：機密性の高いイシューかどうかを示すブール値

人間参加型の確認 — コンテキストを尋ねる

AskUserQuestion を必ず使用して、イシューの詳細を確認してください。

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"

イシューの説明テンプレート：

わかりやすくなるよう、説明を構成してください。

## 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.]

イシューの詳細の取得

glab issue view <iid> を使用します。

• <iid>：内部イシュー ID（GitLab に表示される番号。例：42）

以下を含むイシューの完全な情報が返されます。

• タイトルと説明
• 状態（オープン／クローズ）
• ラベルとマイルストーン
• 担当者と作成者
• 作成日時／更新日時
• 関連するマージリクエスト

イシューの一覧表示

フィルターを指定して glab issue list を使用します。

• --state：「opened」、「closed」、または「all」
• --label：ラベルで絞り込みます
• --milestone：マイルストーンのタイトルで絞り込みます
• --assignee：担当者で絞り込みます
• --search：タイトルと説明を検索します
• --order-by：「created_at」、「updated_at」、「priority」などで並べ替えます
• --sort：「asc」または「desc」
• --per-page：1 ページあたりの結果数（最大 100）

イシューの更新

イシューを更新する際は、変更するフィールドのみを指定します。

変更するフィールド（タイトル、説明、ラベルなど）に対応したフラグを使用して、glab issue update <iid> を実行します。

状態の変更：

• glab issue close <iid> - イシューをクローズします。
• glab issue reopen <iid> - イシューを再オープンします。

4. マージリクエストへのリンク

関連するマージリクエストを見つけるには：

フィルターを指定して glab mr list を使用し、イシューを参照しているMRを見つけます。

• MRのタイトルや説明でイシュー番号を検索します
• MRの説明に「Closes #XX」や「Fixes #XX」のパターンがないか確認します

5. 操作の実行（確認が必要）

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

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

Creating issue in project: namespace/project
Title: [title]
Description: [summary]
Labels: [labels]
Assignee: [assignee]

Proceed with issue creation?

イシューの種類別テンプレート

バグ報告

## Bug Description
[Clear description of the bug]

## Environment
- Version: [version]
- OS: [operating system]
- Browser: [if applicable]

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

## Expected Behavior
[What should happen]

## Actual Behavior
[What actually happens]

## Screenshots/Logs
[Attach relevant files]

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

機能リクエスト

## Feature Description
[Clear description of the requested feature]

## Problem Statement
[What problem does this solve?]

## Proposed Solution
[How should this work?]

## Alternatives Considered
[Other approaches considered]

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

## Additional Context
[Mockups, examples, etc.]

タスク

## 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：バグ報告の作成

ユーザー：「話し合ったログインのバグについてイシューを作成して」

AI ワークフロー：

1. 不明な場合は project_id を尋ねます
2. バグについて確認の質問をします
3. 構造化された説明を作成します
4. 確認のために概要を提示します
5. glab issue create --title "<title>" --description "<description>" --label "bug,priority::high,auth" でイシューを作成します

結果：

Title: [BUG] Login fails with OAuth2 when session expires

Description:
## Bug Description
Users are unable to log in using OAuth2 authentication when their 
previous session has expired.

## Steps to Reproduce
1. Log in with OAuth2 (Google/GitHub)
2. Wait for session to expire (or clear cookies)
3. Attempt to log in again
4. Observe error: "Invalid state parameter"

## Expected Behavior
User should be redirected to OAuth provider and log in successfully.

## Actual Behavior
Login fails with "Invalid state parameter" error.

## Environment
- Version: 2.3.1
- Browser: Chrome 120, Firefox 121

Labels: ["bug", "priority::high", "auth"]

例 2：イシューの一覧表示とフィルタリング

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

AI ワークフロー：

1. glab issue list --state opened --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, priority::low
      Created: 2024-01-12

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

例 3：イシューの更新

ユーザー：「イシュー #142 をクローズして、v2.4.0 で修正済みだとコメントを追加して」

AI ワークフロー：

1. まず、イシューにメモ／コメントを追加します：glab issue note 142 --message "Fixed in v2.4.0. Closing this issue."
2. 次に、イシューをクローズします：glab issue close 142

結果：

Issue #142 "[BUG] API timeout on large file uploads" has been closed.

例 4：背景情報を含む機能リクエスト

ユーザー：「ダークモードのサポート追加について機能リクエストを作成して」

AI ワークフロー：

1. 機能について確認の質問をします
2. 受け入れ基準を集めます
3. 構造化されたイシューを作成します

結果：

Title: [FEATURE] Add dark mode theme support

Description:
## Feature Description
Implement a dark mode theme option that users can toggle in their 
preferences.

## Problem Statement
Users working in low-light environments experience eye strain with 
the current bright interface. Dark mode would improve accessibility 
and user comfort.

## Proposed Solution
- Add theme toggle in user preferences
- Implement CSS variables for theme colors
- Store preference in user settings
- Support system preference detection

## Acceptance Criteria
- [ ] User can toggle between light/dark mode in settings
- [ ] Theme preference persists across sessions
- [ ] System preference is detected on first visit
- [ ] All UI components support both themes
- [ ] No accessibility contrast issues in dark mode

## Additional Context
Reference designs: [link to mockups]
Similar implementations: GitHub, GitLab, VS Code

Labels: ["feature", "enhancement", "ux"]

重要な注意事項

• セルフホスト版 GitLab： すべての操作で https://gitlab-erp-pas.dedalus.lan を使用します
• プロジェクトへのアクセス権を必ず確認してください - セルフホストインスタンスでイシューを作成／変更する権限があることを確認します
• ラベルを一貫して使用してください - プロジェクトのラベル付け規則に従います
• タイトルは具体的にしてください - 分かりやすさのため、[BUG]、[FEATURE]、[TASK] を先頭に付けます
• 再現手順を記載してください - バグ報告には欠かせません
• 受け入れ基準を定義してください - 機能やタスクの「完了の定義」を明確にします
• 関連するイシューにリンクしてください - 説明に「Related to #XX」または「Blocks #XX」を使用します
• @username でユーザーにメンションしてください - 可視性と通知のために使用します
• マイルストーンを使用してください - 該当する場合、イシューをリリースやスプリントに関連付けます

GitLab イシューのベストプラクティス

効果的なタイトルの書き方

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

説明の構成

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

ラベルの方針

• スコープ付きラベルを使用します（例：priority::high、status::in-progress）
• 種類のラベル（bug、feature）と領域のラベル（frontend、api）を組み合わせます
• プロジェクト間でラベルの分類体系を一貫させます

割り当てとワークフロー

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