Your AI Agent Doesn't Need a Better Prompt. It Needs to Ask.

I asked a coding agent to "add an admin endpoint to list links". Sixteen seconds later it was done. The code compiled, the tests passed, and the summary was confident.

It was also wrong in five ways I cared about. It used a bearer token instead of the header our tooling sends. It returned every link at once, with no pagination. It left out the creation date the admin screen needed. It gave no total count to page through. And it had no test for the endpoint itself. Against the checks I had written down before starting, it passed 2 out of 9.

None of that was the agent's fault. My request held one sentence of information and about ten decisions. The agent made every one of those decisions for me, quickly and plausibly. A plausible guess is the most expensive kind of wrong: it compiles, it demos, and it fails review a week later.

So I built Agentic Prompt, an open-source skill that makes the agent ask before it builds. Then I measured whether it helps.

The problem isn't the prompt

When an agent builds the wrong thing, the usual fix is a better prompt: longer instructions, a template, "think step by step". None of that helps here, because the missing information isn't in the prompt or in anyone's head yet. Nobody had decided on page sizes when I typed that sentence. The decision has to be asked for.

Spec-driven development gets closer. Tools like GitHub's Spec Kit and Kiro turn a requirement into a spec, the spec into tasks and the tasks into code, and agents build far better from a spec than from a chat message. But they assume someone has already written a good spec. In practice that someone is the person who typed one vague sentence, now asked to write ten requirements from a blank page.

Agentic Prompt fills that gap. It is the step before the spec: a short, guided requirement interview that turns one sentence into an approved spec the agent can build from and be checked against.

How it works

You type /prompt and your rough request. The skill walks it through a fixed path, and nothing gets built until you approve the result.

It reads the code before it asks you anything. For technical work it classifies the request (feature, bug, integration, refactor, architecture or data, plus five non-code types), then reads the entry points, existing patterns, data model and tests. In my test it opened with what it had found, including a trap that's easy to miss: the server's catch-all route would have swallowed /admin/links as if it were a short code. "I found X — confirm?" respects your time far more than "which files are involved?".

It asks only what's missing, and makes answering cheap. Related questions come together, each with lettered options and a recommendation, so a reply like 1b 2a answers a whole topic. Depth is a setting, not a target: a quick interview stops at three questions, a standard one at eight. The recommendation is always the smallest option that fits what you asked for. "You decide" is a valid answer, and it is recorded as an assumption rather than silently absorbed. A question only someone else can answer becomes an open question with an owner, and doesn't block anything.

It writes one spec, in the same shape every time: context, task, numbered requirements, constraints, acceptance criteria tied to those requirements, out of scope, assumptions and open questions. Every requirement must be covered by at least one acceptance criterion, and every unknown is written as an explicit TBD. No secret ever goes in; placeholders like <API_KEY> are the only values allowed.

Approval is the gate. You approve a short plain-language summary of the spec, and the full spec is there if you want it. Nothing is built before you say yes, and if the scope changes halfway through, the agent stops and asks again.

Validation is the receipt. After building, it reports one line per acceptance criterion — met, not met, or not testable here — each with its evidence. Nothing is quietly marked done.

One request, start to finish

Here is the same admin endpoint again, this time through /prompt. This is the actual run from my test, lightly trimmed.

1. The request. /prompt add an admin endpoint to list links.
2. What it found. A standard-library HTTP server with no authentication anywhere. An in-memory store with no way to list links. Tests for the store but none for the server. And the catch-all route that would treat /admin/links as a short code unless the new route is matched first.
3. One message, four questions. How is "admin" enforced? Which route? What response shape — and should it page? Should it add server tests? Each came with options and a recommendation.
4. One reply. A custom header checked against an environment variable; /admin/links; a total count, creation dates, newest first, 20 per page by default and never more than 100; yes to tests.
5. The summary to approve. Six plain-language requirements and six acceptance criteria. It also listed assumptions I could overrule: the endpoint stays closed if the token isn't configured, the comparison is constant-time, and a page size of zero is allowed.
6. "Approved." It built the endpoint, added HTTP-level tests and reported every criterion as met, each with the test that proves it.

Against the same nine hidden checks the plain agent scored 2 on, this build passed all nine on its first try. It cost $0.16 and 44 seconds of agent time — about what the plain agent spent getting it wrong and then fixing it.

I measured it

Claims about prompting tools are cheap, so I tested this one. I took a small Python URL shortener and three requests:

• A vague feature: "add an admin endpoint to list links".
• A vague bug: "short codes are hard to read — people mistype them. fix it".
• A control: a fully specified request with nothing left to guess.

Before any agent ran, I wrote down what I actually wanted for each one and turned it into hidden tests the agents never saw. Each request then went to a fresh Claude Code agent twice, once as a plain request and once through /prompt. When either agent asked a question, I answered honestly from my notes. When the plain agent got it wrong, I corrected it the way a real user would, and counted that too.

| | Plain request | With /prompt | | --- | --- | --- | | Hidden checks passed on the first build | 13 of 20 | 20 of 20 | | Vague feature, first build | 2 of 9 | 9 of 9 | | Rounds of correction needed | 1 | 0 | | Tests the agent wrote | 15 | 23 | | Agent cost, all three tasks | $0.35 | $0.41 | | Agent time, all three tasks | 81 s | 98 s |

The headline is the first build. Without the interview, the agent got the vague feature mostly wrong, and the only reason it was fixed is that I already knew exactly what was missing. In real life, a missing pagination parameter ships, and someone finds it in production. With the interview, every request was right the first time, and the acceptance criteria turned into about half as many tests again.

The cost is real but small: about 17% more agent spend and 21% more agent time overall. On the vague feature, where the interview mattered most, the costs came out level.

An honest caveat: this is one run per task on one small codebase. The direction is clear; treat the exact ratios as indicative.

The early version also had habits the test exposed, and I fixed them in v1.1. It asked one question per message, recommended the bigger option even when a smaller one fitted the request, and showed raw XML to approve. Fixing those cut the agent cost by 29% and the time by 36%, with no loss of accuracy.

Who it's for

Anyone who hands vague work to an AI agent and pays for the guesses.

| Who | What they get | | --- | --- | | Developers and tech leads | Questions grounded in the code, and acceptance criteria that become tests | | Agencies and freelancers | An approved spec is a written scope with the client: fewer "that's not what I asked for" conversations on billed hours | | Product managers | Lettered options that are quick to answer, and a summary that reads like a short PRD | | Founders and non-engineers | An interview that asks the right questions, so you don't have to know them in advance | | Teams on several AI tools | One spec format across Claude Code, Cursor, Codex, Gemini CLI, Windsurf and plain chat |

It isn't only for code. Documents, research, plans and content get their own question set: what the deliverable is, who reads it, what's in and out, and which sources to use.

Your tools at the edges

Every team has its own code-search tool, test command and review habits, so the skill names none of them. Each step asks for a capability — code analysis, implementation, verification — and a short YAML file maps it to your own skills, slash commands, MCP tools or scripts. Rules hook onto six events. For example, a security-review skill can run after the spec is drafted whenever a request mentions login or payments, or a team can require every feature spec to name its feature flag.

The front door to Agentic Playbook

Agentic Prompt has three modes. Execute builds the approved spec. Save writes it to docs/specs/ for later. Hand off returns it to another skill and never builds anything. That last mode is how Agentic Playbook uses it: the interview fills a feature's requirements file, and the playbook carries those requirements, and every decision made after them, for the feature's whole life. Prompt gets the first build right; Playbook keeps it right.

The cheapest place to be wrong

Every wrong guess an agent makes gets more expensive the longer it lives. Caught in an interview, it costs one question. Caught at review, it costs a rebuild. Caught in production, it costs a sprint and some trust. The interview is the cheapest place in the whole delivery cycle to find out what you actually meant.

Agents are fast enough now that typing speed isn't the bottleneck; knowing what to build is. Agentic Prompt doesn't make the agent smarter. It makes it ask, write the answers down, wait for a yes, and prove the result. That turned out to be enough to take my first-build accuracy from 13 of 20 to 20 of 20.

Agentic Prompt is MIT-licensed and works in Claude Code, Cursor and any agent that reads a skill file. In Claude Code:

/plugin marketplace add Gowrishankar4/agentic-prompt
/plugin install prompt@agentic-prompt

Then try it on the next request you'd normally just fire off: /prompt <your request>. The code is at github.com/Gowrishankar4/agentic-prompt.