code-review

Name: code-review
Author: opendatahub-io

36stars74forks

How to install code-review?

opendatahub-io/ai-helpers/code-review

$npx -y skills add opendatahub-io/ai-helpers --skill code-review

Installs into the current project.

Summary

Perform AI code review on a GitLab MR or local branch. Reviews all commits since the base branch, produces structured JSON feedback with inline comments, and posts results to GitLab (CI) or displays them locally. Use when asked to review code changes, do a code review, or run ai-

Files · 1

View on GitHub

SKILL.md

1	# AI Code Review
2
3	Perform a structured code review of the current branch's changes and post
4	results to GitLab (in CI) or display them locally.
5
6	## Step 1: Review Code Changes
7
8	Review ALL commits in the branch since the base branch. The git workspace is
9	already checked out with the branch to review. Use git commands to inspect the
10	changes — do NOT access remote APIs (e.g., `glab` commands).
11
12	```bash
13	git log --oneline origin/main..HEAD
14	git diff origin/main..HEAD
15	```
16
17	Adjust the base branch name if different from `main` (e.g., `master`, `develop`).
18	In CI, `$CI_MERGE_REQUEST_DIFF_BASE_SHA` identifies the exact base commit.
19
20	Only review the committed diff between branches. Do NOT run `git status`,
21	do NOT report on untracked files, and do NOT include uncommitted working-tree
22	changes in your review.
23
24	### Review Guidelines
25
26	$ARGUMENTS
27
28	If no additional instructions were provided above, follow these defaults:
29
30	Provide constructive feedback that helps maintain code quality and follows
31	project best practices. Be selective and focused: only comment on issues that
32	genuinely matter. Do not comment for the sake of commenting. If the code is
33	well-written and follows best practices, it is perfectly acceptable to return
34	zero inline comments. Prioritize critical and major issues over minor stylistic
35	preferences. Avoid repeating the same type of feedback across multiple
36	locations — one representative comment is sufficient.
37
38	When referencing coding standards, security norms, best practices, or
39	component-specific behavior, search for and cite the authoritative source
40	(official documentation, RFCs, upstream references) to back up the claim.
41
42	## Step 2: Produce Review JSON
43
44	Write your review output as a JSON file at `/tmp/ai-review-output.json`.
45
46	The JSON must be a valid object matching this schema exactly:
47
48	```json
49	{
50	"summary": "Brief overall assessment of the changes (2-4 sentences, markdown allowed inside this string)",
51	"positive_aspects": ["List of good practices and well-implemented features"],
52	"inline_comments": [
53	{
54	"file": "path/to/file (relative to repo root)",
55	"line": 42,
56	"severity": "critical\|major\|minor\|suggestion",
57	"comment": "Description of the issue and suggested fix (markdown allowed inside this string)"
58	}
59	],
60	"fix_prompt": "Optional: a copy-paste prompt to fix all issues found. Omit this field if there are no actionable fixes."
61	}
62	```
63
64	### Inline comments rules
65
66	- ONLY comment on lines that appear in the diff (changed or added lines).
67	Do NOT comment on unchanged lines.
68	- Use the line number as it appears in the NEW version of the file.
69	- `file` must be the path relative to the repository root
70	(e.g., `src/main.py`, not `/workspace/src/main.py`).
71	- Severity levels:
72	- critical: Security vulnerabilities, build-breaking changes
73	- major: Significant logic errors, pattern violations
74	- minor: Style issues, minor improvements
75	- suggestion: Optional improvements for code quality
76	- Each comment should be self-contained and actionable.
77	- If there are no inline issues to report, use an empty array `[]`.
78
79	### Summary rules
80
81	- Keep it short (2-4 sentences). The inline comments carry the detail.
82	- Mention the overall quality and any critical concerns.
83
84	### Positive aspects rules
85
86	- List 1-3 things done well. If nothing stands out, use an empty array `[]`.
87
88	### Fix prompt rules
89
90	- Omit this field entirely if there are no actionable fixes.
91
92	## Step 3: Post Results
93
94	Run the `review.py` script from this skill's `scripts/` directory.
95	Execute it directly (not via `python`) to invoke uv via the shebang:
96
97	```bash
98	./scripts/review.py post /tmp/ai-review-output.json
99	```
100
101	The script auto-detects the platform (GitLab CI, GitHub, or local) and handles:
102
103	- JSON validation and chill-mode filtering (controlled by `$CHILL_MODE` env var)
104	- Deduplication against previous reviews (skips comments on unchanged code)
105	- Deleting previous AI review discussions on the MR (GitLab)
106	- Posting inline comments and a summary note to the MR (GitLab)
107	- Falling back to formatted terminal display when no CI platform is detected
108
109	If the script reports a JSON parse error, fix the JSON in
110	`/tmp/ai-review-output.json` and re-run the command.
111
112	## Step 4: Report Results
113
114	After the script completes successfully:
115
116	- CI: Confirm the review was posted to the merge request
117	- Local: The script displays

People who liked this also viewed

6 picks

Type

code-review

36stars74forks

View on GitHub

How to install code-review?

opendatahub-io/ai-helpers/code-review

$npx -y skills add opendatahub-io/ai-helpers --skill code-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# AI Code Review
2
3	Perform a structured code review of the current branch's changes and post
4	results to GitLab (in CI) or display them locally.
5
6	## Step 1: Review Code Changes
7
8	Review ALL commits in the branch since the base branch. The git workspace is
9	already checked out with the branch to review. Use git commands to inspect the
10	changes — do NOT access remote APIs (e.g., `glab` commands).
11
12	```bash
13	git log --oneline origin/main..HEAD
14	git diff origin/main..HEAD
15	```
16
17	Adjust the base branch name if different from `main` (e.g., `master`, `develop`).
18	In CI, `$CI_MERGE_REQUEST_DIFF_BASE_SHA` identifies the exact base commit.
19
20	Only review the committed diff between branches. Do NOT run `git status`,
21	do NOT report on untracked files, and do NOT include uncommitted working-tree
22	changes in your review.
23
24	### Review Guidelines
25
26	$ARGUMENTS
27
28	If no additional instructions were provided above, follow these defaults:
29
30	Provide constructive feedback that helps maintain code quality and follows
31	project best practices. Be selective and focused: only comment on issues that
32	genuinely matter. Do not comment for the sake of commenting. If the code is
33	well-written and follows best practices, it is perfectly acceptable to return
34	zero inline comments. Prioritize critical and major issues over minor stylistic
35	preferences. Avoid repeating the same type of feedback across multiple
36	locations — one representative comment is sufficient.
37
38	When referencing coding standards, security norms, best practices, or
39	component-specific behavior, search for and cite the authoritative source
40	(official documentation, RFCs, upstream references) to back up the claim.
41
42	## Step 2: Produce Review JSON
43
44	Write your review output as a JSON file at `/tmp/ai-review-output.json`.
45
46	The JSON must be a valid object matching this schema exactly:
47
48	```json
49	{
50	"summary": "Brief overall assessment of the changes (2-4 sentences, markdown allowed inside this string)",
51	"positive_aspects": ["List of good practices and well-implemented features"],
52	"inline_comments": [
53	{
54	"file": "path/to/file (relative to repo root)",
55	"line": 42,
56	"severity": "critical\|major\|minor\|suggestion",
57	"comment": "Description of the issue and suggested fix (markdown allowed inside this string)"
58	}
59	],
60	"fix_prompt": "Optional: a copy-paste prompt to fix all issues found. Omit this field if there are no actionable fixes."
61	}
62	```
63
64	### Inline comments rules
65
66	- ONLY comment on lines that appear in the diff (changed or added lines).
67	Do NOT comment on unchanged lines.
68	- Use the line number as it appears in the NEW version of the file.
69	- `file` must be the path relative to the repository root
70	(e.g., `src/main.py`, not `/workspace/src/main.py`).
71	- Severity levels:
72	- critical: Security vulnerabilities, build-breaking changes
73	- major: Significant logic errors, pattern violations
74	- minor: Style issues, minor improvements
75	- suggestion: Optional improvements for code quality
76	- Each comment should be self-contained and actionable.
77	- If there are no inline issues to report, use an empty array `[]`.
78
79	### Summary rules
80
81	- Keep it short (2-4 sentences). The inline comments carry the detail.
82	- Mention the overall quality and any critical concerns.
83
84	### Positive aspects rules
85
86	- List 1-3 things done well. If nothing stands out, use an empty array `[]`.
87
88	### Fix prompt rules
89
90	- Omit this field entirely if there are no actionable fixes.
91
92	## Step 3: Post Results
93
94	Run the `review.py` script from this skill's `scripts/` directory.
95	Execute it directly (not via `python`) to invoke uv via the shebang:
96
97	```bash
98	./scripts/review.py post /tmp/ai-review-output.json
99	```
100
101	The script auto-detects the platform (GitLab CI, GitHub, or local) and handles:
102
103	- JSON validation and chill-mode filtering (controlled by `$CHILL_MODE` env var)
104	- Deduplication against previous reviews (skips comments on unchanged code)
105	- Deleting previous AI review discussions on the MR (GitLab)
106	- Posting inline comments and a summary note to the MR (GitLab)
107	- Falling back to formatted terminal display when no CI platform is detected
108
109	If the script reports a JSON parse error, fix the JSON in
110	`/tmp/ai-review-output.json` and re-run the command.
111
112	## Step 4: Report Results
113
114	After the script completes successfully:
115
116	- CI: Confirm the review was posted to the merge request
117	- Local: The script displays

People who liked this also viewed

6 picks

Type