All playbooks
ModerateHalf a dayDevelopers inheriting legacy code, solo builders

Get up to speed on an unfamiliar codebase

Inheriting someone's project, or returning to your own repo from six months ago: have the structure and call graph explained before you touch anything.

What you end up with

  • A queryable map of the project so you know where things live
  • Answers like 'who calls this function' instead of grep-and-guess
  • Your first change lands with tests behind it

The sequence

  1. 1. Index the structure before letting AI edit anything

    Ask an assistant to edit without context and it only sees the files you pasted; the change won't fit the rest of the project. Turning the whole repo into a queryable structure is the prerequisite for everything after.

  2. 2. Make the first change with a terminal coding agent

    Pick an agent that reads the repo, runs tests and sees failures. Deliberately make the first change small — a bug fix or a new flag — to test whether it actually understands this project.

  3. 3. Give the agent your project's rules

    Write your style, directory conventions and prohibitions into a file the agent always reads. This is the difference between occasional lucky output and consistently following your rules.

Only need one piece of this?

You don't have to build the whole chain. Every tool above is listed on its own, with a summary, pros and cons, and a starting point.

NextAutomate the work you repeat every day