[FEATURE]: Smart Rules - Context-aware instruction injection with Claude Code compatibility #7241

Open
opened 2026-02-16 18:06:33 -05:00 by yindo · 7 comments
Owner

Originally created by @raedkit on GitHub (Jan 22, 2026).

Originally assigned to: @thdxr on GitHub.

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Feature Request

Problem Statement

Currently, there's no way to automatically inject context-specific instructions based on the files being worked with. Users who want file-type-specific guidance (e.g., TypeScript conventions, React patterns, CSS formatting rules)
must either:

  1. Include all rules in a single AGENTS.md/CLAUDE.md file (bloating every prompt)
  2. Manually reference rules when needed (error-prone and tedious)

Additionally, users migrating from Claude Code have existing .claude/rules/ directories that aren't recognized by OpenCode.

Proposed Solution

Implement a Smart Rule system that:

  1. Automatically injects relevant rules based on files accessed during the session
  2. Supports both .opencode/rules/ and .claude/rules/ directories for cross-compatibility
  3. Uses glob patterns to match files (e.g., **/*.ts, src/components/**/*.tsx)
  4. Caches rule discovery for performance (loaded once per project)

Rule File Format

---                                                                                                                                                                                                                                     
description: "TypeScript formatting guidelines"                                                                                                                                                                                         
paths:                                                                                                                                                                                                                                  
  - "**/*.ts"                                                                                                                                                                                                                           
  - "**/*.tsx"                                                                                                                                                                                                                          
alwaysApply: false                                                                                                                                                                                                                      
---                                                                                                                                                                                                                                     
                                                                                                                                                                                                                                        
# TypeScript Guidelines                                                                                                                                                                                                                 
                                                                                                                                                                                                                                        
- Use strict mode                                                                                                                                                                                                                       
- Prefer interfaces over types                                                                                                                                                                                                          

Rule Discovery Locations

Location Scope Precedence
~/.config/opencode/rules/ Global Lowest
~/.claude/rules/ Global (Claude compat) Low
.claude/rules/ Project (Claude compat) Medium
.opencode/rules/ Project Highest

Configuration

Feature gated behind experimental flag:

export OPENCODE_EXPERIMENTAL_SMART_RULES=true                                                                                                                                                                                           
# or                                                                                                                                                                                                                                    
export OPENCODE_EXPERIMENTAL=true                                                                                                                                                                                                       

Use Cases

  1. Language-specific conventions: TypeScript strict mode, Python PEP8, Go formatting
  2. Framework patterns: React hooks rules, Next.js best practices, Vue composition API
  3. Project-specific guidelines: Team coding standards, architecture decisions
  4. Migration from Claude Code: Seamless support for existing .claude/rules/ directories

Benefits

  • Reduced prompt bloat: Only relevant rules are injected
  • Better organization: Rules are modular and file-based
  • Cross-tool compatibility: Works with existing Claude Code setups
  • Zero config for basic use: Just create markdown files in the rules directory

Technical Considerations

  • Piggybacks on existing FileTime.read() for tracking (no new hooks)
  • Uses Instance.state() for per-project caching
  • Pre-compiles minimatch patterns for performance
  • Early exit when feature is disabled (zero overhead)

Acceptance Criteria

  • Rules in .opencode/rules/ are discovered and parsed
  • Rules in .claude/rules/ are discovered (Claude Code compatibility)
  • Global rules from ~/.config/opencode/rules/ work
  • Glob patterns correctly match files
  • alwaysApply: true rules are always included
  • Higher precedence rules override lower ones (by name)
  • Feature is disabled by default (experimental flag)
  • No performance impact when feature is disabled
Originally created by @raedkit on GitHub (Jan 22, 2026). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request ## Feature Request ### Problem Statement Currently, there's no way to automatically inject context-specific instructions based on the files being worked with. Users who want file-type-specific guidance (e.g., TypeScript conventions, React patterns, CSS formatting rules) must either: 1. Include all rules in a single `AGENTS.md`/`CLAUDE.md` file (bloating every prompt) 2. Manually reference rules when needed (error-prone and tedious) Additionally, users migrating from Claude Code have existing `.claude/rules/` directories that aren't recognized by OpenCode. ### Proposed Solution Implement a **Smart Rule** system that: 1. **Automatically injects relevant rules** based on files accessed during the session 2. **Supports both `.opencode/rules/` and `.claude/rules/`** directories for cross-compatibility 3. **Uses glob patterns** to match files (e.g., `**/*.ts`, `src/components/**/*.tsx`) 4. **Caches rule discovery** for performance (loaded once per project) ### Rule File Format ```markdown --- description: "TypeScript formatting guidelines" paths: - "**/*.ts" - "**/*.tsx" alwaysApply: false --- # TypeScript Guidelines - Use strict mode - Prefer interfaces over types ``` ### Rule Discovery Locations | Location | Scope | Precedence | |----------|-------|------------| | `~/.config/opencode/rules/` | Global | Lowest | | `~/.claude/rules/` | Global (Claude compat) | Low | | `.claude/rules/` | Project (Claude compat) | Medium | | `.opencode/rules/` | Project | Highest | ### Configuration Feature gated behind experimental flag: ```bash export OPENCODE_EXPERIMENTAL_SMART_RULES=true # or export OPENCODE_EXPERIMENTAL=true ``` ### Use Cases 1. **Language-specific conventions**: TypeScript strict mode, Python PEP8, Go formatting 2. **Framework patterns**: React hooks rules, Next.js best practices, Vue composition API 3. **Project-specific guidelines**: Team coding standards, architecture decisions 4. **Migration from Claude Code**: Seamless support for existing `.claude/rules/` directories ### Benefits - **Reduced prompt bloat**: Only relevant rules are injected - **Better organization**: Rules are modular and file-based - **Cross-tool compatibility**: Works with existing Claude Code setups - **Zero config for basic use**: Just create markdown files in the rules directory ### Technical Considerations - Piggybacks on existing `FileTime.read()` for tracking (no new hooks) - Uses `Instance.state()` for per-project caching - Pre-compiles `minimatch` patterns for performance - Early exit when feature is disabled (zero overhead) ### Acceptance Criteria - [ ] Rules in `.opencode/rules/` are discovered and parsed - [ ] Rules in `.claude/rules/` are discovered (Claude Code compatibility) - [ ] Global rules from `~/.config/opencode/rules/` work - [ ] Glob patterns correctly match files - [ ] `alwaysApply: true` rules are always included - [ ] Higher precedence rules override lower ones (by name) - [ ] Feature is disabled by default (experimental flag) - [ ] No performance impact when feature is disabled
yindo added the discussion label 2026-02-16 18:06:33 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 22, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #9968: IDE configuration improvements including rules management
  • #9677: Local Claude Code CLI Provider
  • #9637: Auto Context Compression (like Claude Code)
  • #9499: Merged commands and skills for Claude Code parity
  • #9746: Custom provider integration questions

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 22, 2026): This issue might be a duplicate of existing issues. Please check: - #9968: IDE configuration improvements including rules management - #9677: Local Claude Code CLI Provider - #9637: Auto Context Compression (like Claude Code) - #9499: Merged commands and skills for Claude Code parity - #9746: Custom provider integration questions Feel free to ignore if none of these address your specific case.
Author
Owner

@dkraemerwork commented on GitHub (Jan 22, 2026):

You can just use pre or post turn hooks.

@dkraemerwork commented on GitHub (Jan 22, 2026): You can just use pre or post turn hooks.
Author
Owner

@raedkit commented on GitHub (Jan 22, 2026):

You can just use pre or post turn hooks.

Have you read the full feature and checked the proposed pull request ? The implementation is made to not be triggered/verified for each turn, and it's path based activated.
Also this feature is proposed in Claude Code and it will help people migrate from Claude Code or work in parallel in the 2 tools like the already implemented skills and CLAUDE.md files.

@raedkit commented on GitHub (Jan 22, 2026): > You can just use pre or post turn hooks. Have you read the full feature and checked the proposed pull request ? The implementation is made to not be triggered/verified for each turn, and it's path based activated. Also this feature is proposed in Claude Code and it will help people migrate from Claude Code or work in parallel in the 2 tools like the already implemented skills and CLAUDE.md files.
Author
Owner

@dkraemerwork commented on GitHub (Jan 22, 2026):

Yes, counter question:
When do you think this check of Inject in message or not will be done?

@dkraemerwork commented on GitHub (Jan 22, 2026): Yes, counter question: When do you think this check of *Inject in message or not* will be done?
Author
Owner

@dkraemerwork commented on GitHub (Jan 22, 2026):

Spoiler: In any turn, its possible to touch different files. So the check is made each turn..

@dkraemerwork commented on GitHub (Jan 22, 2026): Spoiler: In any turn, its possible to touch different files. So the check is made each turn..
Author
Owner

@dkraemerwork commented on GitHub (Jan 22, 2026):

The solution for claude code also just is: pre turn, ls files, is there a CLAUDE.md, yes? read, then continue; else, no, continue

@dkraemerwork commented on GitHub (Jan 22, 2026): The solution for claude code also just is: pre turn, ls files, is there a CLAUDE.md, yes? read, then continue; else, no, continue
Author
Owner

@florian-trehaut commented on GitHub (Jan 23, 2026):

Great feature! This would really help users who work with both Claude Code and OpenCode.

Question about scope expansion: Would it be possible to extend this compatibility to also support .claude/agents/ alongside .claude/rules/?

I have custom subagents defined in .claude/agents/ (e.g., specialized code reviewers for Rust, architecture, security, etc.) that I'd like to use in both tools without maintaining duplicate configurations.

The frontmatter format differs slightly between Claude Code and OpenCode agents:

  • Claude Code uses name:, tools: (as list), model: haiku
  • OpenCode uses filename as name, tools: (as object with booleans), model: anthropic/claude-haiku-4-*

A similar discovery + conversion layer for agents would enable seamless cross-tool workflows.

@florian-trehaut commented on GitHub (Jan 23, 2026): Great feature! This would really help users who work with both Claude Code and OpenCode. **Question about scope expansion:** Would it be possible to extend this compatibility to also support `.claude/agents/` alongside `.claude/rules/`? I have custom subagents defined in `.claude/agents/` (e.g., specialized code reviewers for Rust, architecture, security, etc.) that I'd like to use in both tools without maintaining duplicate configurations. The frontmatter format differs slightly between Claude Code and OpenCode agents: - Claude Code uses `name:`, `tools:` (as list), `model: haiku` - OpenCode uses filename as name, `tools:` (as object with booleans), `model: anthropic/claude-haiku-4-*` A similar discovery + conversion layer for agents would enable seamless cross-tool workflows.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#7241