use-the-tool-for-its-purposelisted

# Use the tool for its purpose (to find where the bugs actually are) ## Purpose An LLM asked to "find bugs in this repo" will read code and produce plausible smells: a maintainer's least favorite kind of contribution, because every one has to be disproved by hand. The alternative costs more wall-clock and almost nothing in reviewer trust: **run the project for the reason it exists**, on real input, at the scale a real user would. Defects that survive months of green CI are concentrated in the one workflow nobody walks end to end — and a bug found *by being blocked by it* arrives with a reproduction, a stack trace, and an obvious severity, none of which you had to argue for. ## When to use - You want to contribute to a repo you don't own and don't yet know, and you're deciding *what*. - The project is a tool, CLI, or pipeline with an end-to-end workflow you can run. - You have a real task that happens to need this tool — best case. Be a user first; the bug list writes itself. ## When NOT to use - The pain already came to you from a live thread or a CI failure — start from that instead: follow-the-thread (traverse it) or consolidate-a-scattered-thread (map it). - The project isn't runnable in reasonable time/resources (huge cluster, paid service, 100GB corpus you don't have). Say so and pick a different sourcing route rather than faking a run. - Library-only code with no workflow to walk — there is no "purpose" to exercise. ## The practice (checklist) - [ ] **