issue-treeslisted

# Issue Trees ## Concept An issue tree breaks a vague problem into progressively smaller, more concrete sub-problems until you reach something testable. Each branch is a hypothesis about why the parent problem exists. Done well, the leaves are things you can actually go investigate. ## Required output format A fenced code block with `text` syntax. Use ASCII box-drawing characters: - `├──` non-final child - `│ ` vertical continuation under a non-final child - `└──` final child at each level ````markdown ```text Core Problem ├── Category 1 │ ├── Sub-factor A │ └── Sub-factor B └── Category 2 └── Sub-factor C ``` ```` ## Rendering fallback Some destinations mangle box-drawing characters — Slack, certain email clients, and some chat UIs render them as boxes or question marks. If you know the output is heading to one of those, use an indented-dash tree instead: ```text - Core Problem - Category 1 - Sub-factor A - Sub-factor B - Category 2 - Sub-factor C ``` It loses some elegance but stays readable everywhere. Default to box-drawing; switch only when needed. **This is "Slack mode."** When the user asks for Slack / Teams / email / plain-text output (or names that as the destination), use this indented-dash form for the whole tree by default. ## Defaults & flex points | Default | When to flex | |---|---| | At least 2 levels deep | A 1-level tree is a list. Push deeper. For complex problems, 3–4 levels. | | 3–8 words per node | Stay short — long