Picking up a codebase you did not write.
Run /graphify first. Read nothing by hand until it answers.
Four steps before you are allowed to have an opinion about the code.
- 01/graphify standalonea persistent graph
Builds a queryable graph of the repo once, so the next forty questions cost a query instead of a grep. Reading files in the order you happen to open them teaches you the file system, not the system.
- 02/domain-audit standalonea scored audit
Splits the repo into functional sections and scores each one, which turns "this is a mess" into a ranked list you can actually act on.
- 03/health gstack
Separates the parts that are badly written from the parts that are merely unfamiliar. Those two feel identical on day one and need opposite responses.
- 04/improve-codebase-architecture Matt Pocock engineering suite
Only now. Proposing seams before the audit is guessing with confidence.
- 05/triage Matt Pocock engineering suite
The audit produces more work than anyone will do. Triage decides what gets touched, and admits what does not.
What you do not run
/investigate — Nothing is broken yet. Reaching for a debugger to learn a codebase is how you end up understanding one function very well and the system not at all.
/to-tickets — Too early. Tickets written before the audit encode your first impression, which is the impression most likely to be wrong.
The order matters more here than in most chains. Every step exists to stop you forming an opinion one step too early.