requirements-elicitationlisted

# Symphony Requirements Elicitation Use this as Symphony's canonical first lane: messy source evidence in, clear approved work packet out. Implementation happens later, usually through `implementation-dispatch`. ## Contract - Ground the requirement in the real source before interpreting it. - Talk through what the requirement means and where the boundaries are. - Create or update Linear only after Pedro approves the requirement or asks to capture it. - Do not write product code, open a PR, merge, deploy, or mark work review-ready from this skill. - Do not dispatch an implementation thread until Pedro says to implement, pick it up, send it to an agent, or otherwise approves implementation. ## Source Order 1. Resolve and read the source of truth: WhatsApp, Gmail, meeting transcript, Drive doc, screenshots/media, Linear, repo docs, or code. 2. Use metadata-only discovery first for private chats; read the narrow message window needed to understand the ask. 3. Download/open cited screenshots, PDFs, photos, or annotated images when they affect scope. 4. Check Linear for existing coverage before proposing a new issue. Include inactive states such as Done, Duplicate, Obsolete, Canceled, and Needs Info when available. 5. Inspect repo docs/code only enough to avoid wrong or duplicate scope. ## Elicitation Extract only action-shaped items: - `Requirement`: a missing capability, field, report, workflow, print detail, or user-visible behavior. - `Bug`: promi