issuelisted

# Issue An issue is a prompt with context. Its reader is a different agent, in a fresh session, with no access to this conversation. The issue proves that the problem exists and where; it does not prescribe the solution. The reader plans. ## Input `$ARGUMENTS` - `--dry-run`: do everything but the publish step; print the title, the labels and the body instead. - Starts with a number: rewrite that issue. Fetch it with `gh issue view <n> --json title,body,labels,url`, keep the facts that still hold, drop the rest. - Anything else: the request for a new issue. - Empty: ask one question, "What is wrong, or what do you want?", then continue. Ask nothing else unless the request cannot be located in the code at all. ## Protocol 1. **Project constraints.** Read the repo's `AGENTS.md` or `CLAUDE.md` for two things only: the validation commands, and the boundaries the reader must respect. They go in *Done when* and *Hints*. 2. **Evidence.** Locate the code the request touches. Read it before citing it. Each fact gets an anchor the reader can jump to: `path:line` plus the symbol name, or a commit hash. Run `git log --oneline -10 -- <file>` when history explains the current state. Search once for a duplicate: `gh issue list --search "<keywords>" --state all --limit 10`; link a match in *Evidence* and say so to the user. 3. **Body.** Fill the template below. Size follows the problem: a small bug fits in fifteen lines. 4. **Publish.** No question before it: the skill is the guard, an