anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Proper instructions to execute hyper-processes and commands? #4249

New Issue
Open
opened 2026-02-16 17:43:10 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 17:43:10 -05:00
Owner
Copy Link
Copy Source

Originally created by @davidbernat on GitHub (Jan 5, 2026).

Originally assigned to: @jayair on GitHub.

Question

OpenCode is currently fantastic, and I want to see the group gain in success over the year. I noticed that I was not able to implement hyper-processes effectively, to deliver the kind of self-learning that most of us should expect.

There were two types of procedural failures that I kept seeing the LLMs make:

  1. Session wrap-up to capture system mistakes for iteratively better, measurable results.

I created /start-session and /stop-session commands. The start session introduces the scope of the next hour of LLM interactivity from a previously implementation plan, sources for any software engineering design documentation about frameworks that my LLC has created, and retrieves what we have begun calling MISTAKES.md and QUESTIONS.md files which we created at the end of the previous session. The mistakes file contains summaries of specific errors the code agents made which required my human intervention, and why, and the questions file contains questions the code agents asked me when provided an opportunity to ask all the things about my session and frameworks that I did not ever formerly specify. A typical mistake might be that a method is built to expect an unpacking of a dictionary rather than explicit variables; a typical question might be specifying whether a small servlet is expected to only ever work on localhost or LAN even though I forgot to mention that explicitly anywhere in the implementation plan. We also do things similar to OKRs. These are hugely powerful iterative processes when I think out one year into my OpenCode journey, and the code used to collect these needs improvement, and the language used by the code agent is gaudy and non-standardized, and such, but overall these are slam dunks. We would also like to expand this into metrics of various sorts, and so on. I also think of how powerful these data sets will be when I amend an MCP server RAG to grab entire multi-agent histories about this or that intermittent to each request to the code agent.

It is straightforward to do each of these file creation sequentially through manual conversation, but I do not seem to know how to execute sequential operations in a tightly controlled sequence of sub-actions. The workflow is:

a. execute /stop-session, therefore
i. initiation mistakes dialog prompt
ii. discuss what the agent generates as mistakes until satisfied....repeat.
iii. approve composite result generated by agent for mistakes
iv. save to mistakes file.

v. initiation questions dialog prompt
vi. discuss what the agent generates as questions until satisfied....repeat.
vii. approve composite result generated by agent for questions
viii. save to questions file.

ix. execute /export to file
x. final approval... exit session

Problem: Try as I might I cannot figure out how these sets of operations are supposed to be implemented in OpenCode. When they are written as operations in a command the agent has too much freedom to execute out of order, or merge discussion of one into discussion of the other; I also cannot figure out how to get an agent to execute a command (such as export, including with arguments for its dialog box). Comments?

  1. The agent can often stumble with checklists which are not represented as subtasks, and with subtasks.

This one is harder to explain because the graphical representation of the OpenCode is happening behind the scenes. For instance, here is an actual use case: suppose I ask for questions from the agent, and the agent responds with 14 different numbered-listed questions. I can respond to each of those 14 with answers. But what I want is the agent to create one subtask for each item, and then enforce specific workflow patterns on each item one by one. Is this a prompt engineering error on my part, or are these specific under the hood ways to communicate this to the OpenCode framework?

Problem: There is a lot of 'slipperiness' in these processes. One can imagine a diligent engineer would want 14 subtasks, then invoke the agent to make 14 files, then engage in a dialogue scoped to specifically that one subtask until approval, then mark the file as complete; this contains both a. scoped procedure and b. persistence, since I can close sessions and open up to notify the agent to jump back into our subtasks. But at present my way of working neither creates subtasks nor handles the creation of individual-by-individual processes. Comments?

Expectation: I presume these "managed processes" are beyond the realm of OpenCode, but as of yet I do not understand how the OpenCode community expect these forms to be implemented at the application level (me). These also seem like boilerplate cross-domain problems that the community would be reinventing over and over again, suitable for a semi-official cookbook. As I have said I am willing to further the OpenCode community by contributing my time or joining a working group to the subject matter.

Extremely impressive product. I play a little more helpless than engineers tend to like because I am standing in for the thousands of people who I talk to who would have declared their own use as a non-starter. It works wonders.

Originally created by @davidbernat on GitHub (Jan 5, 2026). Originally assigned to: @jayair on GitHub. ### Question OpenCode is currently fantastic, and I want to see the group gain in success over the year. I noticed that I was not able to implement hyper-processes effectively, to deliver the kind of self-learning that most of us should expect. There were two types of procedural failures that I kept seeing the LLMs make: 1. Session wrap-up to capture system mistakes for iteratively better, measurable results. I created ```/start-session``` and ```/stop-session``` commands. The start session introduces the scope of the next hour of LLM interactivity from a previously implementation plan, sources for any software engineering design documentation about frameworks that my LLC has created, and retrieves what we have begun calling MISTAKES.md and QUESTIONS.md files which we created at the end of the previous session. The mistakes file contains summaries of specific errors the code agents made which required my human intervention, and why, and the questions file contains questions the code agents asked me when provided an opportunity to ask all the things about my session and frameworks that I did not ever formerly specify. A typical mistake might be that a method is built to expect an unpacking of a dictionary rather than explicit variables; a typical question might be specifying whether a small servlet is expected to only ever work on localhost or LAN even though I forgot to mention that explicitly anywhere in the implementation plan. We also do things similar to OKRs. These are hugely powerful iterative processes when I think out one year into my OpenCode journey, and the code used to collect these needs improvement, and the language used by the code agent is gaudy and non-standardized, and such, but overall these are slam dunks. We would also like to expand this into metrics of various sorts, and so on. I also think of how powerful these data sets will be when I amend an MCP server RAG to grab entire multi-agent histories about this or that intermittent to each request to the code agent. It is straightforward to do each of these file creation sequentially through manual conversation, but I do not seem to know how to execute sequential operations in a tightly controlled sequence of sub-actions. The workflow is: a. execute /stop-session, therefore i. initiation mistakes dialog prompt ii. discuss what the agent generates as mistakes until satisfied....repeat. iii. approve composite result generated by agent for mistakes iv. save to mistakes file. v. initiation questions dialog prompt vi. discuss what the agent generates as questions until satisfied....repeat. vii. approve composite result generated by agent for questions viii. save to questions file. ix. execute /export to file x. final approval... exit session Problem: Try as I might I cannot figure out how these sets of operations are **supposed** to be implemented in OpenCode. When they are written as operations in a command the agent has too much freedom to execute out of order, or merge discussion of one into discussion of the other; I also cannot figure out how to get an agent to execute a command (such as export, including with arguments for its dialog box). Comments? 2. The agent can often stumble with checklists which are not represented as subtasks, and with subtasks. This one is harder to explain because the graphical representation of the OpenCode is happening behind the scenes. For instance, here is an actual use case: suppose I ask for questions from the agent, and the agent responds with 14 different numbered-listed questions. I can respond to each of those 14 with answers. But what I want is the agent to create one subtask for each item, and then enforce specific workflow patterns on each item one by one. Is this a prompt engineering error on my part, or are these specific under the hood ways to communicate this to the OpenCode framework? Problem: There is a lot of 'slipperiness' in these processes. One can imagine a diligent engineer would want 14 subtasks, then invoke the agent to make 14 files, then engage in a dialogue scoped to specifically that one subtask until approval, then mark the file as complete; this contains both a. scoped procedure and b. persistence, since I can close sessions and open up to notify the agent to jump back into our subtasks. But at present my way of working neither creates subtasks nor handles the creation of individual-by-individual processes. Comments? Expectation: I presume these "managed processes" are beyond the realm of OpenCode, but as of yet I do not understand how the OpenCode community expect these forms to be implemented at the application level (me). These also seem like boilerplate cross-domain problems that the community would be reinventing over and over again, suitable for a semi-official cookbook. As I have said I am willing to further the OpenCode community by contributing my time or joining a working group to the subject matter. Extremely impressive product. I play a little more helpless than engineers tend to like because I am standing in for the thousands of people who I talk to who would have declared their own use as a non-starter. It works wonders.
yindo added the docs label 2026-02-16 17:43:10 -05:00
yindo commented 2026-02-16 17:43:10 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 5, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #5333: Graceful handling of queued messages after session interrupt (related to sequential message processing and queue management)
  • #6792: Task Tool Timeouts & Early Termination in Multi-Agent Conductor Pattern (related to multi-step agent processes and workflow sequencing)
  • #6470: Settings for queue execution order: sequential and parallel (directly addresses sequential vs parallel task execution)
  • #5408: Delayed queue feature (related to queuing messages and controlling execution order)
  • #5895: On-idle background processing (related to managing queued tasks and unattended processing)

These issues address similar concerns about controlling execution order, managing workflows with multiple steps, and implementing sequential vs parallel execution patterns in OpenCode.

Feel free to ignore if your specific use case requires a different approach or has unique requirements.

@github-actions[bot] commented on GitHub (Jan 5, 2026): This issue might be a duplicate of existing issues. Please check: - #5333: Graceful handling of queued messages after session interrupt (related to sequential message processing and queue management) - #6792: Task Tool Timeouts & Early Termination in Multi-Agent Conductor Pattern (related to multi-step agent processes and workflow sequencing) - #6470: Settings for queue execution order: sequential and parallel (directly addresses sequential vs parallel task execution) - #5408: Delayed queue feature (related to queuing messages and controlling execution order) - #5895: On-idle background processing (related to managing queued tasks and unattended processing) These issues address similar concerns about controlling execution order, managing workflows with multiple steps, and implementing sequential vs parallel execution patterns in OpenCode. Feel free to ignore if your specific use case requires a different approach or has unique requirements.
yindo commented 2026-02-16 17:43:10 -05:00
Author
Owner
Copy Link
Copy Source

@davidbernat commented on GitHub (Jan 9, 2026):

I want to provide an even simpler model problem for the power users and developers of OpenCode to tutorial out, please:

Here is a simple design request: I want my agent to execute every call to a specific MCP to be done by a subagent, and I want that subagent to cache the request and results in a local file. This is a kind of "guarantee" that real AI systems need for real requirements of design and law, including accountability, traceability, reconstitution, sanity checks, and more. Other users want an even better feature, which is to log these tool results in a subagent, return to the agent, and then have the agent specifically query into the results file so that minimal context is used back within the agent scope.

The LLM/OpenCode flow would be required to do this:
prompt ==> IF use specified MCP ==> initiate subtask by subagent ==> get MCP result ==> create files + display result in subagent context ==> return to agent ==> agent queries into results file ==> includes in agent context

What I am stating here is that the OpenCode framework itself needs to support these workflow orchestration guarantees, and not let this decision making up to the LLM, and that this code structure exists within OpenCode already, and must. In some cases, I noticed that agents will not even publish MCP results to the display, meaning that MCPs are called and I have no idea the inputs or outputs. This seems mistaken to me, and not simply for testing MCPs, but for provenance. The above use case is far more critical in most industrialized applications.

Currently, even stipulating in an agent .md file that an agent execute a type of result through a subagent remains mostly stochastic, and requires extremely precise LLM results to get even close. It is far more conceivable that the agent .md file should support small snippets of in-line MCP-like code: "if it appears the prompt aligns with this statement, run the software code immediately below". It would still be stochastic, but now the execution of what happens is deterministic and guaranteed, and the requirements on LLM quality of triggering the code is far more exact.

As I said, my recent experiments with agent and subagent files does not come anywhere close to satisfying this requirement, and may be lack of skill (but I do doubt that). I cannot imagine that OpenCode has gone this far without providing this guarantee system (for extremely high value applications like law and finance and regulators?!) so somewhere there is a gap which is either my skill deficiency (i.e., this needs to become a tutorial set that I write) or an OpenCode structure problem (i.e., massive improvement for OpenCode wins). Let's discuss.

Thanks. If anyone needs pseudo-code or specific LLM traces we can get those started, but I think the text is clear here.

cc: @jayair

@davidbernat commented on GitHub (Jan 9, 2026): I want to provide an even simpler model problem for the power users and developers of OpenCode to tutorial out, please: Here is a simple design request: I want my agent to execute every call to a specific MCP to be done by a subagent, and I want that subagent to cache the request and results in a local file. This is a kind of "guarantee" that real AI systems need for real requirements of design and law, including accountability, traceability, reconstitution, sanity checks, and more. Other users want an even better feature, which is to log these tool results in a subagent, return to the agent, and then have the agent specifically query into the results file so that minimal context is used back within the agent scope. The LLM/OpenCode flow would be required to do this: prompt ==> IF use specified MCP ==> initiate subtask by subagent ==> get MCP result ==> create files + display result in subagent context ==> return to agent ==> agent queries into results file ==> includes in agent context What I am stating here is that the OpenCode framework itself needs to support these workflow orchestration guarantees, and not let this decision making up to the LLM, and that this code structure exists within OpenCode already, and must. In some cases, I noticed that agents will not even publish MCP results to the display, meaning that MCPs are called and I have no idea the inputs or outputs. This seems mistaken to me, and not simply for testing MCPs, but for provenance. The above use case is far more critical in most industrialized applications. Currently, even stipulating in an agent .md file that an agent execute a type of result through a subagent remains mostly stochastic, and requires extremely precise LLM results to get even close. It is far more conceivable that the agent .md file should support small snippets of in-line MCP-like code: "if it appears the prompt aligns with this statement, run the software code immediately below". It would still be stochastic, but now the execution of _what_ happens is deterministic and guaranteed, and the requirements on LLM quality of triggering the code is far more exact. As I said, my recent experiments with agent and subagent files does not come anywhere close to satisfying this requirement, and may be lack of skill (but I do doubt that). I cannot imagine that OpenCode has gone this far without providing this guarantee system (for extremely high value applications like law and finance and regulators?!) so somewhere there is a gap which is either my skill deficiency (i.e., this needs to become a tutorial set that I write) or an OpenCode structure problem (i.e., massive improvement for OpenCode wins). Let's discuss. Thanks. If anyone needs pseudo-code or specific LLM traces we can get those started, but I think the text is clear here. cc: @jayair
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label docs
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4249
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?