opencode Agent Rules

Open source coding agent, built for the terminal.

Overview

OpenCode argues against premature abstraction, then states rules its session core must always preserve. Five examples put bad and good code side by side; a sixth shows the intended helper-based flow.

Good and bad pairs Hard prohibitions Generated file guards Architecture as narrative Behavioral framing

Documents

├── 
└── packages
    ├── app
    │   ├── e2e
    │   │   └── performance
    │   │       └── 
    │   └── 
    ├── core
    │   └── src
    │       └── tool
    │           └── 
    ├── desktop
    │   └── 
    ├── effect-drizzle-sqlite
    │   └── 
    ├── llm
    │   └── 
    ├── opencode
    │   ├── src
    │   │   ├── server
    │   │   │   └── routes
    │   │   │       └── instance
    │   │   │           └── httpapi
    │   │   │               └── 
    │   │   └── session
    │   │       └── llm
    │   │           └── 
    │   └── 
    ├── schema
    │   └── 
    └── stats
        └──

Techniques in this file

01 / Good and bad pairs

Paired examples throughout

Destructuring, variable count, control flow and schema definitions each get good and bad examples within one fenced block. The rule is stated in one line and then shown twice, marked good and bad.

02 / Behavioral framing

A rule against extracting helpers

Keep logic inline unless it is reused, hides a real boundary, or has a name that improves the caller. The file repeats this rule in both general and complex-logic sections.

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.

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.

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.

A four-line branch naming convention

At most three words, hyphenated, no slashes, no type prefixes, with three examples given.

Runtime invariants written as prose

The session core records invariants the type system cannot hold: separate durable admission from model execution, allow one provider stream per turn, and never bridge through the legacy loop.

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.

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.

Ideas 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.