← ClaudeAtlas

price-the-door-before-you-enterlisted

A repo has thousands of open issues, a friendly CONTRIBUTING and an obvious defect you could fix, and none of that tells you whether a contribution can land. Open issues measure demand; the merge path measures supply. Before reading a single issue, price the door with four queries — open PRs and how many are stale, merged vs closed-unmerged over the same window, created-to-merged latency, and the author spread of recent merges — then read the licence and the CLA acceptance mechanism, because in some houses opening the PR *is* the signature. Two houses with the same open-issue count can differ by a factor of fifty in whether an outsider's PR merges. Use before forking, before writing code, and before promising anyone a contribution in a repo you have not landed in. Trigger terms: can we contribute to, scout this repo, first PR into, new house, is the door open, worth entering, good first issue, they have lots of open issues.
serhiy-bzhezytskyy/contrib-receipts · ★ 1 · Code & Development · score 75
Install: claude install-skill serhiy-bzhezytskyy/contrib-receipts
# Price the door before you enter ## Purpose The cost of entering a house is paid before any code is written, and it is refunded only if a PR can actually merge. Every surface a repo shows you — issue count, labels, a warm CONTRIBUTING, a defect you can reproduce in an afternoon — describes **demand**. None of it describes **supply**: whether anyone reviews outside PRs, how long they take, what fraction they reject, and what rights you sign away by opening one. Those four things are four API queries and two files, and they routinely reverse the decision. A repo can want a fix, document the workflow perfectly, and still merge nothing from outside for eighteen months. The queries also produce the numbers you will need later: the latency tells you when silence stops being normal, the rejection ratio tells you how much a first PR is worth risking, and the author spread tells you whether outsiders land at all or only the staff who cut releases. ## When to use - Someone asks "can we contribute to X" about a repo with no landed PR of ours. - You have found a defect in an unfamiliar repo and are about to start on the fix. - A repo looks inviting: many open issues, `good first issue` labels, an active feed. - A repo looks dead and you are about to write it off — the latency probe distinguishes *dead* from *slow* from *bimodal*, and only the first is a reason not to enter. - Before promising a human that a contribution is coming. ## When NOT to use - A house already entered an