external-mindstudio-gitcode-code-reviewer

用于审查 GitCode PR，并结合 PR metadata、diff 与整个代码仓上下文生成深度审查结论或发布逐行评论。当用户希望 review GitCode PR、检查某个 GitCode PR 链接、分析变更风险、或将审查意见发布到 GitCode PR 时使用。典型触发方式包括“review this PR”“检视这个 PR”“检查 PR”，或直接提供 GitCode PR 链接，例如 https://gitcode.com/owner/repo/pull/123 。

跳到安装

仓库: ascend-ai-coding/awesome-ascend-skills
最近来源活动: 2026年5月26日 02:59
检测到的 SKILL.md 语言: 中文
星标: 166
分支: 56

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

直接命令不会经过审查 Prompt；运行前请先检查来源。

npx skills add https://github.com/ascend-ai-coding/awesome-ascend-skills --skill external-mindstudio-gitcode-code-reviewer

命令会保持在同一行。复制前请横向滚动并检查完整内容。

想先保存到本地？可下载 SkillsMP 当前能够提供的文件。

检查来源文件

决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。

文件资源管理器

8 个文件

SKILL.md

来源说明 · 只读预览

返回搜索返回安装

tech-docs-guard

评估 CANN 算子仓的「进阶教程 / 开发指南」类文档质量——通读文档 + 对照算子代码**静态**查证(默认不跑),按五轴(找得到/信得过/学得会/可操作/读得懂)找出漏讲/讲不清/过时/对不上代码/概念讲错,产出带证据与改进建议的体检报告(MD + HTML)。涉及「评进阶教程 / 开发指南文档质量 / 文档对不对得上代码 / 教程审稿 / tutorial 体检 / 文档信不信得过」等意图时使用。只评不改不跑,只对着文档与代码出诊断。

2026-07-14

remote-npu-test

Run NPU inference/training tests on a remote SSH server with vllm-ascend Docker container. Use when the user asks to test models on NPU, run inference on Ascend devices, or deploy models to an SSH server.

2026-06-24

vllm-daily-pr-issue-tracker

Track daily PRs and Issues from vllm-project/vllm and vllm-project/vllm-ascend, filter by model (DeepSeek/Qwen/GLM/MiniMax/Kimi) and tech topics (PD disaggregation, MTP, quantization, graph mode, performance), analyze with LLM, and generate a Markdown report. Use when user wants vllm daily tracker, PR/Issue digest, or Ascend inference ecosystem monitoring.

2026-06-09

查看这个仓库的全部 Skills

name	external-mindstudio-gitcode-code-reviewer
description	用于审查 GitCode PR，并结合 PR metadata、diff 与整个代码仓上下文生成深度审查结论或发布逐行评论。当用户希望 review GitCode PR、检查某个 GitCode PR 链接、分析变更风险、或将审查意见发布到 GitCode PR 时使用。典型触发方式包括“review this PR”“检视这个 PR”“检查 PR”，或直接提供 GitCode PR 链接，例如 https://gitcode.com/owner/repo/pull/123 。
original-name	gitcode-code-reviewer
synced-from	https://github.com/kali20gakki/mindstudio-skills
synced-date	2026-05-26
synced-commit	f6695da3cfa864a100db5a94f594b638aeff6389
license	UNKNOWN

GitCode 代码审查助手

针对 GitCode PR 做“有上下文”的代码审查。diff 只是入口，不是全部证据；必须结合 PR 标题/描述、变更文件、调用链、相邻模块、历史实现、测试与配置来判断改动是否真的正确。

前置要求

GitCode 访问令牌

本技能需要 GitCode 访问令牌，用于获取 PR 信息和发布评论。令牌可通过以下方式之一配置：

环境变量（推荐）：GITCODE_TOKEN
Git 配置：git config --global gitcode.token <your-token>

如果没有找到令牌，需要提示用户提供。

获取 GitCode 令牌

登录 https://gitcode.com
点击头像，进入“设置”
打开“私人令牌”
创建新令牌，并授予以下权限：
- pull_requests（读写）
- issues（读写）
- projects（只读）

工作流程

1. 解析 PR 信息

当用户提供类似 https://gitcode.com/Ascend/msprof/pull/109 的 GitCode PR 链接时：

提取：owner=Ascend、repo=msprof、pull_number=109

2. 获取 PR 信息

使用 scripts/fetch_pr_info.py 获取 PR 详情：

python scripts/fetch_pr_info.py \
  --owner <OWNER> --repo <REPO> --pull-number <NUMBER> \
  [--token <TOKEN>] [--output-dir <DIR>]

该脚本会获取：

PR 元数据，例如标题、描述、作者、状态
发生变更的文件及其 diff 内容
PR 评论（可选）

3. 准备分析工作区

优先使用用户当前 workspace；如果当前目录已经是目标仓库，并且可以拿到 PR 对应分支或 commit，就直接在当前仓库分析，不要重复克隆。

只有在当前 workspace 不是目标仓库，或无法获取 PR 对应代码时，才克隆到临时目录：

export GITCODE_TOKEN="your-token"
TEMP_DIR="/tmp/gitcode-review-<REPO>-<TIMESTAMP>"
git clone --depth=50 "https://oauth2:${GITCODE_TOKEN}@gitcode.com/<OWNER>/<REPO>.git" "${TEMP_DIR}"
cd "${TEMP_DIR}"

# 获取 PR 分支
git fetch origin "refs/merge-requests/<NUMBER>/head:pr-<NUMBER>-source"
git checkout "pr-<NUMBER>-source"

4. 构建审查上下文（必做）

先读 summary.json、pr_metadata.json、pr_files.json、pr_diff.patch，再开始看代码。必须先回答下面几个问题：

这个 PR 想解决什么问题
- 从标题、描述、标签、关联 issue、文件分布中推断目标，是修 bug、加功能、重构、补测试、回滚还是兼容性修复。
- 如果 PR 描述不足，要根据修改内容自行归纳目的，并在结论里说明你的判断依据。
改动落在系统的哪一层
- 识别变更文件分别属于入口层、核心逻辑层、数据模型层、接口/协议层、配置/构建层、测试层、生成产物。
- 如果是生成文件、lockfile、SDK 产物，继续追到“源头文件”审查，不要只评论生成结果。
这些改动与仓库中的哪些实现有关
- 查调用方、被调用方、同类实现、适配层、配置项、feature flag、schema、迁移脚本、测试夹具、文档。
- 审查时必须看修改行的上下文文件，不要只看 patch hunk。
基线行为是什么
- 通过 base 分支代码、历史提交或已有测试确认原本行为，再判断这次改动是否破坏兼容性或遗漏分支。

推荐优先使用这些工具建立上下文：

rg -n "<symbol>|<config>|<endpoint>" .：查调用链、配置项、同类实现、测试覆盖
git diff --stat <base_sha>...<head_sha>：快速识别高风险改动面
git diff --name-only <base_sha>...<head_sha>：按模块分组变更文件
git show <base_sha>:<path>：对比基线实现
git log --follow -- <path>：看文件演进和历史意图
git blame -L <start>,<end> -- <path>：定位历史上下文和责任归属
项目自带测试/构建命令：验证推断是否成立

如果某个结论依赖推断而不是直接证据，必须明确写出条件，例如“如果这里允许空集合输入，那么当前实现会……”。不要把猜测写成确定事实。

5. 深入审查代码

在完成上下文构建后，从以下维度审查，并尽量结合项目实际实现给出判断：

目标一致性：实现是否真的满足 PR 目标，是否只改了表层而漏掉调用链上的必要改动
正确性与回归风险：老行为是否被意外改变，边界条件、异常路径、状态切换是否完整
契约兼容性：函数签名、接口字段、返回值、序列化格式、错误码、配置项是否与上下游兼容
项目一致性：是否偏离仓库中已有模式，导致后续维护成本升高或行为不一致
性能与资源：是否引入不必要的遍历、重复 I/O、锁竞争、缓存失效、N+1 调用等问题
安全性：输入校验、权限边界、敏感数据处理、命令/SQL/路径注入等风险
可测试性：关键分支是否有测试支撑；没有测试时，至少指出应补哪类用例

6. 整理审查结论

按照严重程度组织问题：

严重：会导致 bug、安全问题或破坏性变更
建议：建议优化代码质量、性能或实现方式
提示：格式、风格或其他可选的小问题

默认聚焦真正影响行为、可靠性、兼容性、可维护性的发现；不要把纯风格意见堆成主要结论。

每条发现必须包含：

文件路径
行号
严重程度
四段式结构：
1. 严重程度：明确标注问题级别，并与实际影响一致
2. 问题：具体指出当前代码存在什么问题
3. 原因：解释为什么这是个问题，会带来什么风险或影响，并尽量说明它和仓库中哪段实现、哪条调用链、哪类已有约束相关
4. 怎么改：给出可执行的修改建议，必要时附代码示例

额外要求：

不要只复述 diff 表面现象；每条重要评论都应体现你查过周边上下文
如果问题来自“改动不完整”，说明还缺哪些文件、分支、调用点或测试
如果没有发现问题，要明确说出你检查过哪些关键上下文，而不是只说“LGTM”

7. 先向用户展示审查结果

在正式发布评论前，先将审查结果展示给用户：

## 代码审查摘要

**PR**： [标题](URL)  
**作者**：@author  
**结论**： [通过 / 请求修改]

### 发现的问题

#### 🔴 严重问题（N 个）
1. **文件**：`path/to/file.py`（第 42 行）
   - **严重程度**：严重
   - **问题**：描述问题
   - **原因**：解释原因
   - **怎么改**：提供代码示例

#### 🟡 改进建议（N 个）
...

#### 🟢 细节建议（N 个）
...

### 总结
[给出清晰结论及其原因]

在摘要中，除了列问题，还应补一小段“审查覆盖面”，简述你看过的关键上下文，例如“检查了调用方 A/B、对照了基线实现 C、确认了测试 D 的覆盖情况”。

8. 将评论发布到 PR（可选）

先询问用户：“是否要把这些发现作为逐行评论发布到 PR？”

如果用户确认，则创建评论 JSON 文件，并使用 scripts/post_pr_comment.py 发布：

python scripts/post_pr_comment.py \
  --owner <OWNER> --repo <REPO> --pull-number <NUMBER> \
  --comments-file /tmp/pr_comments.json \
  --inline

评论正文示例（四段式）：

**严重程度：** 建议

**问题：** 代码中存在不规范的空格

**原因：** `node = int (node_str)` 不符合 PEP 8 规范，影响可读性

**怎么改：**
```python
# 修改前
node = int (node_str)

# 修改后
node = int(node_str)
```

优先在 comments.json 中使用结构化字段：severity、problem、reason、fix。
scripts/post_pr_comment.py 会在发布前将这些字段统一整理为四段式 Markdown 正文，默认输出中文严重程度（严重、建议、提示），也会兼容旧版英文值和旧版三段式 body 内容。

9. 清理临时目录

审查完成后，清理临时仓库：

rm -rf /tmp/gitcode-review-<REPO>-<TIMESTAMP>

审查语气要求

保持建设性、专业、友好
解释清楚为什么需要修改
如果给出通过结论，要明确指出本次提交的价值
使用尊重式表达，避免命令式语气
所有发现都必须使用四段式结构
一条评论只聚焦一个问题，严重程度要和实际风险一致
行级评论尽量具体、可执行，避免只有结论没有修改方向
优先指出真正影响业务或系统行为的问题，少给脱离项目上下文的泛泛建议

审查底线

不要只基于 diff 下结论；diff 只是定位入口
不要为了凑数量输出低价值评论
不要忽略测试、配置、调用链和兼容性影响
不确定时先补代码搜索和上下文验证，再决定是否提出问题

脚本说明

fetch_pr_info.py

用于从 GitCode API 获取 PR 信息。

python scripts/fetch_pr_info.py \
  --owner OWNER \
  --repo REPO \
  --pull-number NUMBER \
  [--token TOKEN] \
  [--output-dir DIR] \
  [--include-comments]

post_pr_comment.py

用于向 GitCode PR 发布评论。

发布逐行行级评论：

python scripts/post_pr_comment.py \
  --owner OWNER \
  --repo REPO \
  --pull-number NUMBER \
  --comments-file COMMENTS_JSON \
  --inline

发布整体审查结论：

python scripts/post_pr_comment.py \
  --owner OWNER \
  --repo REPO \
  --pull-number NUMBER \
  --body "审查总结" \
  --review-event COMMENT|APPROVE|REQUEST_CHANGES

setup_token.py

用于配置并验证 GitCode 访问令牌。

# 交互式配置
python scripts/setup_token.py

# 仅验证现有令牌
python scripts/setup_token.py --verify-only

参考资料

GitCode API 文档：见 references/gitcode_api.md
如需查看 API 细节，按需阅读对应参考文件

技术说明

API 版本

GitCode 同时支持 v4（兼容 GitLab）和 v5（兼容 GitHub）两套 API：

v5 API：用于获取 PR 信息、文件列表和普通评论
- 基础地址：https://api.gitcode.com/api/v5
- 认证方式：PRIVATE-TOKEN 请求头
v4 API：用于创建逐行行级评论
- 基础地址：https://api.gitcode.com/api/v4
- 认证方式：PRIVATE-TOKEN 请求头
- 接口：POST /projects/{encoded_project}/merge_requests/{mr_iid}/discussions

评论 JSON 格式

[
  {
    "path": "relative/path/to/file.py",
    "line": 42,
    "severity": "严重",
    "problem": "描述问题",
    "reason": "解释为什么这是个问题",
    "fix": "给出修改建议",
    "side": "RIGHT"
  }
]

path：相对仓库根目录的文件路径
line：新文件中的行号
severity：问题级别，建议使用 严重、建议、提示；脚本兼容旧值 Critical、Improvement、Nitpick
problem：当前代码具体有什么问题
reason：为什么这是个问题，以及会产生什么影响
fix：建议如何修改，可附带 Markdown 代码示例
body：可选的旧版输入；如果提供，脚本会将其规范化为四段式 严重程度、问题、原因、怎么改
side："RIGHT" 表示新代码，"LEFT" 表示被删除的旧代码

external-mindstudio-gitcode-code-reviewer

来源信息

安装方式

检查来源文件

同仓库更多 Skills

同仓库更多 Skills

GitCode 代码审查助手

前置要求

GitCode 访问令牌

获取 GitCode 令牌

工作流程

1. 解析 PR 信息

2. 获取 PR 信息

3. 准备分析工作区

4. 构建审查上下文（必做）

5. 深入审查代码

6. 整理审查结论

7. 先向用户展示审查结果

8. 将评论发布到 PR（可选）

9. 清理临时目录

审查语气要求

审查底线

脚本说明

fetch_pr_info.py

post_pr_comment.py

setup_token.py

参考资料

技术说明

API 版本

评论 JSON 格式

GitCode 代码审查助手

前置要求

GitCode 访问令牌

获取 GitCode 令牌

工作流程

1. 解析 PR 信息

2. 获取 PR 信息

3. 准备分析工作区

4. 构建审查上下文（必做）

5. 深入审查代码

6. 整理审查结论

7. 先向用户展示审查结果

8. 将评论发布到 PR（可选）

9. 清理临时目录

审查语气要求

审查底线

脚本说明

fetch_pr_info.py

post_pr_comment.py

setup_token.py

参考资料

技术说明

API 版本

评论 JSON 格式