issuinglisted

# File issues that read as specs An issue states what must become true, so a later plan can be written against it. The enemy is the story issue: the occasion that prompted it, a quote from the prompt, and a background paragraph repeating the labels, type and parent that GitHub already shows beside the body. The overcorrection is the one-line issue that never says when it is done, which pushes the whole spec into the plan. An issue is a spec before a plan; a plan reads it and never depends on it staying open. A plain request to file, open, write or split issues authorizes creating them, with their labels, type, project fields, relations and milestone, and creating the default labels `references/fields.md` names when the repository defines none of its own. It never closes an issue, never deletes one, and never edits an existing one, except to add a relation to a parent or a blocker the user named. ## Steps 1. **Intake.** Turn the request into one goal sentence per issue, and say which sentence came from which part of the request. An issue whose goal sentence needs an "and" for two unrelated outcomes is too big: propose a parent plus sub-issues and ask once, listing the split you would make. That is the only question this skill asks, because the request approved the rest. Never invent an issue the request does not ask for. 2. **Read the repository, invent nothing.** Read its labels, issue types, milestones, project fields and issue templates, and pick the