Skip to content

External files are not read in AGENTS.md #832

@almirsarajcic

Description

@almirsarajcic

Transitioning from Cursor -> Claude Code -> opencode I've been using various rules (https://github.com/optimumBA/cursor_rules).

So to make that maintainable, in Claude Code I referenced external files in CLAUDE.md and it worked pretty well.
https://docs.anthropic.com/en/docs/claude-code/memory#claude-md-imports

Besides rules being respected, I know that it worked because Claude Code would ask me the first time I open it in some directory that contains CLAUDE.md file whether I want to allow it to read external files referenced in the CLAUDE.md.

Now, in opencode, these rules aren't respected.

This is what my AGENTS.md file looks like:

# AGENTS.md

This file provides guidance to AI assistants when working with code in this repository.

...

## Coding Guidelines

### Development Rules

This project uses centralized development rules available at: @codegen/rules/RULES.md

Rules are automatically applied based on context and file types being worked on.

...

and then the RULES.md file looks like this:

# Rules Index

This directory provides centralized development rules for any repository that includes these rules via symbolic link. Works with Claude Code and other AI assistants.

## Rule System Structure

Each rule file contains specific guidance for different aspects of development. Rules are organized by domain and responsibility:

- **@phoenix.md** - Phoenix framework development, LiveView, contexts, schemas, generators, PubSub, database operations
- **@elixir-code-generation.md** - Elixir code quality, specs, types, proper patterns, avoiding redundancy  
- **@elixir-readability.md** - Code formatting, sorting, pipe usage, variable naming, structure organization
- **@elixir-error-handling.md** - Error patterns, exception handling, validation approaches
- **@elixir-ci.md** - Testing, CI failures, code coverage, formatting issues, database test problems
- **@git.md** - Read-only git operations, viewing repository state, prohibited write operations
- **@planning.md** - Feature planning, development plans, documentation, project stages organization
- **@project-structure.md** - Directory organization, file naming, module placement conventions
- **@javascript-code-generation.md** - JavaScript/TypeScript patterns, LiveView hooks, frontend development
- **@i18n.md** - Internationalization patterns, gettext workflow, translation management
- **@github-workflows.md** - CI/CD patterns, GitHub Actions, deployment automation
- **@wallaby.md** - Browser testing, end-to-end testing, ChromeDriver usage
- **@npm-packages.md** - Package management, JavaScript dependencies in Phoenix projects
- **@comments.md** - Code documentation, when to add comments, documentation standards

## Usage Instructions

When working on code that matches the rule descriptions, apply the corresponding rule automatically. Rules are designed to be concise and actionable, focusing on specific development scenarios.

Unlike Cursor's .mdc format, these rules are integrated directly into the CLAUDE.md file context and activated based on relevance to the current task.

## Rule Integration

To use these rules in a project:

1. Set the environment variable: `export OCG_RULES_DIR=<path-to-rules-directory>`
2. Run `ocg setup` which will automatically create the symbolic link to `codegen/rules`
3. Reference this file from your project's CLAUDE.md with: `@codegen/rules/RULES.md`
4. Individual rules can be referenced as needed: `@codegen/rules/phoenix.md`, `@codegen/rules/elixir-code-generation.md`, etc.

Alternatively, you can manually create the symbolic link: `ln -s <rules_dir> codegen/rules`

This approach provides modular, reusable development guidance across all projects while maintaining project-specific customizations in the main CLAUDE.md file.

## Maintenance

Rules are maintained centrally in `<rules_dir>` and updated as development practices evolve. Changes automatically propagate to all projects using symbolic links.

To make things worse, my RULES.md file is a symlink to a centralized RULES.md file that I use for every project. I don't think that should make a difference for opencode, but I thought it's worth a mention.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions