Why does my coding agent keep asking questions?

Usually the task leaves the output open: no file path, no format, no definition of done. Each open choice is a reason to ask before acting.

What does locking a path mean?

Naming the exact file the agent must write, such as `docs/plan.md`, before it starts. The agent's job becomes producing that file, not deciding where work goes.

Does this work in Cursor and Claude Code?

The technique is client-neutral: it's just a clearer prompt or instruction file. Both tools treat instructions as context for the model, so state the path and done condition plainly rather than relying on enforcement.

Should the agent ever ask before writing?

Yes, when a wrong guess is costly or irreversible, such as deleting data, spending money or changing something shared. For a draft file in a set path, writing first and flagging open questions is cheaper.

How do I define done for an agent task?

One line the agent can check itself: the file exists at the locked path, has the named sections, and lists any assumptions it made instead of asking.

What if the agent still has an open question?

Have it write its best version to the locked path and list the question at the top of the file. You answer once, and it edits the same file.

Stop an agent asking questions instead of shipping: lock the output path first

When a coding agent keeps asking clarifying questions instead of producing work, the task usually leaves the output open: no file path, no format, and no definition of done. The fix is to lock the output before the agent starts. Name the exact file it must write, the sections that file needs, and the one-line check that means "done." Tell it to write its best version to that path and list any open questions at the top of the file instead of stopping to ask. The agent's job becomes producing one known artifact, and you review a file instead of answering a chain of messages.

Who this is for

You hand an agent a task in Cursor, Claude Code, or another client, and you get back "Before I start, a few questions…" more often than you get a file.

Why the loop happens

Every open decision in a task is a reason to pause. "Write a plan for the auth migration" leaves at least four open: where the plan goes, what it's called, what it contains, and how long it should be. A careful agent asks about each. That's reasonable behavior for an unclear task; the fix is a clearer task, not a scolding.

Open in the task	What the agent asks	Lock it with
Where the output goes	"Where should I put this?"	An exact path: `docs/auth-migration-plan.md`
What shape it takes	"What format do you want?"	Named sections: Goal, Steps, Risks, Open questions
When it's finished	"Is this enough detail?"	A done line the agent can check itself
What to do with unknowns	"Should I assume X?"	"List assumptions at the top; don't stop to ask"

The locked-path prompt

A task written this way leaves little to ask about:

text

Write docs/auth-migration-plan.md.
Sections: Goal, Steps, Risks, Open questions.
Done when: the file exists at that path, has all four sections,
and every assumption you made is listed under Open questions.
Do not ask before writing. Write your best version first.

The path is the anchor. Once the agent knows exactly which file it owns, the other decisions become details inside that file rather than blockers in front of it.

You can put the same pattern in a project instruction file (such as `AGENTS.md`) so it applies by default: "For any writing task, confirm the output path in your first line, write the file, then list open questions inside it." Keep in mind that instruction files are context for the model, not enforcement, so state the path and done condition plainly in each task as well.

When asking first is right

Locking a path is for work that is cheap to redo: drafts, plans, notes, a new file in a known folder. It is not a reason to skip questions when a wrong guess is costly. Deleting data, spending money, publishing, sending messages, or changing something other people depend on should still stop for a human. Keep those as explicit approval gates and let everything else ship to a file first. For more on drawing that line, see the related post on approval boundaries below.

Pitfalls

Locking a folder, not a file. "Put it in `docs/`" still leaves the name open. Give the full path.
A done line the agent can't check. "Make it good" isn't checkable. "Has these four sections and lists assumptions" is.
Banning questions entirely. Unknowns don't disappear; they get buried. Give them a home inside the file.
Changing the path mid-task. If you redirect output partway through, restate the new path and done line, or the agent will reasonably ask again.
Locking paths for risky actions. A set path doesn't make a destructive step safe. Gate those separately.

How to check it

Take a task that drew questions last time and rewrite it with an exact path, named sections, and a done line.
Run it again. The first thing back should be a file at that path, not a question.
Open the file and check it against the done line yourself.
Read the Open questions section, answer them once, and ask the agent to update the same file.
If the agent still stops to ask, look at which row of the table above is still open in your prompt, and lock that.

Where ShipKits fits

From the live Day-1 Desk page: "1 skill: path-lock — anti-question-loop; lock a path and ship the file". Day-1 Desk is "A $12 pay-once first desk day: two seats (Day Desk + Reviewer Lite), one path-lock skill, a thin gate card, install.sh, and a ~90-minute sample run." Soft path: /free. Cheat Sheet for the skim checklist mindset.

Soft next step

Pick the next task you'd hand an agent, write the exact output path and a one-line done check before anything else, and have it list open questions inside the file. Soft ladder: /free, then the Day-1 Desk ($12). Related: Add a verify step to AGENTS.md, Grok Bot approval boundaries.