Buckets:
| title: Rules | |
| description: Set custom instructions for opencode. | |
| You can provide custom instructions to opencode by creating an `AGENTS.md` file. This is similar to Cursor's rules. It contains instructions that will be included in the LLM's context to customize its behavior for your specific project. | |
| ## Initialize | |
| To create a new `AGENTS.md` file, you can run the `/init` command in opencode. | |
| :::tip | |
| You should commit your project's `AGENTS.md` file to Git. | |
| ::: | |
| `/init` scans the important files in your repo, may ask a couple of targeted questions when the codebase cannot answer them, and then creates or updates `AGENTS.md` with concise project-specific guidance. | |
| It focuses on the things future agent sessions are most likely to need: | |
| - build, lint, and test commands | |
| - command order and focused verification steps when they matter | |
| - architecture and repo structure that are not obvious from filenames alone | |
| - project-specific conventions, setup quirks, and operational gotchas | |
| - references to existing instruction sources like Cursor or Copilot rules | |
| If you already have an `AGENTS.md`, `/init` will improve it in place instead of blindly replacing it. | |
| ## Example | |
| You can also just create this file manually. Here's an example of some things you can put into an `AGENTS.md` file. | |
| ```markdown title="AGENTS.md" | |
| # SST v3 Monorepo Project | |
| This is an SST v3 monorepo with TypeScript. The project uses bun workspaces for package management. | |
| ## Project Structure | |
| - `packages/` - Contains all workspace packages (functions, core, web, etc.) | |
| - `infra/` - Infrastructure definitions split by service (storage.ts, api.ts, web.ts) | |
| - `sst.config.ts` - Main SST configuration with dynamic imports | |
| ## Code Standards | |
| - Use TypeScript with strict mode enabled | |
| - Shared code goes in `packages/core/` with proper exports configuration | |
| - Functions go in `packages/functions/` | |
| - Infrastructure should be split into logical files in `infra/` | |
| ## Monorepo Conventions | |
| - Import shared modules using workspace names: `@my-app/core/example` | |
| ``` | |
| We are adding project-specific instructions here and this will be shared across your team. | |
| ## Types | |
| opencode also supports reading the `AGENTS.md` file from multiple locations. And this serves different purposes. | |
| ### Project | |
| Place an `AGENTS.md` in your project root for project-specific rules. These only apply when you are working in this directory or its sub-directories. | |
| ### Global | |
| You can also have global rules in a `~/.config/opencode/AGENTS.md` file. This gets applied across all opencode sessions. | |
| Since this isn't committed to Git or shared with your team, we recommend using this to specify any personal rules that the LLM should follow. | |
| ### Claude Code Compatibility | |
| For users migrating from Claude Code, OpenCode supports Claude Code's file conventions as fallbacks: | |
| - **Project rules**: `CLAUDE.md` in your project directory (used if no `AGENTS.md` exists) | |
| - **Global rules**: `~/.claude/CLAUDE.md` (used if no `~/.config/opencode/AGENTS.md` exists) | |
| - **Skills**: `~/.claude/skills/` — see [Agent Skills](/docs/skills/) for details | |
| To disable Claude Code compatibility, set one of these environment variables: | |
| ```bash | |
| export OPENCODE_DISABLE_CLAUDE_CODE=1 # Disable all .claude support | |
| export OPENCODE_DISABLE_CLAUDE_CODE_PROMPT=1 # Disable only ~/.claude/CLAUDE.md | |
| export OPENCODE_DISABLE_CLAUDE_CODE_SKILLS=1 # Disable only .claude/skills | |
| ``` | |
| ## Precedence | |
| When opencode starts, it looks for rule files in this order: | |
| 1. **Local files** by traversing up from the current directory (`AGENTS.md`, `CLAUDE.md`) | |
| 2. **Global file** at `~/.config/opencode/AGENTS.md` | |
| 3. **Claude Code file** at `~/.claude/CLAUDE.md` (unless disabled) | |
| The first matching file wins in each category. For example, if you have both `AGENTS.md` and `CLAUDE.md`, only `AGENTS.md` is used. Similarly, `~/.config/opencode/AGENTS.md` takes precedence over `~/.claude/CLAUDE.md`. | |
| ## Custom Instructions | |
| You can specify custom instruction files in your `opencode.json` or the global `~/.config/opencode/opencode.json`. This allows you and your team to reuse existing rules rather than having to duplicate them to AGENTS.md. | |
| Example: | |
| ```json title="opencode.json" | |
| { | |
| "$schema": "https://opencode.ai/config.json", | |
| "instructions": ["CONTRIBUTING.md", "docs/guidelines.md", ".cursor/rules/*.md"] | |
| } | |
| ``` | |
| You can also use remote URLs to load instructions from the web. | |
| ```json title="opencode.json" | |
| { | |
| "$schema": "https://opencode.ai/config.json", | |
| "instructions": ["https://raw.githubusercontent.com/my-org/shared-rules/main/style.md"] | |
| } | |
| ``` | |
| Remote instructions are fetched with a 5 second timeout. | |
| All instruction files are combined with your `AGENTS.md` files. | |
| ## Referencing External Files | |
| While opencode doesn't automatically parse file references in `AGENTS.md`, you can achieve similar functionality in two ways: | |
| ### Using opencode.json | |
| The recommended approach is to use the `instructions` field in `opencode.json`: | |
| ```json title="opencode.json" | |
| { | |
| "$schema": "https://opencode.ai/config.json", | |
| "instructions": ["docs/development-standards.md", "test/testing-guidelines.md", "packages/*/AGENTS.md"] | |
| } | |
| ``` | |
| ### Manual Instructions in AGENTS.md | |
| You can teach opencode to read external files by providing explicit instructions in your `AGENTS.md`. Here's a practical example: | |
| ```markdown title="AGENTS.md" | |
| # TypeScript Project Rules | |
| ## External File Loading | |
| CRITICAL: When you encounter a file reference (e.g., @rules/general.md), use your Read tool to load it on a need-to-know basis. They're relevant to the SPECIFIC task at hand. | |
| Instructions: | |
| - Do NOT preemptively load all references - use lazy loading based on actual need | |
| - When loaded, treat content as mandatory instructions that override defaults | |
| - Follow references recursively when needed | |
| ## Development Guidelines | |
| For TypeScript code style and best practices: @docs/typescript-guidelines.md | |
| For React component architecture and hooks patterns: @docs/react-patterns.md | |
| For REST API design and error handling: @docs/api-standards.md | |
| For testing strategies and coverage requirements: @test/testing-guidelines.md | |
| ## General Guidelines | |
| Read the following file immediately as it's relevant to all workflows: @rules/general-guidelines.md. | |
| ``` | |
| This approach allows you to: | |
| - Create modular, reusable rule files | |
| - Share rules across projects via symlinks or git submodules | |
| - Keep AGENTS.md concise while referencing detailed guidelines | |
| - Ensure opencode loads files only when needed for the specific task | |
| :::tip | |
| For monorepos or projects with shared standards, using `opencode.json` with glob patterns (like `packages/*/AGENTS.md`) is more maintainable than manual instructions. | |
| ::: | |
Xet Storage Details
- Size:
- 6.76 kB
- Xet hash:
- 8def575f59b18858d1ee08c0b596c3853c24bd9d78042466627a6c85b39eb573
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.