01 / Good and bad pairs
Paired examples throughout
Destructuring, variable count, control flow and schema definitions each get a two-block comparison. The rule is stated in one line and then shown twice, marked good and bad.
opencode
Open source coding agent, built for the terminal.
Twelve code blocks in 161 lines; most style rules show the wrong version beside the right one.
Documents
├── └── packages ├── app │ ├── e2e │ │ └── performance │ │ └── │ └── ├── core │ └── src │ └── tool │ └── ├── desktop │ └── ├── effect-drizzle-sqlite │ └── ├── llm │ └── ├── opencode │ ├── src │ │ ├── server │ │ │ └── routes │ │ │ └── instance │ │ │ └── httpapi │ │ │ └── │ │ └── session │ │ └── llm │ │ └── │ └── ├── schema │ └── └── stats └──
The file, explained
What makes it useful
A style guide that argues against abstraction, followed by a set of runtime invariants for its session core. The highest ratio of code to prose in the directory.
Techniques in this file
Quoted passages are verbatim. Open one to see it in the source.
02 / Behavioral framing
A rule against extracting helpers
Logic stays in one function unless it is reused, hides a genuinely complex boundary, or has a name that improves the caller. The same instruction appears twice in the file, once in the general principles and once under complex logic.
Source excerpt starting at line 26.- Do not extract single-use helpers preemptively. Inline the logic at the call site unless the helper is reused, hides a genuinely complex boundary, or has a clear independent name that improves the caller.
03 / From this file
Dependency direction in one sentence
A single line fixes the allowed direction across six packages, including which layers client runtime code may never reach. It can be checked at an import without opening a config file.
Source excerpt starting at line 3.- Keep runtime dependencies directed from Schema to Core and Protocol, then from Core and Protocol to Server. Client runtime code may depend on Schema and Protocol but never Core or Server; `sdk-next` composes Client, Core, and Server.
04 / From this file
A four-line branch naming convention
At most three words, hyphenated, no slashes, no type prefixes, with three examples given.
05 / From this file
Runtime invariants written as prose
The session core section states properties the type system does not hold: durable admission stays separate from model execution, one provider stream call per turn, no bridging through the legacy loop. They are written as standing constraints rather than as style.
Source excerpt starting at line 157.- Preserve one explicit `llm.stream(request)` call per provider turn and reload projected history before durable continuation. Do not bridge through legacy `SessionPrompt.loop(...)` or delegate orchestration to an in-memory tool loop.
06 / From this file
Environment facts that prevent dead ends
The default branch is dev, a local main ref may not exist, and tests cannot run from the repository root because of a named guard. Three lines, each covering a state an agent would otherwise have to discover.
Put it to work
Borrow this for your repo
- Pair every style rule with a wrong example.
- If agents over-abstract in your codebase, state it directly. "Do not extract single-use helpers" is an instruction.
- State dependency direction in one sentence, even where a config file already enforces it.
- Write down the branch naming convention with three examples.
- Note the default branch if it is not main, and any command that fails from the repository root.
How the file is organized
- 01Repo and SDK generation notes
- 02Branch Names
- 03Commits and PR Titles
- 04Style Guide
- 05Destructuring, Imports, Variables, Control Flow
- 06Complex Logic
- 07Schema Definitions
- 08Testing
- 09Type Checking
- 10V2 Session Core
Context your instructions cannot carry
opencode's file tells an agent how the codebase works. It cannot tell it which bug three customers hit this week. Modem keeps that context current and attaches it to the work.
Try Modem