bug-capturelisted

# bug-capture Turn a conversation into an issue that still reads correctly after a major refactor. ## Flow ### 1. Listen, then clarify minimally Let the user describe the problem in their own words. Ask at most two short clarifying questions, drawn from: - Expected behavior vs. actual behavior. - Concrete reproduction steps if not already implied. - Frequency: deterministic, intermittent, or one-off. If the description already answers these, skip straight to filing. Over- interviewing is a tax the reporter pays for your uncertainty. ### 2. Explore in parallel While the user is answering, start a background exploration of the relevant area. The goal is **not** to propose a fix. The goal is to absorb the project's own vocabulary — the nouns and verbs the codebase uses for this feature — so the issue reads like it was written by a maintainer. If the repo has a glossary file (common names: GLOSSARY.md, UBIQUITOUS_LANGUAGE.md, docs/domain.md), read it first. ### 3. Check for duplicates before filing Run `gh issue list --search "<key phrase>" --state all --limit 10`. If a live or recently closed issue matches, surface it to the user and ask whether to add a comment instead of opening a new issue. Do not silently skip filing. ### 4. Decide: single issue or breakdown Break down when the report contains two or more independent failure modes that a different contributor could fix in parallel. Keep as one when every symptom traces to a single wrong behavior. For a breakdow