namht-user-storylisted

# namht-user-story — investigate deeply → features + granular user stories Take ONE requirement (typed, or a Slack discussion the user links) and produce **features + INVEST user stories with acceptance criteria decomposed to the smallest testable unit**. Depth is the point: investigate the codebase for real before writing, and make **every case its own AC** so a tester or dev never has to guess. **Dual audience:** lead each part with a plain-language line a non-technical PM understands, then the precise detail the dev/QA team needs. **Depth (default = EXHAUSTIVE).** By default, do the full deep investigation and granular ACs below. If the user explicitly says "quick" / "lite" / "rough", do a lighter single-pass version and say so. (Deep mode reads more of the repo and spawns analysis agents → more tokens; worth it for a real backlog, and the user asked for maximum detail.) ## Input — accept EITHER (or both) 1. **Typed requirement** — a paragraph, bullet list, or rough idea. 2. **A Slack source the user provides** — a thread URL, a channel link/name, or a message permalink. The user supplies the link; you fetch the content (never guess it). If BOTH are given, merge them. If NEITHER is usable, ask for a requirement or a Slack link — do NOT invent a story. ## Procedure ### 1. Understand the source (a Slack thread is messy — don't just read it, COMPREHEND it) Typed text → use it directly. A **Slack thread** needs real comprehension, because a chat is non-linear, multi-