sweep-the-siblingslisted

# Sweep the siblings A review finding on one file is a hypothesis about every file like it. Reviewers read a diff, so they can only report the instance in front of them; the same omission usually sits in the siblings nobody changed this week, where it will be found one at a time, by one reader each, for as long as nobody looks. The failure this prevents is the slow leak: a rule the project states, honoured in the files that happen to get touched, quietly false everywhere else. The one that makes a sweep worth doing carefully is its opposite: a grep proposes candidates confidently and is wrong about a third of them, so a sweep that trusts its own output ships a diff that "fixes" files that were already correct. ## Procedure 1. **Quote the invariant in the repo's own words before looking for breaches.** It lives in a contributing guide, a `CLAUDE.md`, a pull-request template, or a validator's error strings: ```bash grep -rniE "must|always|every .* (has|carries|states)" CONTRIBUTING* CLAUDE.md AGENTS.md .github/ docs/ 2>/dev/null | head ``` If the rule is your inference rather than the project's, stop and propose it as a rule first. A sweep is enforcement, and enforcing a preference nobody agreed to is how a repo acquires a convention by ambush. 2. **Define the family by what the invariant governs**, not by directory convenience: every skill page, every workflow, every package README. Fewer than three members is not a family; fix the one file