Pr reviewer

Skill jpantsjoha/ai-native-developer-experience/.agents/skills/pr-reviewer

Team-wide AI harness adoption plugin, \w operating model, onboarding and delivery standards coherent human-agent outcomes from day one.

Install

npx -y skills add jpantsjoha/ai-native-developer-experience --skill pr-reviewer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

10 stars10 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Review gate for correctness, reuse, and simplification. Produces a structured verdict with actionable findings. Trigger on any PR before merge, or on any agent-generated code before it is committed.

SKILL.md

3.4 KB, as published. Nobody here has run it

PR Reviewer

Receipts, not polish. A review that says "looks good" is not a review. A review that says "line 47 will panic on a nil pointer and here is the fix" is a review.

This skill runs a structured code review and produces a verdict: approve, approve with comments, or request changes. Every finding is actionable. No findings without evidence.

When to use

Before merging any PR
When reviewing agent-generated code before committing
When a significant refactor or new feature is complete
As part of the release-readiness checklist

Procedure

Scope the review — fetch the diff. Identify:
- Files changed and their purpose
- The stated intent of the PR (what problem does it solve?)
- Any linked spec, issue, or ADR
Correctness pass — look for bugs, not style:
- Null / nil / undefined access on values that could be absent
- Off-by-one errors in loops or index operations
- Error returns that are silently ignored
- Race conditions if the code is concurrent
- Missing input validation at trust boundaries (user input, external API responses)
- Logic that diverges from the stated intent of the PR
Reuse pass — look for duplication:
- Does this code reimplement something that already exists in the codebase?
- Is there a stdlib or already-installed dependency that does this?
- Can the new code be expressed using an existing abstraction?
Simplification pass — look for unnecessary complexity:
- Can this be fewer lines without losing clarity?
- Is there an abstraction that has only one implementation? (remove it)
- Is there a dependency added for something a few lines of code would do?
- Is there "scaffolding for later" that should not exist yet?
Security and data boundary pass — look for:
- Secrets or credentials in code or logs
- User-controlled input reaching a shell, SQL query, or file path without validation
- Data crossing a tenant or trust boundary without an explicit check
- Missing authentication or authorisation checks on new endpoints
Classify findings:
- BLOCKING: must be fixed before merge (correctness bugs, security issues)
- SUGGESTED: improvement worth making but not a blocker (simplification, reuse)
- NOTE: observation for awareness, no action required
Produce the verdict:
- Approve: no BLOCKING findings
- Approve with comments: no BLOCKING findings, SUGGESTED improvements noted
- Request changes: one or more BLOCKING findings

Outputs

Finding list: location | severity | description | suggested fix
Verdict: Approve / Approve with comments / Request changes

Guardrails

Every BLOCKING finding must have a suggested fix. "This is wrong" is not actionable.
Style is not a BLOCKING finding. Style enforcement belongs in the linter, not the review.
Reuse requires evidence. "This might already exist" is not a finding. Find it or drop the comment.
The review is not a rewrite. Surface the issues; let the author fix them.

See also: REFERENCE.md for a quick lookup of common patterns and their preferred alternatives.