vrr/qwen-code
2
0
Fork 0
mirror of https://github.com/QwenLM/qwen-code.git synced 2026-05-22 03:03:56 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 10

fix(review): detect old review comments + require line numbers

Browse source 
Two issues found from real review (PR #2826):

1. Multiple /review runs on same PR create duplicate comments. Now
   Step 9 checks for existing "via Qwen Code /review" comments
   before posting and warns the user about potential duplicates.

2. Comments posted without line numbers appear as orphaned PR
   comments. Now enforced: every inline comment MUST reference a
   specific line in the diff. Findings that can't be mapped to
   diff lines go in the summary instead.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
wenshao 2026-04-08 05:20:12 +08:00
parent ab72b5e6bb
commit bb85768adf
1 changed files with 4 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

4
packages/core/src/skills/bundled/review/SKILL.md
View file

@ -393,8 +393,12 @@ First, determine the repository owner/repo. For **same-repo** reviews, run `gh r
Use the **pre-autofix HEAD commit SHA** captured in Step 1 (not a fresh `gh pr view` call — autofix may have pushed new commits that shift line numbers). If the SHA was not captured in Step 1, fall back to `gh pr view {pr_number} --json headRefOid --jq '.headRefOid'`.
**Before posting any comments**, check for existing Qwen Code review comments on this PR: run `gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --jq '.[] | select(.body | test("via Qwen Code /review")) | .id'`. If previous Qwen Code comments exist, inform the user: "Found N existing comments from a previous Qwen Code review. Posting new comments may create duplicates." Let the user decide whether to proceed or skip Step 9.
Then, for each confirmed finding that is **Critical or Suggestion severity**, post an **inline comment** on the specific file and line using `gh api`. Skip "Nice to have" findings (including linter warnings) — they appear in the terminal output but are too noisy for PR comments.
⚠️ **Every inline comment MUST reference a specific line in the diff.** If a finding cannot be mapped to a line that exists in the diff (e.g., the issue is in unchanged code or spans the entire file), do NOT post it as an inline comment — include it in the review summary instead. Comments without line numbers appear as orphaned PR comments and create noise.
**Shell safety:** Review content may contain double quotes, `$VAR`, backticks, or other shell-sensitive characters. Do NOT interpolate review text directly into shell arguments. Instead, use a **two-step process**: write the body to a temp file using the `write_file` tool (which bypasses shell interpretation entirely), then reference the file with `-F body=@file` in the shell command.
For pattern-aggregated findings (multiple locations), post the comment on the most representative location and reference the other locations in the comment body.