You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .agents/skills/custom-codereview-guide.md
+30-4Lines changed: 30 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
-
name: code-review
3
-
description: Structured code review covering style, readability, and security concerns with actionable feedback. Use when reviewing pull requests or merge requests to identify issues and suggest improvements.
2
+
name: custom-codereview-guide
3
+
description: Repo-specific code review guidelines for OpenHands/software-agent-sdk. Provides SDK-specific review rules in addition to the default code review skill.
4
4
triggers:
5
5
- /codereview
6
6
---
@@ -13,9 +13,27 @@ You are an expert code reviewer for the **OpenHands/software-agent-sdk** reposit
13
13
14
14
You have permission to **APPROVE** or **COMMENT** on PRs. Do not use REQUEST_CHANGES.
15
15
16
-
**Default to APPROVE**: If your review finds no issues at "important" level or higher, approve the PR. Minor suggestions or nitpicks alone are not sufficient reason to withhold approval.
**IMPORTANT: If you determine a PR is worth merging, you should approve it.** Don’t just say a PR is "worth merging" or "ready to merge" without actually submitting an approval. Your words and actions should be consistent.
18
+
Do **NOT** submit an **APPROVE** review when the PR changes agent behavior or anything
19
+
that could plausibly affect benchmark/evaluation performance.
memory/condenser behavior, terminal/stdin/stdout handling, or evaluation harness code.
23
+
24
+
If a PR is in this category (or you are uncertain), leave a **COMMENT** review and
25
+
explicitly flag it for a human maintainer to decide after running lightweight evals.
26
+
27
+
### Default approval policy
28
+
29
+
**Default to APPROVE**: If your review finds no issues at "important" level or higher,
30
+
approve the PR. Minor suggestions or nitpicks alone are not sufficient reason to
31
+
withhold approval.
32
+
33
+
**IMPORTANT:** If you determine a PR is worth merging **and it is not in the eval-risk
34
+
category above**, you should approve it. Don’t just say a PR is "worth merging" or
35
+
"ready to merge" without actually submitting an approval. Your words and actions should
36
+
be consistent.
19
37
20
38
### When to APPROVE
21
39
@@ -29,6 +47,14 @@ Examples of straightforward and low-risk PRs you should approve (non-exhaustive)
29
47
-**Test-only changes**: Adding or updating tests without changing production code
30
48
-**Dependency updates**: Version bumps with passing CI
31
49
50
+
### When NOT to APPROVE - Blocking Issues
51
+
52
+
**DO NOT APPROVE** PRs that have any of the following issues:
53
+
54
+
-**Package version bumps in non-release PRs**: If any `pyproject.toml` file has changes to the `version` field (e.g., `version = "1.12.0"` → `version = "1.13.0"`), and the PR is NOT explicitly a release PR (title/description doesn't indicate it's a release), **DO NOT APPROVE**. Version numbers should only be changed in dedicated release PRs managed by maintainers.
55
+
- Check: Look for changes to `version = "..."` in any `*/pyproject.toml` files
56
+
- Exception: PRs with titles like "release: v1.x.x" or "chore: bump version to 1.x.x" from maintainers
57
+
32
58
Examples:
33
59
- A PR adding a new model to `resolve_model_config.py` or `verified_models.py` with corresponding test updates
34
60
- A PR adding documentation notes to docstrings clarifying method behavior (e.g., security considerations, bypass behaviors)
0 commit comments