How to Structure Your OpenCode Workflow for Maximum Productivity
Problem
When I first started using OpenCode, I thought it was simple: type what you want, get code. I’d open a session and write something like “build me a task tracker app.” The agent would generate something that looked right at first glance. But when I dug deeper, the code was riddled with issues—missing edge cases, inconsistent architecture, and features that didn’t match what I actually needed.
The tool wasn’t the problem. My workflow was.
After spending time on the r/opencodeCLI subreddit, I found that experienced users follow a structured approach that’s completely different from how beginners use the tool. The gap between “it works” and “it works well” comes down to four principles: write specs first, separate planning from building, keep system prompts minimal, and close sessions frequently.
The Power User Workflow
Here’s the workflow loop that power users actually follow:
┌──────────────┐│ 1. WRITE ││ SPEC │└──────┬───────┘ ▼┌──────────────┐│ 2. GATHER ││ CONTEXT │└──────┬───────┘ ▼┌──────────────┐ Big models (Opus/GPT-5)│ 3. PLAN │◄─── for strongest reasoning│ MODE │└──────┬───────┘ ▼┌──────────────┐ Mid models (Sonnet/GPT-5-mini)│ 4. BUILD │◄─── for implementation│ MODE │└──────┬───────┘ ▼┌──────────────┐│ 5. REVIEW ││ & ITERATE │└──────┬───────┘ ▼┌──────────────┐│ 6. COMMIT ││ & RESET │└──────┬───────┘ │ └──────► back to step 1Each step has a specific purpose. Let me walk through them.
Step 1: Write the Specification First
This is the step most beginners skip. One Reddit user put it bluntly:
“I mean DETAILED, every single functionality, edge case, failure mode, EVERYTHING.”
Before you even open OpenCode, write a specification document. Cover every feature you need, edge cases and failure modes, constraints like language and framework, and acceptance criteria.
Another user recommended: “create a specification document first before developing an application. This can be done with an LLM too. Then tell opencode to read the document.”
I tried this approach on a recent project. I spent 15 minutes writing a spec that described exactly what I wanted, then fed it to OpenCode. The difference was immediate—the agent didn’t wander or make assumptions. It built exactly what I described because it had a clear target.
Step 2: Gather Context
Before jumping into implementation, pull in relevant documentation and context. Use /Exa-search or web-search MCP tools to find official library documentation, best practices, and similar implementations.
Feed this context to OpenCode. One user’s battle-tested prompt loop starts with: “Best way to accomplish this goal?” followed by “/Exa-search for details.” This research phase prevents the agent from working with outdated or incorrect information.
Step 3: Plan Mode
Once you have a spec and context, switch to Plan mode. Ask OpenCode to create a detailed implementation plan with phases and specific tasks. Review it, push back on anything that doesn’t look right, and iterate until the plan is solid.
This is where big models like Claude Opus or GPT-5 shine. Planning requires strong reasoning, and using a cheaper model here often produces shallow plans that miss important details.
Step 4: Build Mode
Only now do you switch to Build mode. With an approved plan in hand, the agent knows exactly what to implement and in what order.
For simple, well-defined tasks, you can switch to a faster and cheaper model. For complex implementation, stay with a mid-tier model like Sonnet or GPT-5-mini. This is also where OpenCode’s model switching feature becomes useful—use a fast model for straightforward file edits, a stronger one for complex logic.
The key is matching the model to the task. I keep a fast model for file exploration and simple edits, and switch to a stronger model when the task requires reasoning.
Step 5: Review and Iterate
Power users don’t blindly trust the agent’s output. They run the code, observe results, and iterate.
One user emphasized: “Feedback is often more important than careful planning and constant rethinking. Encourage the agent to actually run the code and observe results.”
The pty plugin or tmux integration is critical here. It lets the agent see actual output—error messages, logs, test results—and fix bugs based on real feedback rather than assumptions. I’ve found that telling the agent “run this and fix any errors” produces much better results than asking it to review its own code in isolation.
Step 6: Commit and Reset
This is the step that saves money. One user shared:
“One of the biggest unlocks for me to reduce costs, is to close a session after a feature or two, and not let it run for long.”
Long sessions balloon token usage. OpenCode needs to reprocess the entire conversation history on each turn, which means every previous exchange adds to the cost. Closing the session and starting fresh keeps context clean and costs predictable.
I now commit working code after 1-2 features, close the session, and start a new one. The quality of output in fresh sessions is noticeably better.
Beyond the Workflow: What Power Users Also Do
Keep AGENTS.md Under 50 Lines
One user who prioritizes control shared this approach:
“Minimise the system prompt. Remove absolutely everything that is unnecessary from AGENTS.md. It really should be max 50 lines.”
Instead of cramming everything into the system prompt, they use separate files: CONTEXT.md for project-specific context and ADRs (Architecture Decision Records) for architectural decisions. This keeps the system prompt focused and prevents the agent from being confused by too many instructions.
Agent Role Specialization
One power user emulates an entire engineering team with role-specific agents: a Project Manager orchestrator, a planning agent, a code executor, an API researcher, a test verifier, a security auditor, and a code reviewer.
Each agent produces specific file outputs—ADRs, security audits, code reviews—that feed into the next stage. This team-of-agents pattern produces higher quality output because each agent has a focused responsibility rather than trying to do everything at once.
Common Mistakes to Avoid
Skipping the spec. Jumping straight to “build this” without a spec is the most common mistake. The agent makes assumptions, and those assumptions compound across the project.
Cramming AGENTS.md. Putting everything in the system prompt makes the agent slow and unfocused. Use separate context files instead.
Never closing sessions. Long sessions cause token bloat and degraded output. Close after 1-2 features.
Using strong models for everything. Don’t burn expensive models on tasks like file exploration or simple edits. Match the model to the task complexity.
Not letting the agent run code. If the agent never sees actual output, it can’t learn from mistakes. Use tmux or pty to give the agent a real feedback loop.
Summary
In this post, I walked through the OpenCode workflow that power users actually use: write a detailed spec, gather context, plan with a strong model, build with the right model for each task, review with real feedback, and commit then reset. The key point is that structured discipline—not just a better prompt—is what separates productive OpenCode sessions from frustrating ones.
Final Words + More Resources
My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me
Here are also the most important links from this article along with some further resources that will help you in this scope:
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
Comments