Course · OpenCode · Daily workflow
Daily workflow
OpenCode rewards fluency. Once a repository has providers wired, standing rules (AGENTS.md) and skills (packaged procedures) in place, a permission policy set, extensions attached, and unattended runs in CI, the tool itself often stops being the bottleneck - and the loop is exactly as fast as the habits of the person driving it. This chapter is about those habits. It adds no new capability. It makes the ones you already have cheap enough to use without thinking, so the interactive side of the loop - the part you drive from the keyboard - moves as fast as the unattended side.
The course’s illustrative scenario is feedmill, a small self-hosted feed aggregator - a Go CLI plus an HTTP sync server pulling dozens of RSS, Atom, and JSON feeds into one reading queue - and the chapter’s worked examples run on it, but every habit here maps onto any repository you own. To start here you need OpenCode installed with one working provider, in a repository you can edit (install OpenCode). The habits get more out of other primitives, but none of them is a prerequisite, and each keeps its full treatment linked: assigning a model per task or per agent instead of per session (per-agent models), getting a second opinion on a stuck session now that sharing links are retired (sharing, discontinued), driving the same engine with no terminal attached (headless runs), and reading the same kind of language-server diagnostics your editor shows (the LSP channel). When those stop being features you reach for and start being reflexes, the daily loop gets fast.
What this chapter installs
Section titled “What this chapter installs”Each habit answers a friction you have probably already felt:
- Codify your repeated chores - the sweep for feeds that stopped publishing, the “scan the parsers for the suspected date-parsing bug” sweep, the release-notes draft you rewrite for every release. Turn each into a custom slash command - a markdown file with frontmatter that can pin its own agent and model (as of October 2026; commands documentation) - so it’s
/staleness-sweep 7(7 is the number of days without a new item) instead of a paragraph you keep rewriting - Codify the chore you keep typing - Prompting and keyboard reflexes - the small moves that get a clean first pass: describe the outcome not the steps, plan before you build, and let your hands find
@(reference a file) and!(run a shell command), the Tab agent switch, and the model picker without looking - Prompt well and move at the speed of the keyboard - Take stock of the difference - a synthesis of OpenCode’s distinctive moves: what each one earns on a real repo, what carries past a single repo, and where to point the tool next - The OpenCode difference, and where to point it next
Why these are habits, not tips
Section titled “Why these are habits, not tips”You could treat these as three loose tips and skip them - OpenCode works without them. Don’t, because none of them mean anything in the abstract. A custom command is busywork until you’ve typed the same staleness-sweep instructions for the fourth time and felt the friction; that’s the moment to codify it, not before, because only then do you know which chores actually repeat. A prompting reflex isn’t a tip you memorize - it’s the shape your requests drift toward once you’ve corrected the agent enough times, made deliberate. And the stock-taking is most useful after you have used several of these features on real tasks: you can’t honestly judge whether bring-your-own-model (any provider or local model you configure) earned its keep until you’ve used each on real work.
So the order here is a reading order, not a schedule. The commands you write are yours, shaped by your own chores. The reflexes are yours, worn in by your own corrections. And the synthesis is the one that decides what OpenCode is for on your repos after the course ends.