Challenge a decision before committing to it

--- name: challenge-a-decision-before-committing-to-it description: "Use when you are about to commit a non-trivial technical or business decision, claim something is safe or correct, or change something hard to undo. Runs a short, bounded adversarial review of the decision before it stands." --- Apply this before a non-trivial decision stands, not after it ships. A decision is non-trivial when it adds branching logic, crosses a system or team boundary, relies on a property nobody can easily check (safety under concurrency, ordering, idempotence, legal compliance), or is hard to reverse (data migrations, public interfaces, published commitments). Do not apply it to renames, formatting, clear instructions from the user, or one-line changes with obvious correctness. Steps 1. State the claim in two lines: what you are asserting and why it matters if it is wrong. If you cannot state it that compactly, you do not have a decision yet. 2. Separate the artifact (the change, plan or proposal itself) and the requirements it must meet from your own reasoning about it. Review only the artifact against the requirements. 3. Argue against it as a skeptical reviewer who assumes the author is overconfident. Look for unstated assumptions, unhandled edge cases, hidden shared state or coupling, ways the requirements could be violated, conventions it breaks, and behavior under unexpected input. Find issues, or state explicitly that none were found after a real search. 4. Classify each finding in this order: the requirement was unclear (fix the requirement first), a real issue (change the artifact), an accepted trade-off (write it down), or not applicable given context the review lacked. 5. Stop after a round that finds only trivial issues, after three rounds, or when the user says to proceed. If serious issues remain after three rounds, tell the user the decision is not ready rather than looping. Output shape Show the claim, the findings with their classification, what you changed, and any accepted trade-offs. Keep it brief. Avoid - Asking 'is this good?' instead of 'what is wrong with this?'. - Treating every finding as authoritative without re-reading the artifact. - Reviews where nothing is ever actionable; that is validation, not doubt. - Doubting trivial work until nothing ships.

Claim: Moving invoice numbering to the new service is safe to run alongside the old one during migration. If wrong, two invoices could share a number, which breaks audit requirements. Findings 1. Both services read 'last number + 1' with no lock; concurrent requests can collide. - Real issue. Changed: numbers now come from a single sequence owned by the new service; the old service calls it. 2. Requirement does not say whether gaps in numbering are allowed. - Requirement unclear. Asked finance: gaps are allowed if logged. 3. Rollback path re-enables the old counter, which will be behind. - Real issue. Changed: rollback step sets the old counter to the current maximum first. 4. Review flagged missing currency handling. - Not applicable: numbering is currency-independent. Round 2 found only naming nits. Stopping; decision stands with the two changes above.