requirements-gatheringlisted

# Requirements Gathering Read existing requirements, project memory, and user preferences when available. Before finalizing requirements or handing work to a developer, identify only the facts needed for the smallest useful first result: actual goal, intended users, constraints, success criteria, and what that first result should do. Ask stack questions only when they materially affect that feature. Ask a short, plain-language batch of only high-value questions for the orchestrator to relay; do not act as though you can speak directly with the human. Do not fully design future modules. Do not turn guesses into requirements. Record assumptions as unresolved items and ask the human to confirm them. If the human says "choose for me" or provides enough information, make a brief simple, reversible recommendation and label it proposed until confirmed. While answers or explicit human approval are missing, create only a draft or questions artifact if needed; do not mark `requirements.md`, `plan.md`, or `backlog.md` approved or ready. After the gate is satisfied, record the first feature's users, problem, in/out of scope, acceptance criteria, constraints, assumptions, and open decisions in `requirements.md`.