The Onboarding Tutor — A Five-Day Curriculum Calibrated to a Real Codebase
I'm joining this team Monday. Read the codebase. Generate me a personalized five-day curriculum where each day is a real PR-sized exercise on actual files. By Friday I should be productive.
Why this exists
Generic onboarding wastes the first week. New hires read wikis, shadow standups, and skim architecture diagrams written eighteen months ago by someone who already left. They emerge oriented but not productive — they can describe the system without being able to change it. The productive first week is the one that ships small, real change. Five tiny PRs beat five days of reading every time, because every PR forces contact with the build, the review process, the test suite, and a senior engineer's attention. Reading is passive. Shipping is the only thing that makes a codebase yours.
What you get back
- Five day-by-day plans, each scoped to a single working session.
- Concrete files to touch on each day, named from the actual repo — not "explore the auth module."
- A real bug or small feature to ship each day, pulled from issue tracker patterns or stale TODOs in the code.
- Expected duration for each exercise so you know when to ask for help instead of grinding.
- The senior engineer best suited to review each PR, inferred from git blame and CODEOWNERS.
- A Friday capstone PR worth opening — small enough to land, large enough to mean something.
When to reach for this pattern
Every new hire on day one. Internal team transfers, where the engineer is senior but the codebase is foreign. Consultants and contractors ramping into a client repo on a deadline. Open-source maintainers welcoming a first-time contributor. And — the underrated case — yourself, returning to a project you wrote six months ago and no longer remember. The tutor doesn't care who you are. It cares what you're about to touch.
I'm joining this team Monday. Read the codebase. Generate a
personalized five-day curriculum: each day is one PR-sized exercise
that builds on the last. Use the actual files I'd touch and a real
bug or improvement I'd hunt. Day 1 should be safe and observational.
Day 5 should ship code that lands. By Friday I should be productive
in this codebase, not just oriented to it.Paste this into Claude, Cursor, or Copilot. Change one thing that matters to you.
What I learned shipping it
- Onboarding docs are written for the median engineer who doesn't exist. Yours is calibrated to this repo, this week, this hire.
- A curriculum that compresses weeks into days isn't faster reading — it's targeted doing. Each day is a PR, not a page.
- The best teacher of a codebase is a model that has actually read all of it. Tribal knowledge becomes a syllabus.