Scan the Diff Before You Request Agent Review

Do not request review on an agent patch yet.
A leaked secret outlives a bad function name.
Scan the diff, then write a replay note.

Start from the review gate

You are the new engineer on this repo.
Your first pull request should stay very small.
An agent may draft the patch for you.

You still decide what reviewers are allowed to see.
Treat the agent summary as an unverified claim.
Every claim needs a command you can rerun.

A confident paragraph is not evidence at all.
You need a command log beside that paragraph.
Git output beats a polished explanation every time.

Keep this hour narrow

Change only one behavior during this first hour.
Touch only the files that this behavior needs.
Leave lockfiles and migrations alone unless the ticket names them.

Do not explore the whole tree on this branch.
Do not ask the agent to clean unrelated files.
Wide diffs hide secrets and unrelated edits together.

Step 1: Freeze the base ref

Pick the base branch that reviewers already trust.
Write that ref down before you edit anything.
Do not guess the base ref from memory later.

git fetch origin
git rev-parse --abbrev-ref HEAD
git merge-base HEAD origin/main
git status --short

Stop if your working tree is not clean.
Stop if the base ref is missing locally.
A dirty tree makes this scan meaningless now.

Replace origin/main if your default branch name differs.
Ask a teammate for the real base name.
Do not invent a base just to pass.

The three-dot diff starts at the merge base.
It shows changes your branch introduced, not upstream noise.
A two-dot diff can blame files you never edited.

Step 2: Keep secrets out of the prompt

Never paste env file contents into a chat.
Never paste private keys, tokens, or customer rows.
Name the file path when the agent must avoid it.

Say which files the agent is allowed to touch.
Say which commands the agent is allowed to run.
Say that unknown files must stay completely untouched.

A free model does not make a secret safer.
The secret already left your machine in that paste.
Treat every prompt as a copy you may not recall.

Step 3: Run a diff scan before review

This script is only a proposal for you.
It is an unexecuted example for your branch.
Adapt the base ref and path rules first.

#!/usr/bin/env bash
# Unexecuted example. Review it before you run it.
set -euo pipefail

base="${1:-origin/main}"

if ! git rev-parse --verify "$base" >/dev/null 2>&1; then
  echo "FAIL: base ref not found"
  exit 2
fi

files="$(git diff --name-only "${base}...HEAD")"

if [ -z "$files" ]; then
  echo "FAIL: empty diff against $base"
  exit 2
fi

echo "FILES:"
printf '%s\n' "$files"

blocked='(^|/)(\.env|\.env\..*|id_rsa|id_ed25519|.*\.pem|.*\.p12|.*\.key|credentials\.json|secrets\.ya?ml)$'

if printf '%s\n' "$files" | grep -E "$blocked"; then
  echo "FAIL: sensitive path in diff"
  exit 1
fi

pattern='AKIA[0-9A-Z]{16}|-----BEGIN [A-Z ]*PRIVATE KEY-----|ghp_[A-Za-z0-9]{20,}|xox[baprs]-[A-Za-z0-9-]{10,}'

if git diff --unified=0 "${base}...HEAD" | grep -E -q "$pattern"; then
  echo "FAIL: possible secret text in diff"
  echo "Do not print the match in a shared log."
  exit 1
fi

echo "PASS: no blocked path or obvious token pattern"

Save the script outside the repository if possible.
Run it with the base ref as its argument.
Read each failure before you silence the script.

bash scan-first-diff.sh origin/main

A pass is not a full security audit.
It catches obvious paths and a few token shapes.
Your team scanner still matters when you have one.

The failure path can still reveal a secret nearby.
Run the scan in a private terminal, not a shared log.
If a real secret appears, rotate it with the owner.

Step 4: Use a decision table

Read this table before you push the branch.
Act on the row that you actually hit.
Do not blur two rows into a maybe.

Scan result	What you do	What you do not do
Sensitive path listed	Remove that file from the branch	Ask the model to ignore it in prose
Token-like text in the diff	Tell the credential owner and rotate	Hide the line and hope review misses it
Empty diff	Stop and restate the one behavior	Open review only to show effort
Pass, but a hunk is unexplained	Drop that hunk or ask a human	Ship the model explanation as your own
Pass, and you can replay the test	Write the replay note next	Add extra files for completeness

A shared branch needs a teammate before any rewrite.
This table does not teach you to force-push.
Ask the owner before you rewrite any public history.

Step 5: Fix a failure without hiding it

Do not delete the failing line from the log.
Copy the flagged path, then remove it from the branch.
Commit that removal before you rerun the scan.

If the file is new, delete it from the branch.
If the file is tracked, restore the base version with help.
Do not hide a flagged path inside gitignore.

Rerun the same script after that fix lands.
A second pass still needs the replay note.
Do not request review from a failing log.

Step 6: Write the replay note

Put this note in the pull request body.
A reviewer should rerun your checks without guessing.
Keep each line short enough to verify quickly.

## Replay note

- Base ref: origin/main
- Branch: your-branch-name
- One behavior: one sentence you can defend
- Allowed paths: list only those paths
- Command run: the exact test command
- Scan result: pass or fail, plus script name
- Not run: anything you skipped on purpose
- Model claim you rejected: one sentence, or none

Fill every line using your own words only.
Do not paste an agent summary over those lines.
If any line is unknown, the review is early.

Step 7: Use a remote run only as a tool

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode offers free model access and a free server option.
Both are availability claims supplied for this article, not measured results.
Current quotas, hardware, and time limits are not stated.

Check the current product docs before you rely on either.
Those offers can change, and this article will not track them.
Do not plan a deadline around an unverified limit.

Use the free model to draft replay note wording.
You still type the commands and read the output.
Use a free server only when your team allows that workspace.

Do not upload secrets so a remote scan looks better.
The scan should see the diff, not your password store.
If that workspace is unclear, run the script locally.

Read the current MonkeyCode docs before any remote run.
Try the scan on a branch you can delete.
Stop if the docs disagree with this article.

Step 8: Reject a yes from the model

Ask the agent which checks it actually skipped.
A short approval line is not a real scan.
Compare its file list with git diff output.

If those lists differ, believe git every time.
If the agent reports no secrets, rerun the script.
If you cannot explain a line, drop that line.

This is the habit you want on later reviews.
Your first review is where that habit starts.
Reviewers teach faster when your note stays honest.

Who should skip this workflow

Skip this if CI already blocks secret paths.
Follow that gate instead of a second unofficial script.
Skip this if you cannot open pull requests yet.

Skip this flow during an active production incident.
Incident work needs the on-call owner, not a first-hour test.
Skip this if the ticket requires production credentials.

That ticket needs a human owner, not an agent run.
You are still learning the review path on purpose.
An incident is the wrong classroom for this script.

Limits you should say out loud

The pattern list misses many private token formats.
It misses secrets that are split across lines.
It misses tokens that do not match these shapes.

The path list misses custom secret file names.
Add the secret names your repository actually uses.
Do not delete a team rule to match this example.

The script does not rotate any credential for you.
The script does not prove that your test passed.
The script does not make the agent accountable.

This example was not run against your repository.
Treat the listing as a starting point only.
Change it until a teammate accepts the blocked paths.

Before you request review

Run the scan and keep the last lines.
Paste the replay note in your own words.
Read the full diff with the agent closed.

Request review only when all three answers hold.
You can name the base ref from the command output.
You can name the exact test command you ran.

You can name every file you would defend.
If one answer fails, keep the branch in draft.
Fix that gap, or close the branch and start smaller.

A delayed first review is cheaper than a leaked key.
Leave the draft closed until those answers are easy.
Your name is on the pull request, not the model's.