Context Engineering in OpenCode: Rules, Tools, and Memory

Context engineering in OpenCode means selecting the project instructions, source files, tool results, and task history that make its next coding action well informed. Begin with a narrow task and a readable project rules file, then add evidence as the work requires it. Keep the information needed for a later handoff outside the current conversation.

A shared work record such as fenbs can hold approved decisions and progress for later sessions. OpenCode is not one of the clients with a guided fenbs setup, so treat any direct connection as something to verify separately rather than an assumed integration.

How do you prepare one OpenCode task?

1. Write the desired behavior and its boundary. For example, change the empty search result message without changing how search matches records.
2. Point to the relevant project rules and starting files. Include the component, its existing checks, and any shared wording conventions that affect the change.
3. State the evidence required for completion. Ask for a review of the changed behavior and the applicable check result, including anything the assistant could not verify.
4. Make tool access deliberate. Start with what the task needs and check the project configuration before allowing broader actions.
5. End with a handoff. Save the files changed, checks performed, remaining uncertainty, and the next action rather than just saying that the task is finished.

This small task gives you a useful baseline. If the assistant cannot explain the current behavior before editing it, adding more general guidance is unlikely to help. Ask it to locate the relevant code and identify the missing fact first.

What belongs in the project rules file?

The OpenCode rules documentation↗ (opens in a new tab) explains how AGENTS.md supplies custom instructions. Project instructions belong at the project root and apply in that directory and its subdirectories. OpenCode also supports global instructions for guidance that should apply across sessions.

Use project rules for durable, checkable facts: the package manager, where shared code lives, which commands verify changes, and actions that require approval. Keep them short enough to inspect. A temporary search bug and the latest investigation result belong with the task, where they can change without turning into a permanent repository rule.

Write instructions that help someone choose an action. “Keep it clean” offers little guidance. “Use the shared message component for empty states” names a concrete convention and a place to start. If a person changes that convention, update its authoritative record rather than leaving contradictory copies in different files.

The Claude Code context guide covers the analogous work in that client. Keep client-specific setup there; use the same distinction between lasting instructions and current task evidence here. Decisions and rules in fenbs can preserve the human choice behind a project convention for other supported connected assistants.

How much code and tool output should you include?

Select files by their role in the task. For the empty search message, start with the search screen, the message component it calls, and the closest existing check. Add the search implementation only if you need to establish whether the empty state is triggered correctly. This makes each additional read answer a question.

Prefer the relevant failure and surrounding evidence to an entire build log. Preserve the command that produced it and enough context to distinguish a code failure from an environment problem. If you shorten a log yourself, say what was omitted and retain the full result somewhere you can inspect.

Also ask what the assistant has not read. A file name mentioned in chat is not proof that its contents were examined. The assistant should be able to connect a proposed edit to the code it observed. That practical habit carries over to context engineering in Cursor, even though the interface differs.

How do outside tools change the context?

OpenCode supports local and remote MCP servers, which expose outside tools through a standard connection. Its MCP documentation↗ (opens in a new tab) warns that tools add to context, and describes options for enabling tools globally or for individual assistants. Adding every available server creates more material to manage.

Connect a tool because the task needs an answer it can provide. A project record may explain why the search wording was approved. A code tool may reveal where it is rendered. Keep those functions distinct, and check the returned evidence before acting on it.

OpenCode documents remote OAuth authentication, a browser-based authorization flow, but that general capability does not prove a specific fenbs connection works in your installation. If you explore one, verify sign-in, available tools, intended access, and a harmless read first. Use a client with a fenbs setup guide when you need an established starting path.

What should survive compaction and a new session?

Compaction condenses a growing session so work can continue within the model input limit. The OpenCode configuration guide↗ (opens in a new tab) documents automatic compaction, pruning of older tool outputs, and a reserved input buffer. Check the options for your installation instead of copying settings without understanding their effect.

A compacted session is useful working continuity, but you still need an inspectable progress record. Before stopping, save the observed behavior, the change made, and the actual check result. “Changed the message; the interaction check still needs a browser” is a better handoff than an optimistic completion summary.

Keep a decision separate from an observation. “The wording is approved” needs a person behind it. “The component currently renders this wording” is a code fact. The context engineering guide for AI agents explains why multi-step work needs both. Where we left off in fenbs gives the next supported connected assistant a place to recover that distinction.

How to do this with fenbs

1. Create a free account and add the project. Make one task for the behavior change, with the problem, plan, and completion checks.
2. Record the wording or behavior a person approved in Decisions and rules. Keep ongoing constraints distinct from a choice that applies only to this change.
3. Choose a guided client from Integrations to read and maintain the record, or verify a separate OpenCode connection before relying on it. You can also update fenbs yourself in the web app.
4. Save what changed and what remains in Where we left off. Ask the next connected assistant to read the project context and explain its starting action.

fenbs does not import OpenCode conversations, replace repository instructions, or verify your code. If you need only a single local session, a clear task note may be enough. It becomes more useful when the current decision and remaining work need to survive a change of assistant or teammate.

How can you tell whether your setup improved?

Start another session with the same task and saved record. Check whether it finds the right component, respects the boundary, and recognizes the unperformed browser check. If it has to repeat your entire investigation, identify the missing fact and add that fact to the handoff.

Do not respond to every mistake by lengthening the rules. Fix the source, scope, or missing result that caused it. The context engineering hub offers other techniques, and the separate learning roadmap provides a sequence of practice exercises.