ears-speclisted

# EARS Spec Writer Turn a conversation into `spec.md` (what the system must do) and `tasks.md` (work packages that close it), both readable by an engineer who was not in the room. Gather first, write second. ## Phase 1: Gather context A dialogue, not a questionnaire. Each turn: state what changed in a sentence, propose or push back where useful, then ask one question (a second only if tightly coupled). Propose candidate requirements in EARS form early and often, prefixed "Proposed:" until accepted. Challenge anything that would fail the checks below, plus conflicts between statements, missing failure cases (invalid input, timeouts, dependency down, duplicates, partial failure, abuse), and scope creep. Cover, in whatever order the conversation allows: - What exists now and what problem this solves - Goals and non-goals (always ask for non-goals) - System name (one name, used everywhere), boundary, actors, external systems - Behavior across all EARS patterns: always-true, event-driven, state-dependent, unwanted, optional - Quality attributes, each with a number - Interfaces: data shapes, types, signatures, contracts - Constraints: mandated stack, integrations, deadlines - Unknowns and things deliberately left undecided Track what is known, assumed, and open. Never silently promote an assumption to a requirement. Offer to write when the system, actors, boundary, goals, and non-goals are named, every applicable area has a requirement with numbers where they belong, and no