issue-writerlisted

An issue is a work order for someone with none of this conversation's context. Write it so that a developer who picks it up cold can reproduce the problem, knows when they are done, and starts in the right file - and do the investigating now, while the context exists, rather than leaving it to them. A two-minute look at the code turns "the export is broken" into an issue with a suspected cause and a pointer. ## Step 1: Extract and classify From the user's description (and the current conversation - the bug being discussed right now is usually the subject), pin down: - **Type:** bug, feature request, or task/chore. This decides the template below. - **The one-sentence problem.** If you cannot state it in one sentence, you do not understand it yet; ask the one or two questions that resolve it. Do not interrogate - two questions maximum, then write with what you have and mark the gaps. - **Severity signals** for bugs: data loss, wrong results, crash, cosmetic? Who hits it and how often? ## Step 2: Investigate before writing Spend a short, bounded pass in the repo making the issue concrete: - **Bugs:** find the code path involved (`grep` the error message, the feature name, the route). Note the suspected file/function. If reproduction is cheap - a failing command, a curl, a unit test - actually run it and record the real output. Check `git log` on the suspect file for a recent change that correlates. - **Features:** find where the change would land, what patterns exist to f