requirements-clarificationlisted

# Requirements Clarification Gather requirements before writing code. A few minutes of structured discovery prevents hours of rework. Use this skill when a request is ambiguous, underspecified, or likely to have non-obvious edge cases. **When NOT to clarify:** The request is a single, well-scoped bug fix with one clear resolution. Don't block on questions you can resolve by reading the existing code. --- ## Verify the premise before accepting the requirement Not every requirement arrives as a conversation. Many arrive pre-formed — a filed issue, an audit finding, a review comment, a recommendation document — asserting that something is broken or missing. That is a **claim**, and claims can be stale, partly wrong, or right for the wrong reason. Check it against the current code before designing anything. **A requirement that arrives with a proposed solution is two claims:** 1. The problem exists. 2. The proposed change addresses it. Verify them separately — they fail independently, and the second fails more often. A real problem paired with a wrong remedy is the most expensive case, because the problem being real lends the remedy false credibility. | What you find | Right response | |---|---| | Claim true, proposal fits | Implement it | | Claim true, proposal wrong or backwards | Solve it another way; say why | | Claim partly true | Narrow scope to the true part | | Claim false or already fixed | Don't implement; record the evidence | **Record the null result.** "I c