build-the-alternative-before-you-chooselisted

When a design decision is defended in prose — "the alternative is a bigger design", "arguably correct", "that's out of scope", "that's the maintainer's call" — build the alternative (or measure the deferred claim) before recording the choice. A rejected-by-argument option costs a paragraph and settles nothing; a rejected-by-measurement option costs an hour and ends the debate, including the future re-litigation in review. Words that trigger this: arguably, probably, bigger design, out of scope, their call, we assume. Use when you are about to record a design choice whose alternative was rejected in prose rather than measured, or to defer a claim to someone else's judgement. Trigger terms: design trade-off, alternative considered, out of scope, arguably, defer to maintainer, prototype, spike, measured choice.
serhiy-bzhezytskyy/contrib-receipts · ★ 1 · Web & Frontend · score 75

Install: claude install-skill serhiy-bzhezytskyy/contrib-receipts

# Build the alternative before you choose ## Purpose In someone else's repo, a design choice defended by reasoning invites the reviewer to re-do the reasoning; a choice defended by a measurement of the *built* alternative gives them nothing to re-litigate. The same applies inward: "out of scope", "upstream's call" and "arguably correct" are the three phrases that most often mark an assumption wearing a decision's clothes. Each is a claim, and claims about buildable things get verified by building. The pattern that makes this cheap: most alternatives are a small patch away once the main design exists — the expensive part (harness, tests, invariants) is already built and serves both. ## When to use - You are about to write "arguably", "probably fine", "the alternative would be a bigger design", or "that is their decision" in a design note, PR body, or handoff. - A semantics trade has two coherent sides (streaming vs batching, eager vs lazy, fail vs warn) and you picked one by taste. - A reviewer *could* ask "why not the other way?" — pre-empt with the other way's measured numbers, not adjectives. ## When NOT to use Decisions that are literally someone else's authority (whether a public API ships at all, licensing, release timing) — there, build the *evidence package*, not the decision. And don't build alternatives to requirements nobody traced to a real need: first check the demand, or you measure two answers to a question no one asked. ## The practice (checklist)