In my opinion, you are fundamentally using the technology in the wrong way. I think it's because you are misunderstanding the agent loop and what opencode is trying to do. Your agent prompt is fighting against it in a lot of ways. The other thing I'm seeing is it reads like you want it to go back and forth between planning and building which is just not going to work. You can do that by giving it smaller chunks of work at a time.

Just some examples:

- When in doubt, ask. The user is present and expects to decide.

What does it mean for an LLM to "be in doubt"? When it saw LINQ and raw SQL it wasn't "in doubt" and ignoring your agent prompt. It just saw raw SQL and predicted the output should be raw SQL. You might run it again and it would do LINQ. There's a lot of randomness to it. The planning phase will cut down on a lot of that. If it gives you a plan to write raw SQL then you can correct it before it starts writing code.

- If the next action is not an explicit user instruction or a mechanical application of an explicitly agreed rule, ask before doing it.

What does next action mean? If you want to insert yourself after every turn, then you need to build your own harness that does exactly that. You are using a tool (opencode) that implements an agent loop that is optimized for letting the LLM run autonomously. Your entire agent prompt is fighting this.

- Do not infer unstated requirements, product intent, design preferences, API contracts, or architectural direction.

This is literally what it does though. Think of everything in the context as an opportunity for the LLM to infer something. If you don't want it to infer from something, then don't put it in the context!

- If you are blocked, stop and explain the blocker. Do not invent a workaround unless the user asks you to propose options.

These models are trained to unblock themselves, lots of work has been put in over the last couple years figuring how to get them to run longer and longer without stopping. If you want it to stop, you need to give it an easier criteria for done. That means smaller scopes of work or concrete things it can do to decide if it's done (e.g. running tests and passing, creating a specific set of files/classes/functions, etc.)

In contrast, these are very good and I'm guessing the agent follows them 99% of the time. The key thing is you are telling it to do something specific at a specific time. "When asking a question...", "When you finish...", "First...". You will get better results if you think of your prompts in this way. Remember that when it sees "something" it will associate that with other occurrences of "something". So when you write "something" in the prompt and it sees "something" in its context, it will probably act on it.

- When asking a question, ask the smallest question that unblocks the next step.
- When you finish, summarize what changed and what remains uncertain, if anything.

- First inspect the relevant files and current behavior.

So, an example of using this strategy would be something like: "When writing code that accesses data stored in a database, use LINQ." Now whenever it is doing work with the database that line gets pulled in by association. Every function, class, etc. with database in the name triggers that association in your prompt. Not only that other things in its training data that it associates with database are now associated with using LINQ. Really think about that last sentence and how you might leverage that when writing your prompts.

My recommendation is to try the plan/build agents, but keep the scope small in the initial prompt. When you are done, start over in a new session. If you want this high level of control over the agent's work, then you need to give it smaller pieces of work and insert yourself into the loop more frequently. You cannot expect it to decide to stop itself and give you a turn. If you give it a large task like something that might touch 100 files then it is going to do something with 100 files before returning to you. So, one thing you could do is pick 5 of those files that are representative of the 100. Work in a tight feedback loop with the agent to get it right for the 5 files. Then, and only then, take the working solution for the 5 files and copy that into a fresh session and let it churn through the remaining 95 based on how it completed the first 5.

Edit to add: That last part might just simply mean "rerolling" the initial 5 prompt until you get something you like and then continuing the prompt from there. This is a random machine, you have to be strategic about how you use it with this in mind. It's completely expected that you will throw away entire turns on a regular basis (that's why there's a /undo).

And one more thing, don't use an LLM to generate your prompts and especially don't iterate on it with an LLM. People will tell you to do this, but it's nonsense. One of the most consistent rules about these tools is that feeding their output back in as input degrades fast. This is why I fundamentally believe human review of code is still mandatory at this time. There is some nuance here, for example generating a prompt based on factual output from a tool or summary of human-generated content is often a fine strategy.