Your first PR is a culture test, not a code test.

Most onboarding advice teaches you the code. That is the easy half. The hard half is knowing what reviewers on this team reject on sight.

You can learn that from data already in the repo. Merged PRs and their review comments are usually readable by every contributor.

This post gives you a read-only script. Run it in your first hour. Turn twenty merged PRs into a checklist you can satisfy on the first attempt.

1. Why review history beats the style guide

A style guide tells you what the team says it wants. Review comments show what the team actually enforces. The gap between those two is where new contributors lose a week.

You are not looking for opinions. You are looking for repetition. A comment that appears once is taste. A comment that appears nine times is a rule.

Counting is boring and reliable. Reading twenty PRs by hand is neither.

2. Pull the last twenty merged PRs

You need the GitHub CLI. Check that you are authenticated first.

gh auth status

Then collect the merged PR list. Keep the output local and keep it small.

#!/usr/bin/env bash # review-intake.sh — read-only, writes only to /tmp set -euo pipefail REPO="${1:-$(gh repo view --json nameWithOwner -q .nameWithOwner)}" LIMIT="${2:-20}" OUT="/tmp/intake-$REPO" mkdir -p "$OUT" gh pr list --repo "$REPO" --state merged --limit "$LIMIT" \ --json number,title,additions,deletions,changedFiles \ > "$OUT/merged.json" jq -r '.[] | [.number, .additions, .deletions, .title] | @tsv' "$OUT/merged.json"

The size columns matter. If every merged PR touches two files and yours touches nineteen, that is a signal before review even starts.

3. Turn review comments into a frequency table

Now fetch the comment bodies. Reviews and inline comments live in two endpoints, so call both.

: > "$OUT/comments.txt" : > "$OUT/paths.txt" for n in $(jq -r '.[].number' "$OUT/merged.json"); do gh api "repos/$REPO/pulls/$n/comments" --paginate -q '.[].body' >> "$OUT/comments.txt" gh api "repos/$REPO/pulls/$n/reviews" --paginate -q '.[].body // empty' >> "$OUT/comments.txt" gh api "repos/$REPO/pulls/$n/comments" --paginate -q '.[].path // empty' >> "$OUT/paths.txt" done wc -l "$OUT/comments.txt"

If that line count is under fifty, stop here. Twenty PRs without comments teach you nothing about review culture.

Next, count the words reviewers repeat. Crude keywords are enough for a first pass.

grep -oiE '\b(test|tests|coverage|nit|squash|rebase|changelog|naming|typo|revert|scope|breaking|docs)\b' \ "$OUT/comments.txt" | tr 'A-Z' 'a-z' | sort | uniq -c | sort -rn | head -20

Read the top eight lines out loud. You now know what this team argues about.

4. Map the comments back to files

File paths tell you where the arguments concentrate. That is where your first PR should be careful, or absent.

sort "$OUT/paths.txt" | uniq -c | sort -rn | head -15

Three outcomes are common. Hot files are under active review pressure. Quiet files are safe first targets. Config and CI files often collect the angriest comments of all.

Write the top five paths into a note. You will use them when you pick your ticket.

5. Write the checklist before you write code

Convert frequencies into rules. Keep each line testable, so you can answer yes or no.

# My First-PR Checklist (from 20 merged PRs)  - [ ] Diff touches 3 files or fewer - [ ] Tests run locally; output pasted in the PR body - [ ] No changes under .github/ without asking - [ ] Commit messages squashed to one, per merged-PR pattern - [ ] Changelog entry added if docs/ appears in the diff - [ ] Reviewer tagged who reviewed similar files last month

Six lines is plenty. A checklist you finish beats a policy you skim.

6. Optional: let a model cluster the comments

Keyword counts miss synonyms. A model can group comments into themes like naming, test coverage, and scope creep.

This is where a free model endpoint helps. The MonkeyCode project offers free model access and a free server option, which is enough for a one-off clustering run on a small text file. Both are operator-supplied here; check current limits, terms, and data handling in the project's own documentation before you depend on them.

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

Two rules keep this step honest. First, feed comment text only if your org allows it. Review comments frequently quote private code. Second, verify every cluster against the raw lines that produced it. A cluster without a quoted line is a guess.

The script from step 3 stays the source of truth. The model only reorders it.

If you would rather not set up local tokens for a throwaway repo, running the script on a free server workspace is a reasonable alternative. Same rules apply: read-only calls, output to a temp directory.

7. Put your rollback line in the PR body

Write the revert command for your own PR before you open it. Paste it into the description under a heading called Rollback.

git revert -m 1 <merge-commit-sha>

Squash-merge repos are simpler. The command is git revert <sha> against the squashed commit.

Writing that line does two things. It proves you checked the merge strategy. It also gives the next person a copy-paste path when your patch breaks something at 2am.

If your PR cannot be reverted cleanly, the PR is too large. Split it.

Limitations

This method measures words, not severity. One blocking objection can outweigh twenty nits, and the script cannot tell them apart.

It also fails on young repos. Fewer than twenty merged PRs means noise, not patterns, and squashed histories hide commit hygiene entirely.

Comment counts skew toward chatty reviewers. Quiet reviewers still reject PRs, so treat the table as a starting hypothesis and confirm it with a human.

Who should skip this

Skip it if your team reviews in chat and merges without comments. Skip it if the repo is private and your org forbids any external model call. Skip it if you already have a maintained contributor guide that reviewers actually cite.

Everyone else: spend forty minutes in hour one. Open your first PR with fewer surprises, and with a revert line already written.