codebase-quality-opinion

Gather structural metrics like file counts, lines of code per language, largest files, and test-to-code ratio, then check smell signals such as TODO density and unwrap counts. Lead with a direct verdict backed by numbers, and always name at least one specific weakness.

Raw counts mislead without segmentation. Split unwrap, panic, and TODO counts by test versus production paths first, since a large total concentrated in test modules is usually fine. Only cite a number as a weakness after knowing where it lives.

Useful signals include file-size concentration, test-to-code ratio, TODO density, dependency hygiene in manifests, scoped conventional commit history, and substantive documentation. No single metric suffices; weigh them together against the project's stated purpose.

Use a lightweight opinion when the user asks for a judgment like "is this a good codebase". Escalate to a fan-out multi-reviewer audit when they ask to review everything for bugs, and to a readiness review when they ask whether the project can go public.

READMEs pitch the project rather than describe reality. Verify that the claimed safety model, test coverage, and dependency choices actually exist in the code, then judge the implementation against the pitch instead of repeating it.