GitCode Code Review Assistant

Perform "context-aware" code reviews for GitCode PRs. The

diff

is just an entry point, not all evidence; you must combine PR title/description, changed files, call chains, adjacent modules, historical implementations, tests and configurations to determine if the changes are truly correct.

Prerequisites

GitCode Access Token

This skill requires a GitCode access token to obtain PR information and publish comments. The token can be configured in one of the following ways:

Environment Variable (Recommended):
```
GITCODE_TOKEN
```

Git Configuration:

git config --global gitcode.token <your-token>

If no token is found, prompt the user to provide one.

Obtaining a GitCode Token

Log in to https://gitcode.com
Click your avatar and enter "Settings"
Open "Personal Tokens"
Create a new token and grant the following permissions:
- ```
pull_requests
```
  (Read/Write)
- ```
issues
```
  (Read/Write)
- ```
projects
```
  (Read-only)

Workflow

1. Parse PR Information

When the user provides a GitCode PR link like

https://gitcode.com/Ascend/msprof/pull/109

Extract:
```
owner=Ascend
```
,
```
repo=msprof
```
,
```
pull_number=109
```

2. Retrieve PR Information

Use

scripts/fetch_pr_info.py

to get PR details:

bash

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

This script will retrieve:

PR metadata such as title, description, author, status
Changed files and their diff content
PR comments (optional)

3. Prepare Analysis Workspace

Prioritize using the user's current workspace; if the current directory is already the target repository and the PR's corresponding branch or commit is accessible, analyze directly in the current repository without cloning again.

Only clone to a temporary directory if the current workspace is not the target repository or the PR's corresponding code cannot be obtained:

bash

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}"

# Fetch PR branch
git fetch origin "refs/merge-requests/<NUMBER>/head:pr-<NUMBER>-source"
git checkout "pr-<NUMBER>-source"

4. Build Review Context (Mandatory)

Read

summary.json

pr_metadata.json

pr_files.json

pr_diff.patch

first before reviewing code. You must answer the following questions:

What problem is this PR trying to solve?
- Infer the goal from the title, description, tags, linked issues, and file distribution—whether it's fixing a bug, adding a feature, refactoring, supplementing tests, rolling back, or compatibility fixes.
- If the PR description is insufficient, summarize the purpose based on the changes and explain your reasoning in the conclusion.
Which layer of the system do the changes belong to?
- Identify whether the changed files belong to the entry layer, core logic layer, data model layer, interface/protocol layer, configuration/build layer, test layer, or generated artifacts.
- If they are generated files, lockfiles, or SDK artifacts, trace back to the "source files" for review instead of only commenting on the generated results.
Which implementations in the repository are related to these changes?
- Check callers, callees, similar implementations, adaptation layers, configuration items, feature flags, schemas, migration scripts, test fixtures, and documentation.
- When reviewing, you must look at the context files of the modified lines, not just the patch hunk.
What is the baseline behavior?
- Confirm the original behavior through the base branch code, historical commits, or existing tests, then determine if this change breaks compatibility or omits branches.

Recommended tools to build context:

```
rg -n "<symbol>|<config>|<endpoint>" .
```
: Check call chains, configuration items, similar implementations, test coverage
```
git diff --stat <base_sha>...<head_sha>
```
: Quickly identify high-risk change areas

git diff --name-only <base_sha>...<head_sha>

: Group changed files by module

```
git show <base_sha>:<path>
```
: Compare baseline implementations
```
git log --follow -- <path>
```
: View file evolution and historical intent
```
git blame -L <start>,<end> -- <path>
```
: Locate historical context and responsible parties
Project-specific test/build commands: Verify if your inferences are valid

If a conclusion relies on inference rather than direct evidence, clearly state the conditions, e.g., "If empty set input is allowed here, then the current implementation will...". Do not present guesses as facts.

5. In-Depth Code Review

After building the context, review from the following dimensions and try to combine the project's actual implementation to make judgments:

Goal Consistency: Does the implementation truly meet the PR's goal? Are only surface changes made while necessary changes in the call chain are missed?
Correctness and Regression Risk: Is the old behavior accidentally changed? Are boundary conditions, exception paths, and state transitions complete?
Contract Compatibility: Are function signatures, interface fields, return values, serialization formats, error codes, and configuration items compatible with upstream and downstream?
Project Consistency: Does it deviate from existing patterns in the repository, leading to higher maintenance costs or inconsistent behavior?
Performance and Resources: Does it introduce unnecessary traversals, repeated I/O, lock contention, cache invalidation, N+1 calls, etc.?
Security: Risks such as input validation, permission boundaries, sensitive data handling, command/SQL/path injection
Testability: Are critical branches supported by tests? If there are no tests, at least indicate what types of use cases should be added

6. Organize Review Conclusions

Organize issues by severity:

Critical: Will cause bugs, security issues, or breaking changes
Suggestion: Suggest optimizing code quality, performance, or implementation methods
Hint: Formatting, style, or other optional minor issues

By default, focus on findings that truly affect behavior, reliability, compatibility, and maintainability; do not pile pure style opinions as main conclusions.

Each finding must include:

File path
Line number
Severity
Four-part structure:
1. Severity: Clearly mark the issue level, consistent with actual impact
2. Problem: Specifically point out what is wrong with the current code
3. Reason: Explain why this is a problem, what risks or impacts it will bring, and try to relate it to which implementation, call chain, or existing constraint in the repository
4. Fix: Provide executable modification suggestions, attach code examples if necessary

Additional requirements:

Do not only repeat the surface phenomenon of the diff; each important comment should reflect that you have checked the surrounding context
If the problem comes from "incomplete changes", explain which files, branches, call points, or tests are missing
If no issues are found, clearly state which key contexts you have checked instead of just saying "LGTM"

7. Show Review Results to the User First

Before officially publishing comments, present the review results to the user:

markdown

## Code Review Summary

**PR**: [Title](URL)  
**Author**: @author  
**Conclusion**: [Approved / Request Changes]

### Issues Found

#### 🔴 Critical Issues (N)
1. **File**: `path/to/file.py` (Line 42)
   - **Severity**: Critical
   - **Problem**: Describe the issue
   - **Reason**: Explain the reason
   - **Fix**: Provide code examples

#### 🟡 Improvement Suggestions (N)
...

#### 🟢 Detail Suggestions (N)
...

### Summary
[Provide clear conclusion and its reasons]

In the summary, in addition to listing issues, add a short "Review Coverage" section to briefly describe the key contexts you have checked, e.g., "Checked callers

A/B

, compared baseline implementation

, confirmed test coverage of

8. Publish Comments to the PR (Optional)

First ask the user: "Do you want to publish these findings as line-by-line comments to the PR?"

If the user confirms, create a comment JSON file and use

scripts/post_pr_comment.py

to publish:

bash

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

Example Comment Body (Four-part Structure):

markdown

**Severity:** Suggestion

**Problem:** There are inconsistent spaces in the code

**Reason:** `node = int (node_str)` does not comply with PEP 8 standards, affecting readability

**Fix:**
```python
# Before modification
node = int (node_str)

# After modification
node = int(node_str)
```

Prioritize using structured fields in

comments.json

severity

problem

reason

fix

scripts/post_pr_comment.py

will uniformly organize these fields into a four-part Markdown body before publishing, defaulting to Chinese severity values (

严重

建议

提示

), and also compatible with old English values and old three-part

body

content.

9. Clean Up Temporary Directory

After the review is completed, clean up the temporary repository:

bash

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

Review Tone Requirements

Keep constructive, professional, and friendly
Clearly explain why modifications are needed
If giving an approval conclusion, clearly point out the value of this submission
Use respectful expressions, avoid imperative tone
All findings must use the four-part structure
Each comment focuses on only one issue, and the severity must match the actual risk
Line-level comments should be as specific and executable as possible, avoiding conclusions without modification directions
Prioritize pointing out issues that truly affect business or system behavior, and give fewer generic suggestions脱离项目上下文

Review Bottom Lines

Do not draw conclusions based only on diff; diff is just a positioning entry point
Do not output low-value comments just to meet quantity requirements
Do not ignore tests, configurations, call chains, and compatibility impacts
When uncertain, first supplement code search and context verification before deciding whether to raise an issue

Script Explanations

fetch_pr_info.py

Used to retrieve PR information from GitCode API.

bash

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

post_pr_comment.py

Used to publish comments to GitCode PRs.

Publish line-by-line comments:

bash

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

Publish overall review conclusion:

bash

python scripts/post_pr_comment.py \
  --owner OWNER \
  --repo REPO \
  --pull-number NUMBER \
  --body "Review Summary" \
  --review-event COMMENT|APPROVE|REQUEST_CHANGES

setup_token.py

Used to configure and verify GitCode access tokens.

bash

# Interactive configuration
python scripts/setup_token.py

# Only verify existing token
python scripts/setup_token.py --verify-only

Reference Materials

GitCode API Documentation: See references/gitcode_api.md
For API details, read the corresponding reference files as needed

Technical Notes

API Versions

GitCode supports two sets of APIs: v4 (compatible with GitLab) and v5 (compatible with GitHub):

v5 API: Used to retrieve PR information, file lists, and regular comments
- Base URL:
```
https://api.gitcode.com/api/v5
```
- Authentication:
```
PRIVATE-TOKEN
```
  request header

v4 API: Used to create line-by-line comments

Base URL:
```
https://api.gitcode.com/api/v4
```
Authentication:
```
PRIVATE-TOKEN
```
request header

Endpoint:

POST /projects/{encoded_project}/merge_requests/{mr_iid}/discussions

Comment JSON Format

json

[
  {
    "path": "relative/path/to/file.py",
    "line": 42,
    "severity": "严重",
    "problem": "Describe the issue",
    "reason": "Explain why this is an issue",
    "fix": "Provide modification suggestions",
    "side": "RIGHT"
  }
]

```
path
```
: File path relative to the repository root
```
line
```
: Line number in the new file
```
severity
```
: Issue level, recommended to use
```
严重
```
,
```
建议
```
,
```
提示
```
; the script is compatible with old values
```
Critical
```
,
```
Improvement
```
,
```
Nitpick
```
```
problem
```
: Specific issue with the current code
```
reason
```
: Why this is an issue and what impact it will have
```
fix
```
: Suggestions for modification, can include Markdown code examples
```
body
```
: Optional old-format input; if provided, the script will normalize it into the four-part structure of
```
Severity
```
,
```
Problem
```
,
```
Reason
```
,
```
Fix
```
```
side
```
:
```
"RIGHT"
```
indicates new code,
```
"LEFT"
```
indicates deleted old code

external-mindstudio-gitcode-code-reviewer

NPX Install

Tags

SKILL.md Content (Chinese)

GitCode Code Review Assistant

Prerequisites

GitCode Access Token

Obtaining a GitCode Token

Workflow

1. Parse PR Information

2. Retrieve PR Information

3. Prepare Analysis Workspace

4. Build Review Context (Mandatory)

5. In-Depth Code Review

6. Organize Review Conclusions

7. Show Review Results to the User First

8. Publish Comments to the PR (Optional)

9. Clean Up Temporary Directory

Review Tone Requirements

Review Bottom Lines

Script Explanations

fetch_pr_info.py

post_pr_comment.py

setup_token.py

Reference Materials

Technical Notes

API Versions

Comment JSON Format