Marcos
76b6752f48
Gitea 1.26.x has no GitHub-style 'Apply suggestion' button — a ```suggestion fence is just an unknown-language code block, so chroma does not highlight it and there is no apply control. Switch inline_comment_body to wrap the suggested fix in a fence tagged with the file's language (new _lang_for_path helper, .java→java, .ts→typescript, .py→python, ...), so Gitea syntax-highlights the code. No capability lost (there was never an apply button on this Gitea version). Correct the docstrings/skills/README that wrongly claimed an apply-button was rendered. Co-Authored-By: Claude <noreply@anthropic.com>
58 lines
2.5 KiB
Markdown
58 lines
2.5 KiB
Markdown
---
|
|
name: review-methodology
|
|
description: pragent review methodology — severity rubric, what to report vs skip, anchoring rules, and how to honor repo focus. Load this before reviewing a PR.
|
|
---
|
|
|
|
# pragent review methodology
|
|
|
|
## Severity rubric
|
|
|
|
- **critical** — exploitable security bug, data loss/corruption, or a crash on
|
|
a normal input path. Must fix before merge.
|
|
- **high** — correctness bug on a real input path, broken contract, or a
|
|
missing test for security/error behavior. Should fix before merge.
|
|
- **medium** — likely bug on an edge case, missing test for changed logic, or a
|
|
risky pattern that isn't broken yet. Worth fixing.
|
|
- **low** — minor risk, stale expectation, or a defensive improvement. Nice to
|
|
have.
|
|
|
|
## Report vs skip
|
|
|
|
**Report:** correctness bugs, security problems, risky changes, missing tests
|
|
for changed behavior, breaking API/contract changes, N+1/O(n²) in hot paths.
|
|
|
|
**Skip:** praise, nitpicks, pure formatting/style, personal preference,
|
|
speculative "what if" without a concrete trigger, anything already covered in
|
|
`prior_reviews`.
|
|
|
|
Cap at ~15 findings, highest severity first. Quality over quantity — an empty
|
|
findings list for a clean diff is a correct result.
|
|
|
|
## Anchoring (for inline comments)
|
|
|
|
Each finding's `line` MUST be a line that exists in the POST-CHANGE version of
|
|
`path`:
|
|
- a **context** line (unchanged, shown with a leading space in the diff), or
|
|
- an **added** line (shown with a leading `+`).
|
|
|
|
Never anchor on a **removed** (`-`) line — it has no post-change line number.
|
|
If you're unsure of the exact line, use the closest context line you CAN see in
|
|
the diff. A misanchored finding becomes a summary bullet instead of an inline
|
|
comment, so correct anchoring is what gets a finding shown inline with its
|
|
suggested-fix code block (language-highlighted) rather than demoted to a bullet.
|
|
|
|
## Honoring repo config
|
|
|
|
If `.pr-review.json` is present, honor it:
|
|
- `focus` — weight these areas higher, but never ignore a critical issue
|
|
outside them.
|
|
- `exclude_paths` — skip findings in these paths.
|
|
- `languages` — hint to the primary languages; pick matching linters.
|
|
- `instructions` — house conventions / compliance language; treat as binding
|
|
reviewer rules.
|
|
|
|
## Linters are a signal, not the verdict
|
|
|
|
Run the repo's own typecheck/lint on changed files, but translate their output
|
|
into human findings — a raw `TS2322` is not a review comment. Correlate
|
|
diagnostics with the diff; ignore diagnostics in files the PR didn't touch. |