Introduction
My usual workflow with Claude Code is simple. I talk to the agent about what I want, and then I expect it to implement it. When I describe a bug, I want it fixed. When I describe a feature, I want it built. Most of my messages end in code changes.
But sometimes I just want to ask something, and then nothing should get implemented.
A while ago, I was in the middle of a feature when I looked at a piece of the code and wondered whether a different approach would be cleaner. So I asked: “Wouldn’t it make more sense to do it this way?”
I expected an answer. Maybe a yes, maybe a no, ideally a few reasons either way. What I got was “You’re right, that is cleaner”, followed by the agent rewriting the code. Before I had even decided whether I liked the idea, it was already implemented.
It was not the only time, and over the following weeks it kept happening. In this post, I want to share why I think it happens and the very small skill I wrote to stop it.
A Question Is Not a Request
When I ask a colleague “wouldn’t it make more sense to do it this way?”, I am not telling them to change the code. I am thinking out loud. I want them to push back, point out something I missed, or confirm that my idea holds up. The decision comes after the discussion, not before it.
That is the conversation I wanted to have with the agent. Instead, the question skipped the discussion and went straight to the implementation. This causes a few problems:
- The decision was made without me. I had not agreed to the change. I had only asked about it.
- The agent agreed too quickly. An answer that starts with “you’re right” and ends in a diff is not an evaluation of my idea. Sometimes my idea was worse, and I only found out after reading the new code.
- I have to clean up. If I decide to keep the original approach, I now have to ask the agent to revert its changes, and check that it actually did.
- It costs focus. Instead of thinking about the trade-off, I am suddenly reviewing a diff I did not ask for.
Why the Agent Acts
I do not think the model misunderstands me. It is an agent with tools to edit files and run commands, and it is built to be helpful. Read in that context, “wouldn’t it make more sense to do it this way?” is easy to interpret as a polite instruction. And the most helpful thing an agent can do with an instruction is to carry it out.
To be fair, that matches my usual workflow. Most of my messages end in code changes, so that eagerness is exactly what I want most of the time. The messages where I only want to ask something look a lot like the others. From the wording alone, the agent cannot reliably tell whether I want to talk or to act.
Claude Code has a plan mode for read-only work. But plan mode is built for planning an implementation and ends with a plan to approve. For a quick question in the middle of a session, I do not want a plan. I want an answer.
The Skill
So I made the difference explicit. I wrote a skill called answer. Here is the complete file:
---
name: answer
description: Answer the request with an explanation, diagnosis, or recommendation only.
disable-model-invocation: true
---
Answer the user's request; do not implement it. If the answer is a change, describe it instead of making it.
That is all. Two sentences of instructions.
The first sentence is the obvious rule. The second one covers the case that kept happening: when the answer to my question is “yes, change the code”, the agent should describe the change instead of making it. That way I still get the useful part, a concrete proposal, but I decide whether it happens.
The disable-model-invocation: true line matters as well. It means the agent can never load this skill on its own. Only I can start it. The skill is a signal from me about how I want this specific message to be handled, so it would make no sense for the agent to decide when it applies.
How I Use It
I put /answer in front of the question:
/answer wouldn't it make more sense to move the validation into the service?
The agent now looks at the code, weighs the two approaches, and tells me what it thinks. If it agrees, it explains why and describes what the change would look like. If it disagrees, it tells me that too. Either way, no file is touched.
I use it for more than design questions:
- Diagnosis. “Why does this test fail?” When I want to understand the cause before I decide how to fix it.
- Review. “Is there anything wrong with this approach?” When I want an opinion, not a refactoring.
- Recommendations. “Which of these two libraries would you pick?” When I want the reasoning, not a new entry in
package.json.
The skill only applies to the message I use it with. If the answer convinces me, my next message is simply “do it”, and the agent implements the change it just described. The discussion and the decision happen first, the implementation second.
Conclusion
The fix for an agent that acts too eagerly was not a long prompt or a complicated rule. It was a way for me to say, in one word, that this message is a question and not a request.
It also reminded me of something I wrote about in The System Around the Agent: write the rule at the point of failure. I kept getting implementations when I wanted answers, so now there is a skill that names exactly that.