Repo Autopsy

PROBLEM When a developer joins a project, the first hours are rarely spent coding. They go to finding out which parts of the documentation are still true, and which "easy first task" won't quietly break something else. READMEs describe env vars the code no longer reads and setup steps for files that were deleted. Issue trackers mix harmless dependency bumps with changes that touch authentication. As the project lead of a university team project, I've watched teammates lose afternoons to both problems. Existing tools catch part of this: documentation-drift checkers flag stale docs, and dependency scanners flag vulnerable packages. None of them answer the question a newcomer actually has: what should I work on first, and why is it safe? SOLUTION Repo Autopsy turns a repository URL into an onboarding report in seconds, in three stages: 1. Drift detection cross-checks the README against the actual codebase: unused env vars, setup steps that reference missing files, and documented routes with no implementation. It respects .gitignore and "create this file" instructions to avoid false alarms. 2. Blast-radius ranking builds an import graph of the codebase and ranks every open issue and TODO by how much of the system it touches. It handles public API entry points, dev-only dependencies, and security labels, so a newcomer sees "bump this dev tool" at the top and "fix the unauthenticated registration endpoint" flagged as risky. 3. The Onboarding Trust Score combines both into a transparent 0-100 score with a plain-English breakdown of every deduction. TARGET USERS Developers joining a codebase, maintainers onboarding contributors, and small teams and student projects without a formal onboarding process. HOW THEY USE IT Paste a repo URL, read the report, then share it with one link or export it as Markdown into an issue or onboarding doc. WHY IT'S DIFFERENT It connects diagnosis to a decision. Instead of listing problems, it recommends a starting point and explains the risk behind it. The scoring is fully documented on a public methodology page, including known limitations, because a trust score has to be trustworthy itself. IMPACT A new contributor avoids hours of dead-end setup and gets steered away from a risky first change. It's especially useful for teams where no senior developer is available to hand-pick starter tasks.