wishlisted

# Wish A wish granted literally is a bug. Clarify first, then grant: a plan a stranger can build from. Rules only. The output is a file, not a chat essay. **Plan only — never write or edit product code here.** **Input** = the text after `/wish` (Claude Code appends it as `ARGUMENTS:`). Empty → ask what to plan, offering 3–5 candidates read from the repo (README roadmap, TODO/FIXME, recent commits). ## Flow 1. **Read** — README, manifests (`package.json`, `pyproject.toml`, `go.mod`…), tree to depth 2, the modules the wish touches, existing `docs/`. External APIs / libraries the plan leans on: check current docs if a web tool exists. Skim, don't audit. Never ask what the code answers. 2. **Gap check** — mark every row of §Sufficiency `known` / `inferred` / `unknown`. 3. **Ask** — only `unknown` rows that change architecture, scope, or the finished look (§Asking). Everything else becomes an assumption in the doc. Nothing to ask → write straight away. 4. **Write** — load [references/template.md](references/template.md); save per §File. 5. **Gate** — run §Gate; fix the doc until it passes. 6. **Report** — path + ≤5-line summary + open questions. Offer the next step; don't start it. **Follow-ups** (“补充…”, “also…”, answers to open questions) → edit the same file, bump `Revision`, add a Changelog line. User approves → `Status: Confirmed`. New file only for a different task. ## Sufficiency | # | Dimension | Unknown → ask when | |---|---|---| | 1 | Goal — the problem,