[FEATURE] Operation-scoped rules: separate read (execution) vs write (authoring) triggers

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Rules with paths: frontmatter fire whenever a matching file enters the conversation context. There is no way to distinguish why the file entered context — whether Claude is executing a skill (reading a SKILL.md to follow its instructions) or authoring/editing a file (reading it before making changes).

This conflates two distinct use cases into a single trigger, making it impossible to write rules that apply only during one operation type.

Real-World Use Case: Skill Authoring vs Skill Execution

I maintain a set of Claude Code skills in .claude/skills/. I have a rule file for skill authoring conventions:

---
paths:
  - ".claude/skills/**/*"
---
# Skill Authoring Guidelines
- Keep SKILL.md under 500 lines
- Put deterministic operations in scripts/
- Provide exact prompt template text, not descriptions

I also need runtime execution rules for when skills are being run:

# Skill Execution Rules
- Do not re-display or reformat script output — it is already visible to the user
- Use plain text prompts, not multi-choice pickers — the script table is the selection UI

The problem: Both rule sets target .claude/skills/**/* because skill execution reads the same SKILL.md files that authoring edits. Today, both rules load in both contexts:

• When I run /my-skill, the authoring rules load too ("keep SKILL.md under 500 lines" is noise during execution)
• When I'm editing a SKILL.md, the execution rules load too ("don't re-display script output" is irrelevant while authoring)

Currently I have to merge both into a single rule file and accept that all rules are always in context regardless of operation. This wastes tokens and can cause behavioral interference (Claude applying authoring advice during execution, or execution advice during authoring).

Proposed Solution

Add an optional trigger (or on) field to rules frontmatter to scope when the rule loads:

---
paths:
  - ".claude/skills/**/*"
trigger: read
---
# Skill Execution Rules (loaded when skills are read/executed)

---
paths:
  - ".claude/skills/**/*"
trigger: write
---
# Skill Authoring Guidelines (loaded when skills are being edited)

Possible values:

• read — rule loads when a matching file enters context for reading/execution purposes only
• write — rule loads when a matching file is about to be written or edited
• read+write — current default behavior (always loads on any matching file operation)

If trigger is omitted, the behavior is read+write (backwards compatible with today).

Design Consideration: Read-Before-Edit

A naive tool-level implementation would not be sufficient. Claude reads files before editing them — so during an authoring session, a trigger: read rule would fire too (since the Read tool is called as part of the edit workflow). The feature needs to distinguish intent — "is this read for execution/research, or is it a read-before-edit?" — rather than simply matching on which tool was invoked. This likely requires the rule engine to be aware of the surrounding operation context, not just the immediate tool call.

Alternative Solutions

• Duplicate rules into each SKILL.md — works but creates N copies that drift out of sync
• Merge everything into one rule file — current approach, but every rule loads in every context regardless of relevance
• Use hooks to inject context conditionally — possible via PreToolUse but adds significant complexity for what should be a declarative configuration

Relationship to Prior Issues

• #23478 (closed/stale) — reported that rules don't fire on Write, only on Read. That's the trigger gap. This issue is about the trigger granularity: even once Write triggers are fixed, there's no way to say "this rule is only for write operations."
• #27861 (closed as duplicate of #23478) — proposed [mode: read] / [mode: write] scoping. The auto-closure as a duplicate was incorrect — operation-type scoping is a distinct feature from fixing the Write trigger bug. This issue refines that proposal with a concrete use case and flags the read-before-edit design challenge.

Priority

Low - Nice to have

Feature Category

File operations