Reverse Engineer

An unfamiliar repo lies to you in a specific way: the README describes what someone intended two years ago, the directory names describe the original design, and the code describes what actually runs. Documentation produced by skimming names and folder structure reproduces the intention and misses the reality — which is exactly the part the user needed, because the intention is already written down.

So the value here comes from actually reading the code and reporting what it does, including the parts that contradict the docs. Everything downstream — the diagrams, the bottleneck list, the upgrade plan — is only as good as that read.

Every claim in the output traces to a file and line you actually read. No inference from filenames.

Workflow

Run these in order. Each phase feeds the next, and skipping recon makes the read unfocused.

1. Recon — census the repo, detect the stack, pick a read order → references/recon.md
2. Read — the line-by-line pass, module by module, taking structured notes → references/code-reading.md
3. Diagram — architecture, flow, sequence, data model from the notes → references/diagrams.md
4. Audit — vulnerabilities, issues, bottlenecks, review findings → references/security.md, references/performance.md, references/code-review.md
5. Recommend — upgrade path and optimization plan, sequenced by payoff → references/upgrade-and-optimize.md
6. Write — assemble the document set → references/report-template.md