gitlab-issue

GitLab Issue 管理

创建、检索、更新和管理 GitLab issue，并整合全面的上下文信息和结构化工作流。

前置条件

• glab（GitLab CLI）：所有 issue 操作都需要；请从 https://gitlab.com/gitlab-org/cli 安装，或运行 brew install glab

GitLab 实例配置

此技能已配置为使用自托管的 GitLab 实例：

• GitLab URL： https://gitlab-erp-pas.dedalus.lan
• 所有项目标识符、URL 和引用都应使用此自托管实例
• 确保已为此 GitLab 服务配置适当的访问凭据

何时使用此技能

在以下情况下启用此技能：

• 用户想要创建新的 GitLab issue
• 用户要求查看或检索 issue 详情
• 用户需要更新现有 issue
• 用户想要列出项目中的 issue
• 用户提到要在 GitLab 中管理 issue、工单或任务
• 用户想要关闭、重新打开或修改 issue 属性
• 用户需要将 issue 关联到合并请求

重要规则

重要：创建或修改 issue 前，务必确认 project_id

始终使用描述清晰的 issue 标题，并提供结构化描述

切勿创建重复 issue；适当时应先搜索现有 issue

工作流

1. 收集上下文

首先，收集当前项目和上下文信息：

• 确认项目（project_id 或经过 URL 编码的路径）
• 了解 issue 类型（错误、功能、任务等）
• 收集相关标签、里程碑和受指派人（如适用）

2. 验证项目

执行任何操作前，验证项目是否存在，以及标识符是否正确：

自托管 GitLab 实例： https://gitlab-erp-pas.dedalus.lan

使用 glab repo view 来：

• 确认项目存在于自托管 GitLab 实例中
• 获取项目详情（默认分支、可见性等）
• 了解项目结构
• 验证项目路径格式（例如，"namespace/project"）

3. Issue 操作

创建新的 Issue

创建 issue 时，收集完整上下文：

必需信息：

• project_id：项目标识符（例如，"namespace/project" 或数字 ID）
• title：清晰、描述性强的 issue 标题

可选但建议提供：

• description：Markdown 格式的详细描述
• labels：标签名称数组（例如，["bug", "priority::high"]）
• assignee_ids：要指派的用户 ID 数组
• milestone_id：要关联的里程碑 ID
• due_date：截止日期，格式为 YYYY-MM-DD
• confidential：敏感 issue 的布尔值

人在环路中——询问上下文

始终使用 AskUserQuestion 澄清 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"

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 详情

使用 glab issue view <iid>，其中：

• <iid>：issue 的内部 ID（GitLab 中显示的数字，例如，42）

此命令会返回完整的 issue 信息，包括：

• 标题和描述
• 状态（已打开/已关闭）
• 标签和里程碑
• 受指派人和作者
• 创建/更新时间戳
• 相关合并请求

列出 Issue

使用 glab issue list 并添加筛选条件：

• --state："opened"、"closed" 或 "all"
• --label：按标签筛选
• --milestone：按里程碑标题筛选
• --assignee：按受指派人筛选
• --search：在标题和描述中搜索
• --order-by：按 "created_at"、"updated_at"、"priority" 等排序
• --sort："asc" 或 "desc"
• --per-page：每页结果数（最多 100）

更新 Issue

更新 issue 时，只提供变更的字段：

使用 glab issue update <iid>，并为要更改的字段（标题、描述、标签等）添加相应标志。

状态变更：

• glab issue close <iid> - 关闭 issue
• glab issue reopen <iid> - 重新打开 issue

4. 链接到合并请求

查找相关合并请求：

使用 glab mr list 搭配筛选条件，查找引用该问题的合并请求：

• 在合并请求标题/描述中搜索问题编号
• 检查合并请求描述中是否包含 “Closes #XX” 或 “Fixes #XX” 模式

5. 执行操作（需要确认）

重要：创建或修改问题前，必须先与用户确认

收集完所有信息后，向用户提供摘要以供审批：

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

Proceed with issue creation?

问题类型模板

Bug 报告

## 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：创建 Bug 报告

用户：“为我们讨论过的登录 Bug 创建一个问题”

AI 工作流：

1. 如果项目 ID 未知，询问 project_id
2. 询问 Bug 的相关细节
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：列出并筛选问题

用户：“显示所有分配给我的未解决 Bug”

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] 前缀以便明确分类
• 包含复现步骤 - 这对 Bug 报告至关重要
• 定义验收标准 - 为功能/任务明确“完成定义”
• 关联相关问题 - 在描述中使用 “Related to #XX” 或 “Blocks #XX”
• 使用 @username 提及用户 - 以便相关人员查看并收到通知
• 使用里程碑 - 适用时，将问题关联到版本或冲刺

GitLab 问题最佳实践

编写有效的标题

• 简洁明了，同时准确描述
• 添加问题类型前缀：[BUG]、[FEATURE]、[TASK]、[DOCS]
• 适用时注明受影响的组件
• 避免使用“修复 Bug”或“更新代码”等模糊标题

组织描述内容

• 使用 Markdown 格式提升可读性
• 在开头提供所有相关背景
• 适当添加截图或日志
• 链接相关问题、合并请求或文档
• 使用任务列表跟踪子项

标签策略

• 使用作用域标签（例如，priority::high、status::in-progress）
• 将类型标签（bug、feature）与领域标签（frontend、api）组合使用
• 在各项目中保持标签体系一致

分配与工作流

• 将问题分配给具体的团队成员
• 使用里程碑规划冲刺/版本
• 随着工作进展更新问题状态
• 关闭问题时引用修复该问题的合并请求：“Closes #XX”