CLAUDE.md in OpenCode: Share Rules and Check What Loads

You can use CLAUDE.md in OpenCode as a fallback when the project has no AGENTS.md. To share instructions reliably, check which file OpenCode selects, adapt references to other files, and test the result before asking it to change code.

The useful goal is one agreed set of project rules. A tool such as fenbs can keep the changing decisions and work state outside those files, while your repository explains how to work with the code. Moving the instructions alone does not move the previous conversation.

How do you start using your existing instructions?

1. Open the project folder you actually intend to work in. Note the starting directory, because a different folder can change which local instructions apply.
2. Read the existing CLAUDE.md and look for AGENTS.md alongside it or above it. Identify which document contains the maintained rules, rather than assuming both should be combined.
3. Choose one source for the shared instructions. Keep tool-specific commands separate and remove old references that nobody can explain.
4. Check any files the instructions mention. If an important rule lives in another document, arrange for OpenCode to load that document explicitly.
5. Start a fresh OpenCode session and give it a small read-only task. Compare its proposed approach with the written rules before allowing edits.

Do this review before renaming or copying anything. A second complete instruction file may appear convenient, but someone will eventually update just one copy. For the underlying file format, see what CLAUDE.md is; this guide focuses on the transfer into OpenCode.

Which file will OpenCode actually read?

The OpenCode rules documentation↗ (opens in a new tab) describes local CLAUDE.md as a fallback behind AGENTS.md. It also gives the OpenCode global file priority over the Claude global file. Claude compatibility can be disabled, so check that setting when a fallback seems absent.

Treat this as a review of your setup, not a reason to delete every older file. A teammate may still need a Claude-specific entry point. Give each remaining file a clear purpose and name the shared source in your team documentation.

What happens to imports and extra rule files?

Do not assume an @path reference behaves identically in both tools. OpenCode says references inside AGENTS.md are not automatically parsed. Its configuration guide↗ (opens in a new tab) supports an instructions list of file paths and patterns, which makes the intended inputs explicit.

{
  "$schema": "https://opencode.ai/config.json",
  "instructions": [
    "docs/project-rules.md",
    "docs/testing-guide.md"
  ]
}

Merge that entry into your existing configuration rather than replacing the whole file. Choose the documents individually before using a broad pattern. Pulling in an archive of old plans can create contradictions that look like current instructions.

Anthropic documents its own import behavior in the Claude Code memory guide↗ (opens in a new tab). Use that to understand the source setup, then verify the destination separately. A copied filename is evidence that a file exists, not that every reference inside it was read.

What should the shared rules say?

Keep rules that remain useful whichever assistant reads them: where the main code lives, which package manager the project uses, the checks required for a change, and the areas that need a person to approve work. Replace tool-specific assumptions with concrete actions.

# Project rules
- Read docs/testing-guide.md before changing checkout behavior.
- Use the existing package manager and lockfile.
- Keep generated files out of ordinary source edits.
- Ask a person before changing production settings.
- Report the checks actually run and any remaining uncertainty.

For example, replace a command that only exists inside one assistant with the actual outcome you need. “Explain the proposed files and checks before editing” is portable guidance. A private command name without its definition gives the next tool little to work with.

Use CLAUDE.md examples for ideas about instruction content, then keep only what describes your project. Put a changing next step in the task record instead of turning yesterday’s unfinished work into a permanent rule. fenbs Skills and prompts can hold the reusable wording alongside that separate work record.

How can you verify the transfer without changing code?

Use a specific question whose answer depends on the rules. Ask the new session to describe how it would make one small change, list the required checks, and identify any action needing approval. Choose a task you understand well enough to evaluate yourself.

Do not edit files or run commands. Explain how you would change the
checkout confirmation message. Name the relevant instruction files,
required checks, and any approval boundary. Quote no secrets.

A correct summary is useful evidence, but it is not proof of future compliance. Follow it with a small supervised task and inspect the proposed changes. The assistant should use the right locations, respect scope, and distinguish checks it ran from checks it merely recommends.

If the answer misses a rule, inspect loading before strengthening the wording. Check the directory, competing files, configuration, and referenced documents one at a time. Our CLAUDE.md troubleshooting guide covers problems in the Claude setup; investigate the OpenCode setup on its own terms.

How to do this with fenbs

Use fenbs for the approved reusable instructions and the state of the work. For OpenCode, carry reviewed text across manually in this workflow. Use the supported Claude Code connection for that side of the work.

1. Create a free account, then add the project whose instructions you are moving.
2. Save the reviewed reusable guidance in Skills and prompts. Record a person’s lasting project choices in Decisions and rules.
3. Add a task for the transfer, including the files to review and the read-only check you will use.
4. Use the Claude Code guide in Integrations if you want Claude Code to read the project context directly. Copy the relevant reviewed context into OpenCode yourself.
5. After testing, update the task with what passed and save Where we left off, including any remaining difference between the tools.

If you only need one static instruction file in one repository, the file may be enough. fenbs is useful when the instructions sit beside changing tasks, decisions, and handoffs across supported AI apps.

What should you review after the first successful session?

Write down the working launch directory, the chosen instruction source, and the check you used. Repeat the check when you change the file layout or instruction settings. Ask a teammate to try the setup from their own checkout before treating it as a shared solution.

Instruction portability is one part of the broader OpenCode and Claude Code comparison. Keep the first transfer narrow: the same rules, one small task, and a clear account of the result. The switching models hub covers other moves without assuming that sharing instructions makes tools behave identically.