0
代码
代码
Issues
Pull Requests
讨论
Wiki
分析
0
Aaflyingtofeat: add 8 GitCode CLI skills with full-dimension workflows
f2643571创建于 21 天前历史提交

name: gitcode-issue-review description: | 对 GitCode Issue 进行深度内容评审，包括信息完整度检查、需求分析、 需求分解、开发实现建议和安全隐患排查。在 Issue 评论区发布评审意见。

TRIGGER when: 用户要求 review issue、评审issue、分析issue需求、 分解issue、issue实现建议、评估issue质量、检查issue完整性、 或对 GitCode issue 做深度分析。与 issue triage（分类贴标签） 不同，本 skill 关注内容深度和开发可行性。只要是围绕 issue 内容 质量做深度分析，即应触发。

GitCode Issue 深度评审

对 GitCode Issue 进行深度内容评审：检查信息完整度、分析需求、分解任务、提出实现建议， 并在 Issue 评论区发布评审意见。

与 gitcode-issue-triage 的区别

维度 gitcode-issue-triage gitcode-issue-review（本 skill）
关注点 分类、标签、优先级 内容质量、需求深度、开发可行性
输出 类型判断 + 标签建议 需求分析 + 任务分解 + 实现方案
目标 快速归类分流 深度理解后推动落地

两个 skill 互补：triage 适合新 issue 的快速分流，review 适合需要深入分析后再动手的 issue。

适用范围

  • 需要弄清楚"这个 issue 到底要做什么"时
  • 开发前需要技术方案建议时
  • 发现 issue 描述不清需要指出缺失信息时
  • 需要把大 issue 拆成可执行子任务时
  • Bug report 需要评估复现步骤是否完备时

核心工作流

第一步：收集 Issue 信息

# Issue 详情（标题、描述、标签、受理人、里程碑）
gc issue view <number> --json

# Issue 评论区（了解已有讨论和补充信息）
gc issue comments <number> --json

# 关联的 PR（了解是否已有修复方案）
gc issue prs <number>

# 关联关系（了解 issue 之间的依赖）
gc issue relations <number>

从 gc issue view --json 中提取：

  • 标题、描述（body）、作者、状态、创建/更新时间
  • 当前标签、受理人、里程碑
  • 描述中是否包含：复现步骤、期望行为 vs 实际行为、环境信息

第二步：代码库调研

根据 issue 涉及的功能区域，了解相关代码：

# 根据 issue 关键词搜索相关代码
grep -r "<issue关键词>" --include="*.go" .

# 了解相关模块的结构
find . -path "*<module>*" -name "*.go" | head -20

# 查看最近的 git log（了解模块变更历史）
git log --oneline -20 -- <related_path>/

调研目的：

  • 理解 issue 涉及模块的现有实现
  • 评估修改范围和复杂度
  • 为后续实现建议提供代码级参考

第三步：多维度分析

1. 信息完整度检查

根据 issue 类型分别检查：

Bug Report 检查清单：

  • 问题现象：发生了什么？（预期 vs 实际）
  • 复现步骤：最小复现操作是什么？
  • 环境信息：版本号、OS、相关配置
  • 影响范围：影响了哪些用户/功能
  • 日志/截图/错误信息：是否有支撑证据
  • 是否可稳定复现 vs 偶发

Feature Request 检查清单：

  • 需求背景：为什么要做？解决什么问题？
  • 功能描述：具体要做什么？（What，不是 How）
  • 验收标准：做到什么程度算完成？
  • 优先级/紧迫度：为什么现在要做？
  • 影响范围：涉及哪些模块、用户

缺少关键信息时：在评审结论中列出，建议添加 needs-info 标签待作者补充。

2. 需求分析

从技术角度分析 issue 提出的需求：

  • 核心诉求：用一句话概括本质问题
  • 需求边界：做什么 + 不做什么（Scope 清晰比什么都重要）
  • 技术可行性：基于现有代码库架构是否可行
  • 影响评估：涉及多少模块、多少文件、是否破坏性变更
  • 优先级判断：是否阻塞其他功能、是否有 workaround
  • 潜在坑点：容易出错的地方、需要特别注意的边界条件

3. 需求分解

将 issue 拆解为可独立执行的子任务：

### 需求分解

#### Sub-task 1: <标题> [预估: Xh]
- 做什么
- 涉及文件
- 依赖前提

#### Sub-task 2: <标题> [预估: Xh]
- 做什么
- 涉及文件
- 依赖前提

拆分原则：

  • 每个子任务可独立完成和验证
  • 按依赖关系排序（先基础后上层）
  • 每个子任务预估工作量（XS < 2h, S < 1d, M < 3d, L > 3d）

4. 开发实现建议

基于代码库调研，给出具体的实现指导：

  • 推荐方案：技术路线和原因
  • 备选方案（如有）：权衡利弊
  • 涉及的关键文件：列出现有文件（需修改的）和新增文件
  • 核心逻辑设计：关键函数/接口的设计思路，必要时给出伪代码
  • 数据库/配置变更（如有）：migration、新增配置项
  • 测试策略：需要覆盖的测试场景（单元/集成/e2e）
  • 风险点：性能瓶颈、兼容性问题、安全注意事项
  • 文档同步：需要更新的文档（README、CHANGELOG、API 文档等）

5. 安全隐患排查

检查 issue 本身是否存在安全问题：

  • 描述中是否包含敏感信息（密码、token、内网地址）
  • 需求本身是否有安全风险（权限绕过、数据泄露）
  • 修复方案是否会引入新的安全隐患

第四步：生成评审报告

报告结构

## Issue 深度评审报告

### 整体评价
[1-2 句话评估 issue 质量和可行性]

### Issue 基本信息
- 标题
- 类型：[bug/feature/enhancement/docs/question]
- 当前状态
- 关联 PR

### 信息完整度

| 检查项 | 状态 | 说明 |
|--------|------|------|
| ... | ✅/❌/⚠️ | ... |

**缺失信息**（如有）：
- [ ]

### 需求分析

**核心诉求**: [一句话]

**需求边界**: 
- 范围内：...
- 范围外：...

**技术可行性**: [可行/需调研/不可行] + 理由

**影响范围**: X 模块, ~Y 文件

**潜在坑点**:
1. [ ]

### 需求分解

| # | 子任务 | 涉及模块 | 预估 | 依赖 |
|---|--------|----------|------|------|
| 1 | ... | ... | S | - |
| 2 | ... | ... | M | #1 |

### 开发实现建议

**推荐方案**: 
[技术路线概述]

**关键设计要点**:
1. ...
2. ...

**涉及文件**:
- 修改: `path/to/file.go` — 改什么
- 新增: `path/to/new_file.go` — 做什么

**测试建议**:
- 单元测试：...
- 集成测试：...
- 手动验证：...

**风险提示**:
- [ ]

### 安全审查

| 检查项 | 状态 |
|--------|------|
| 描述无敏感信息 | ✅/❌ |
| 需求无安全隐患 | ✅/❌ |
| 方案无新增风险 | ✅/❌ |

### 最终建议

- [ ] 信息充分，可开始开发
- [ ] 需要补充信息后再评估
- [ ] 建议拆分为多个小 issue
- [ ] 需要进一步技术调研
- [ ] 建议关闭/合并到其他 issue

第五步：发布评审意见

# 发布整体评审报告
gc issue comment <number> --body-file review-report.md

# 如需补充简短评论
gc issue comment <number> --body "简要评论内容"

# 如需建议标签
gc issue label <number> --add <labels>

发布前与用户确认，尤其当评审结论是"需要补充信息"或"建议关闭"时。

评审原则

  • 先理解再评判：阅读完整描述和已有评论，不凭标题下结论
  • 先验证再建议：通过代码搜索确认技术可行性，不在空中楼阁上给方案
  • 具体优于笼统：实现建议落实到具体文件和函数级别
  • 拆解优于通吃：大 issue 拆成小任务，降低启动门槛
  • 开发者视角：评审结论要能直接指导开发，不只是"写得好/不好"
  • 尊重作者：假设作者有合理意图，缺失信息先问再判

注意事项

  • issue 质量参差不齐，对描述简陋的 issue 重点做信息完整度检查，告知需要补充什么
  • 需求分解的粒度适中：太粗无法指导开发，太细变成 micromanagement
  • 实现建议定位在"指导"而非"替代"，给开发者留发挥空间
  • 与 gitcode-issue-triage 配合：先用 triage 分流，再用 review 深入
  • 如果 issue 已有大量讨论，先总结已有共识再补充新观点
  • 安全审查只检查 issue 描述本身，不扩展到代码审查

示例用法

完整 Issue 评审：

全面评审 Issue #42，我需要搞清楚这个需求要做什么、怎么实现

Bug 信息检查：

review Issue #15 这个 bug report，看看信息够不够开始修复

需求分解：

帮我把 Issue #128 拆成可以独立开发的子任务

实现建议：

分析 Issue #67，给出具体的技术实现方案

评审但不发布：

评审 Issue #89 给我看，先不要评论到 issue 上