match-the-house-shapelisted

# Match the house shape (what merges, not what's documented) ## Purpose The reviewer who will read your PR has a shape in their head — and it was set by the hundreds of PRs they have *already* merged, not by the words in CONTRIBUTING.md. A change that arrives in that familiar shape (roughly the median churn, the usual file-count, the expected title prefix, tests where tests usually go) is cheaper to hold in the head and cheaper to sign off. A change that arrives three times the usual size, spread across ten files, with no JIRA key in the title, costs the reviewer extra work before they can even start — and that cost is what stalls it. The honest framing is **review cost, not correctness**: matching the house's usual shape makes your PR cheaper to review, which helps it land as help. It does not make a wrong change right, and being small is not a virtue in itself. This is about fitting the house so the reviewer's attention goes to the change, not to its packaging. ## When to use - After you have picked the work and before you shape the PR — to decide how big, how many files, what the title looks like, whether to include tests. - When a change feels large and you are unsure whether to split it. - On a repo new to you, to learn its real conventions from data instead of docs. ## When NOT to use For *when* to talk to maintainers before coding, that is discuss-in-issue-first; this skill governs the *shape* of what you submit, not the timing of the conversation. ## The pra