need-understandinglisted

# need-understanding — ambiguity hunt Follow the shared contract in `../README.md`. Prerequisite: `01-extraction.md` (else offer `us-review`). Load relevant knowledge via `knowledge/index.md` — project rules may already answer some questions. The open questions this skill raises are the ones a human later has to arbitrate, often blind. When production data for the same feature exists, `signal-ingest` attaches observed evidence to those questions — it never answers them, but it stops the arbitration from being a guess. Raise the question here regardless: a question that waits for evidence is still a question, and one never written down is never informed. ## Steps 0. **Nothing-to-understand check.** If `01-extraction.md` has no capability/behavior to test (a design doc, an RFC process, an empty template, a title with no ACs), do not fabricate requirements: say what the source actually is, and either ask the user for the missing acceptance criteria or stop. A reformulation of nothing is a defect. 1. **Reformulate.** State the need in 3-5 sentences: who, what, why, main risk if it misbehaves. This is the understanding the whole test design will rest on. 2. **Hunt ambiguities.** Systematically inspect each AC and rule for: - undefined terms and units ("soon", "recent", inclusive/exclusive thresholds) - **every duration or deadline: "measured against which clock/referential?"** (user timezone vs server vs counterpart — attach the question to the AC doing the *computation*