Proper instructions to execute hyper-processes and commands? #6980
Description
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:
- 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?
- 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.