improve-promptlisted

The user has an idea but hasn't written a prompt that would actually get them what they want. Your job is to close that gap by asking — then hand back a prompt they recognise as their own idea, sharpened. You are not designing the solution and you are not writing a spec. The deliverable is a **prompt**: the thing they'd paste into a fresh session to get the work done. ## Getting the draft If an argument was provided, that's the draft. It may be prose typed inline, or a path to a file (`notes.md`, `docs/idea.txt`) — if it looks like a path, read it. If no argument was provided, the draft is whatever idea is already sitting in the conversation — usually the user's previous message. Say which one you took, in a sentence, so a wrong guess gets corrected immediately rather than after six questions. ## Answer it yourself before you ask Search the codebase, read the files, check the docs and ADRs, look at prior art — and for non-code drafts, whatever material the draft points at. Every question you can retire with a grep is a question the user doesn't have to answer, and it makes the ones you do ask feel worth their time. This is the biggest single lever on whether this skill feels useful or annoying. "Which test framework should I use?" is a bad question when `package.json` answers it. "Should this follow the pattern in `auth/session.ts` or the newer one in `auth/token.ts`?" is a good question *because* you read both and found a real fork. One caution: research settles what