The agent does the digging — git history, GitHub PRs, design docs, release notes — and writes a draft chapter. You read it critically, challenge every assumption, and ask the questions whose answers aren’t in any commit message. By the end of the chapter, you have the context of someone who’s been on the team for years — and the confidence to contribute like one.

You just joined the team

You open the repo. 2,000 commits. 200+ tickets. 14 contributors. Half don’t work here anymore. The README was last updated in 2023. What do you do?

option A: wing it

option B: hack right?

option C: be Indiana Jones

You dig. You don’t read 2,000 commits — you read a book the agent writes for you. Then you sit with it and ask the questions that turn information into understanding.

Read it like a book — chapter by chapter

A book is structured. It has chapters. Each chapter has a thesis, evidence, and the parts the author chose to leave out. You read books critically — you mark margins, you push back on the framing, you check the citations.

That’s exactly the loop. Run /dig in Claude Code, OpenCode, or Cursor, in any repo with git history.

1. Survey the dig site Commits, contributors, releases, RFCs, infra files, the suspicious silence around legacy_v2/. Where’s the rich seam on this project?

2. Identify the chapters Team transitions, migrations, the Great Refactor of 2022, the incident that shall not be named. Each one a chapter you’ll read.

3. Deep-dive, one chapter at a time What happened, who did it, why, and what got abandoned along the way. Enough context to ask good questions — not a wall of text.

4. Push back. Hard. Why not the simpler thing? What breaks if this is wrong? Was this eventually replaced? Whose call was this and what were they optimising for? The chapter writes itself into chapters/<n>.md as you talk.

Step 4 is the whole point. Steps 1–3 produce a draft — a thing to react to. Real understanding lives in the conversation: the assumptions you challenge, the alternatives you forced into the open, the answers that don’t appear in any commit message. Reading is the prep. Arguing is the learning.

Questions worth asking out loud

The agent will happily answer these. Skip them at your peril.

• Why not the simpler thing? — Forces the agent to defend the existing complexity. Half the time it can’t, and you’ve found dead weight.
• What breaks if this assumption is wrong? — Builds operational intuition you cannot get from reading code.
• Was this eventually replaced? — If yes, the replacement is the verdict on the original trade-off.
• Who pushed for this and what were they optimising for? — Decisions are people. Names + motivations explain shape that code can’t.
• What got abandoned in this chapter? — Casualties often explain the surviving design better than the surviving design does.

Recent excavations

Sample books — output of running /dig against well-known repos. Skim a chapter to feel what a finished excavation looks like before pointing it at your own.

Volume I · 8 chapters

vLLM

From Woosuk Kwon’s solo PagedAttention prototype (codename CacheFlow) to the dominant open-source LLM inference engine. Block managers, V1 rewrite, distributed serving, vLLM IR.

≈ 16k commits · 3 years · feb 2023 → apr 2026

Volume II · 15 chapters

NautilusTrader

Cython FX prototype → open-source quant platform → Rust beachhead → PyO3 migration → engine port. Identity crises, MessageBus, high-precision value types, blockchain adapters.

multi-year · python ↔ rust crossover

Suggest a repo →

Begin the dig

Claude Code (one-liner via marketplace):

/plugin marketplace add twitu/indiana-codes
/plugin install dig@indiana-codes

For OpenCode, Cursor, and other agents see the install page. Then type /dig in any repo with git history.

MIT licensed · Property of: anyone with git and an itch