Disable/enable agent in front matter

[jonandersen]

Add support to disable/enable a rule for a specific agent in the front matter.

Example:

allow list:

allowed_agents: ["claude", "cursor", "firebender", "goose", "amp"]

block list

blocked_agents:  ["amp"]

[privatenumber]

Ran into this today with Claude Code hooks.

Claude Code has SessionStart hooks that can auto-activate tooling (like Hermit) by writing to $CLAUDE_ENV_FILE — so you don't need to prefix every bash command with source ./bin/activate-hermit &&.

We updated our hermit.md rule to say "automatically activated via SessionStart hook", but that's misleading for Cursor/Cline/Goose users who don't have hooks.

Current workaround is writing conditional prose in a single rule ("Claude Code users: X. Other agents: Y.") which is clunky and wastes tokens.

Would be cleaner to have two rules:

# hermit-claude.md
---
allowed_agents: [claude]
---
Hermit is automatically activated via SessionStart hook. Run commands directly.

# hermit-other.md  
---
blocked_agents: [claude]
---
Prefix every command with: source ./bin/activate-hermit && <command>

This would also reduce context window usage since agents only load rules relevant to their capabilities.

[lifeizhou-ap]

Hi @privatenumber,

Thanks for sharing your use case. It really helps understand the motivation behind this feature!

I have a question: would it be harmful for Claude to also have the hermit-other.md instruction? My understanding is that running source ./bin/activate-hermit when Hermit is already activated via the SessionStart hook should be idempotent (no side effect).

If that's the case, I wonder if a single universal rule might work well for all agents:

My thinking is that keeping project-specific setup instructions like this consistent across all agents helps keep things simple and avoids agents getting out of sync. Claude's hook can still provide an optimization sometimes, but the rule would serve as the source of truth for everyone.

I also chatted with @jonandersen , and it sounds like this feature is no longer a priority use case for him. So I wanted to check in with you: if the universal rule approach works, would you still need this feature? The implementation adds some code complexity and can be confusing for users, so we're trying to weigh the trade-offs.

Curious to hear your thoughts! Thank you!

[privatenumber]

Thanks but I wasn't really looking for help with workarounds. My intent was mainly to propose a feature that felt consistent with the project's direction. The use case is real, but was mostly meant to illustrate where this shows up in practice.

Based on how the project is described in the README (multi-agent rule management, selective generation, and keeping agent behavior predictable), agent-scoped rules felt like a missing expression layer. Different agents already have meaningfully different capabilities, and letting rules declare applicability directly keeps intent explicit instead of encoding it in prose.

You mentioned implementation complexity and possible confusion, which totally makes sense. I'm curious to hear what specific concerns you're thinking about there.

[lifeizhou-ap]

Hi @privatenumber,

Thanks for the detailed response!

Thanks but I wasn't really looking for help with workarounds.

In your Hermit case, "prefix commands with source ./bin/activate-hermit" works for everyone, including Claude (it's harmless when already activated). This is not a workaround — this is the simpler solution.

My intent was mainly to propose a feature that felt consistent with the project's direction. The use case is real, but was mostly meant to illustrate where this shows up in practice.

Based on how the project is described in the README (multi-agent rule management, selective generation, and keeping agent behavior predictable), agent-scoped rules felt like a missing expression layer. Different agents already have meaningfully different capabilities, and letting rules declare applicability directly keeps intent explicit instead of encoding it in prose.

The project direction is managing the same rules across all agents. The value: write rules once, update in one place, all agents stay in sync, make it easy for user to manage and maintain the rules without confusion.

Different agents do have different capabilities, but those belong in each agent's own config, not in ai-rules. For example, Claude's SessionStart hook is a Claude setting. "How to activate Hermit" is a rule for everyone. ai-rules is for universal rules.

The value of ai-rules is a clear mental model: define rules once, all agents get them. With filtering, users have to figure out: "Which agents get this rule? Does it show up in AGENTS.md or get excluded?" That adds confusion.

You mentioned implementation complexity and possible confusion, which totally makes sense. I'm curious to hear what specific concerns you're thinking about there.

The AGENTS.md problem: seven agents share this file. If you write allowedAgents: [goose], the PR excludes it from AGENTS.md to avoid leaking — but then goose never sees it either. The feature doesn't work for those agents.

Code complexity:

• Two parallel filtering paths (single agent vs. agent group) — more to maintain and test
• A hardcoded list of which agents share AGENTS.md — need to maintain this for new agents
• Separate optional-rules files per agent — more files to manage and debug

The trade-off: added complexity for all users, but only works for agents with dedicated files(not the seven sharing AGENTS.md) I'd need to see broader demand before taking this on.

Please let me know your thoughts!