---
name: mergisi/pr-first-review
source: https://app.decimal.ai/s/mergisi-pr-first-review@1/SKILL.md
source_sha256: fe5260ff19a0
---

# PR First Review

A first-pass code review for incoming pull requests. Catches the obvious things — failing tests, security anti-patterns, scope creep, breaking changes — and leaves comments before the maintainer opens the PR. The maintainer's review starts from "is this AI right?" instead of "what does this PR do?".

## What this skill does

For every new PR (or new commit on an existing PR):

1. **Read the diff and the description** — what files changed, what the author claims they did, whether tests were added.
2. **Run the OWASP Top 10 pattern check** on the diff: SQL injection (string concatenation into queries, raw ORM calls), XSS (dangerouslySetInnerHTML, unescaped output), IDOR (resource access without auth checks), SSRF (server-side fetch from user-controlled URLs), broken auth (missing session validation), XXE, mass assignment.
3. **Style and convention check** — does the change match the repo's established style (config file naming, error handling patterns, log format)? Is there a `.eslintrc` / `.prettierrc` / framework convention being violated?
4. **Scope check** — does the PR do what its title/description claims, or did it sneak in unrelated changes? Flag any out-of-scope file in a separate comment.
5. **Breaking-change detection** — function signatures changed? Public API field renamed? Migration script added? If yes and there's no CHANGELOG / version bump, flag it.
6. **Test coverage** — did the PR change behavior without adding/updating a test? Comment with the specific behavior that should have a test.
7. **Block or flag** — if a high-severity issue is found (RCE, exposed secrets, unauthenticated PII endpoint), request changes via the GitHub API. Otherwise, leave comments inline and let the human decide.

## What this skill does NOT do

- It does NOT replace a real static analyzer like Semgrep or CodeQL. Use those alongside for taint tracking and deep dataflow analysis.
- It does NOT auto-merge or auto-approve PRs. Default behavior is comment-only; "request changes" requires explicit configuration.
- It does NOT review architectural decisions or product fit — that's the human's call. It catches mechanical problems.
- It does NOT review every line. The default config skips lockfiles, generated files (`*.min.js`, `dist/`), and snapshot tests.

## How to invoke

Default trigger is the GitHub `pull_request.opened` and `pull_request.synchronize` webhooks. Configure via `hermes webhook list`. For manual run:

```
/pr-first-review owner/repo#312
```

## Configuration

```yaml
github:
  default_repo: "owner/repo"
  block_on_high_severity: false   # set true to actually request changes
  skip_paths:
    - "package-lock.json"
    - "yarn.lock"
    - "pnpm-lock.yaml"
    - "**/*.min.js"
    - "dist/**"
    - "__snapshots__/**"
  severity_thresholds:
    high: ["sql_injection", "xss", "ssrf", "exposed_secret", "broken_auth"]
    medium: ["scope_creep", "missing_test", "style_violation"]
    low: ["typo", "unused_import"]
  comment_style: "constructive"   # alternative: "terse"
```

## Models

PR review needs nuance — a Haiku-class model will miss security-relevant context.

- **Recommended:** Claude Sonnet 4.6 or GPT-5.5 standard. The accuracy gap between Haiku and Sonnet on real PRs is large (~30 percentage points on OWASP catch rate in our testing).
- **For monorepos:** If you review 50+ PRs/month, set up a tiered config — Haiku for the diff summary, Sonnet for the security pass.
- **Avoid:** Opus on every PR is overkill unless the codebase is highly security-sensitive.

## Real-world calibration

Out of the box this skill produces ~10-15% false positives. Calibrate over the first 30 days:

- If it flags too many style issues, narrow the rules in your `.eslintrc` or remove style from `severity_thresholds.medium`.
- If it misses real security issues, run Semgrep alongside and tune the SKILL.md prompts based on what Semgrep caught.
- For repos with unique patterns (Rails mass-assignment, Phoenix contexts, Go interfaces), add repo-specific rules to the SKILL.md `metadata` block.

## Pairing

Pairs naturally with [`github-issue-triage`](../github-issue-triage/) — issues come in, get triaged; PRs go out, get reviewed. Both should run as the same agent under the [`triager`](../../personalities/triager.md) personality.

## Want the full GitHub maintainer crew?

The 4-agent GitHub Maintainer Team ships with this skill plus changelog automation, docs sync, and shared coordination via AGENTS.md. See [crewclaw.com/use-cases/github-maintainer-team](https://crewclaw.com/use-cases/github-maintainer-team).