Timebox Your First PR: A 90-Minute Onboarding Log for New Repos

Most first PRs fail for process reasons, not coding reasons.

The fix is cheap. Log your first 90 minutes in a new repo. Then attach that log to your first pull request.

This post gives you a small bash script, a timebox table, and explicit stop rules. It also explains where a free cloud box fits when your laptop cannot reproduce CI.

Why hour one decides your first PR

You join a repo you have never run. You read code for two hours. You patch something small. Tests pass locally, then fail during review.

The reviewer asks one question. "What was the baseline?" You do not know.

That is the entire failure. The order was wrong, not your skill.

So flip the order. Record first, patch second. Your log becomes evidence a reviewer can replay.

Agent tooling keeps improving. Onboarding discipline has not kept up.

The artifact: a JSONL onboarding log

Save this file as onboard-log.sh on a scratch branch.

#!/usr/bin/env bash
# onboard-log.sh - append JSONL breadcrumbs during your first repo day.
# Usage:
#   ./onboard-log.sh fingerprint
#   TEST_CMD="npm test" ./onboard-log.sh baseline
#   ./onboard-log.sh note "auth tests need redis on 6379"
#   ./onboard-log.sh report
set -uo pipefail

LOG="${ONBOARD_LOG:-onboard.jsonl}"
PHASE="${1:-report}"
shift || true
TEST_CMD="${TEST_CMD:-}"
BASELINE_LOG="${TMPDIR:-/tmp}/onboard.baseline.log"

iso() { date -u +"%Y-%m-%dT%H:%M:%SZ"; }
sha() { git rev-parse --short HEAD 2>/dev/null || echo no-git; }

emit() {              # $1 phase, then raw key=value pairs
  local phase="$1"; shift
  local extra=""
  for kv in "$@"; do
    [ -n "$kv" ] && extra="$extra,\"${kv%%=*}\":\"${kv#*=}\""
  done
  printf '{"at":"%s","phase":"%s","head":"%s"%s}\n' \
    "$(iso)" "$phase" "$(sha)" "$extra" >> "$LOG"
}

case "$PHASE" in
  fingerprint)
    emit fingerprint "bash=${BASH_VERSION%%(*}" "node=$(node -v 2>/dev/null || echo none)"
    ;;
  baseline)
    [ -n "$TEST_CMD" ] || { echo "set TEST_CMD first" >&2; exit 2; }
    t0=$(date +%s)
    bash -c "$TEST_CMD" >"$BASELINE_LOG" 2>&1
    code=$?
    emit baseline "exit=$code" "secs=$(( $(date +%s) - t0 ))"
    echo "baseline exit=$code  log=$BASELINE_LOG"
    ;;
  note)
    emit note "note=${1:-}"
    ;;
  report)
    [ -f "$LOG" ] || { echo "no log yet" >&2; exit 1; }
    awk -F'"' '{for(i=1;i<=NF;i++) if($i=="phase") print $(i+2)}' "$LOG" \
      | sort | uniq -c
    tail -n 1 "$LOG"
    ;;
  *)
    echo "phases: fingerprint baseline note report" >&2; exit 2 ;;
esac

Four phases, four commands. Run them in this order.

1. Fingerprint the machine before you read any code.

./onboard-log.sh fingerprint

1. Branch from main and record the baseline on a clean checkout.

git switch -c onboard/scratch main
TEST_CMD="npm test" ./onboard-log.sh baseline

1. Write notes while reading. Do not edit product code yet.

./onboard-log.sh note "auth suite needs redis on 6379"

1. Print the summary before you open the PR.

./onboard-log.sh report

The report prints one count per phase plus the last entry. A reviewer can replay your first hour in seconds.

Timebox the day in five windows

Window	Action	Exit condition
0-20 min	fingerprint + find the test entry point	you can name the test command
20-35 min	baseline on a clean checkout	exit code written to the log
35-55 min	write one failing test	it fails for the right reason
55-80 min	patch the smallest path	new test passes, baseline still passes
80-90 min	open the PR with the log	reviewer sees one behavior change

Stop at the window boundary. Say what you finished and what comes next. That message beats a rushed patch.

Three ways this goes wrong

Baseline is red on a clean checkout. Stop immediately and report it. Do not fix it in your first PR.

Baseline is green only on your machine. Your fingerprint line will show a different runtime. Fix the environment, not the test.

Your log has no baseline entry. The PR cannot be judged. Skipped steps are invisible, so leave a note instead.

Where a hosted box fits

Some repos will not build on a laptop. Old Node versions, native modules, a database you cannot install locally.

That is the honest use case for a remote environment. Run the fingerprint and baseline steps on a free hosted box, then copy onboard.jsonl back into your branch.

MonkeyCode is an open-source coding-agent project that, per its maintainers, offers free model access and a free server option. Its site currently lists a free token allowance; treat that figure as current-at-writing and verify it on the project's own page before you plan around it.

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

The value here is narrow and testable. The remote box removes environment noise from step 2. Free model access helps only with small questions, like "which fixture seeds this table?" Keep those answers in your notes.

Do not route security review or architecture decisions through a chat box. That work stays with you.

Limits and who should skip this

The script needs bash 4 or newer and a repo with one test command. Monorepos with per-package commands need one baseline entry per package.

Notes containing quotes get mangled by the simple escape used here. Keep notes plain ASCII, or store them elsewhere.

Skip this if your repo holds regulated or proprietary code and you have not read the hosting terms. Skip it if your team already has a trusted CI baseline. Skip it if you need a decision today, because a log costs 90 minutes.

If you want a box for step 2 without provisioning one, MonkeyCode's free tier is one option to evaluate. The log file is the part that matters.

What to take away

Record before you patch. Timebox every window. Stop when the log tells you to stop.

Your first PR should be small, explainable, and replayable. This log makes all three true.