Pre Merge Check

---
name: pre-merge-check
description: Runs a pre-merge security and hygiene sweep on staged or changed code before opening or merging a pull request, scans for hardcoded secrets and credentials, checks dependencies for known vulnerabilities using whatever scanner fits the project (npm/pnpm/yarn audit, pip-audit, govulncheck, cargo-audit), and flags debug leftovers and unresolved TODOs. Use whenever the user says "is this ready to merge", "check this PR", "review before I push", "did I leave any secrets in this", or asks for a security pass on their changes. Trigger this proactively before you yourself open a PR on the user's behalf.
---

# Pre-Merge Check

A five-minute sweep that catches the mistakes everyone makes under deadline
pressure: a forgotten `console.log(apiKey)`, a dependency with a known CVE, a
TODO that quietly became permanent. None of it replaces real code review,
it's the mechanical part review shouldn't have to be.

## Step 1: secrets scan

Prefer a real scanner if one is installed:

```bash
which gitleaks && gitleaks protect --staged --verbose   # if installed
which trufflehog && trufflehog git file://. --since-commit HEAD --only-verified  # if installed
```

If neither is available, use the bundled fallback:

```bash
python3 <skill_dir>/scripts/scan_secrets.py          # scans staged git diff
python3 <skill_dir>/scripts/scan_secrets.py <path>   # scans a file or directory instead
```

It's a regex scanner, real but not exhaustive, treat any finding as worth a
second look rather than an automatic false alarm, and don't treat a clean
result as a guarantee. Findings are redacted in the output; if something
looks like a real secret, the fix is to rotate it, not just delete the line.

## Step 2: dependency vulnerability check

```bash
python3 <skill_dir>/scripts/check_dependencies.py <project_path>
```

This detects the project's ecosystem from its manifest file and runs the
matching scanner if it's installed (`npm audit`, `pnpm audit`, `yarn audit`,
`pip-audit`, `govulncheck`, `cargo-audit`). Read the result carefully:

- `"available": false` means the tool isn't installed, hand the user the
  `install_hint` rather than silently treating it as "no vulnerabilities."
  Those are different things.
- `"has_critical_or_high": true/false` is only trustworthy when it came from
  parsed structured output. If you see `"severity_undetermined"` or
  `"severity_method": "text-heuristic"` in the result, read `raw_output`
  yourself and judge it, don't repeat the boolean as fact.

## Step 3: quick hygiene pass

On the changed files (`git diff --cached --name-only`, or the relevant diff
if you're reviewing a PR that isn't staged locally), check for:

- Debug leftovers: `console.log`, `print(`, `debugger`, `pdb.set_trace()`,
  `dd(`, `var_dump` depending on language, judge by what's actually in the
  diff, not a fixed list.
- Commented-out code blocks that look abandoned rather than intentionally
  documented.
- `TODO`/`FIXME` comments with no ticket/issue reference nearby, worth a
  mention, not a blocker on their own.

This step doesn't need a script, grep the diff and use judgment; a `TODO`
inside a test fixture is not the same problem as one inside error handling
for a payment flow.

## Step 4: report back, don't gate silently

Summarize findings by severity, not just a raw list: secrets and
critical/high dependency issues first, hygiene notes last. If everything's
clean, say so briefly, don't pad a clean result with caveats to seem
thorough. If something needs a person's judgment (a finding that might be a
false positive, an unavailable scanner), say exactly that rather than
guessing on their behalf.

## Ground rules

- Never auto-fix a finding by deleting evidence (e.g. removing a line with a
  real secret) without telling the user, rotation comes first, then cleanup.
- Don't block a merge yourself, you're not the CI system, surface findings
  clearly enough that the human or the actual CI gate can decide.
- If both a real scanner and the bundled fallback are available, run the
  real one, the fallback exists for when nothing else is installed, not as a
  first choice.