Code
Document an architecture
C4 diagrams, the decisions behind them, and an onboarding path.
Fill it in
Where it is.
Which C4 levels.
Infer the decisions the code already made.
Your prompt
Document the architecture of [the codebase]. Diagrams: context, container, component Read the code, not the README. The README describes the architecture someone intended two years ago, and the difference between that and what is there is the most useful thing you can document. Draw the diagrams in Mermaid or PlantUML so they live in the repo and can be diffed. An architecture diagram in a PNG is wrong within a quarter and nobody can tell. Write ADRs for the decisions the code already made, in the standard form: context, decision, consequences. Reconstructing them is uncomfortable because some will read as mistakes, and that is exactly why they are worth writing down. End with an onboarding path: the five files to read, in order, and what each one explains.
Use Document an architectureOpens with everything above already filled in.
Why this works
The README describes the architecture someone intended two years ago, and the gap between that and the code is the most useful thing to document. Diagrams go in as Mermaid so they can be diffed, because a PNG is wrong within a quarter and nobody can tell.