Makes the always-on / subscribed / project-rule distinction explicit at the authoring surface so it can't silently regress (for this operator or other users).
Problem: the tools said only "cross-project rulebook rule" and a bare "subscribe a project" — nothing steered project-specific detail away from shared rulebooks, which is how a Scribe-pinned rule ends up binding every family project.
Principle encoded in 5 places: a rule's home is chosen by who it should bind; both rulebook tiers are SHARED so their rules stay general — they differ in reach (all projects vs opt-in by theme), not generality. Project-specific detail → create_project_rule.
Makes the always-on / subscribed / project-rule distinction explicit at the authoring surface so it can't silently regress (for this operator or other users).
**Problem:** the tools said only "cross-project rulebook rule" and a bare "subscribe a project" — nothing steered project-specific detail away from shared rulebooks, which is how a Scribe-pinned rule ends up binding every family project.
**Principle encoded in 5 places:** a rule's home is chosen by *who it should bind*; both rulebook tiers are SHARED so their rules stay general — they differ in *reach* (all projects vs opt-in by theme), not generality. Project-specific detail → `create_project_rule`.
- `server.py` MCP instructions: 3-tier authoring principle
- `create_rule` / `create_rulebook` / `create_project_rule` / `subscribe_project_to_rulebook` docstrings
- `using-scribe` SKILL.md: a "Where a new rule goes" note for the pull path
CI green on 50b6902 (run 811). Refs #755.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Make the always-on / subscribed / project-rule distinction explicit at the
authoring surface so it can't silently regress (for this operator or other
users). Previously the tools said only 'cross-project rulebook rule' and a
bare 'subscribe a project' — nothing steered project-specific detail away
from shared rulebooks, which is how a Scribe-pinned rule ends up binding
every family project.
Principle encoded in 5 places: a rule's home is chosen by WHO it should bind,
and both rulebook tiers are SHARED so their rules stay general — they differ
in reach (all projects vs opt-in by theme), not generality. Project-specific
detail goes in create_project_rule.
- server.py MCP instructions: add the 3-tier authoring principle
- create_rule / create_rulebook / create_project_rule / subscribe_* docstrings
- using-scribe SKILL.md: a 'Where a new rule goes' note for the pull path
Refs #755
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Makes the always-on / subscribed / project-rule distinction explicit at the authoring surface so it can't silently regress (for this operator or other users).
Problem: the tools said only "cross-project rulebook rule" and a bare "subscribe a project" — nothing steered project-specific detail away from shared rulebooks, which is how a Scribe-pinned rule ends up binding every family project.
Principle encoded in 5 places: a rule's home is chosen by who it should bind; both rulebook tiers are SHARED so their rules stay general — they differ in reach (all projects vs opt-in by theme), not generality. Project-specific detail →
create_project_rule.server.pyMCP instructions: 3-tier authoring principlecreate_rule/create_rulebook/create_project_rule/subscribe_project_to_rulebookdocstringsusing-scribeSKILL.md: a "Where a new rule goes" note for the pull pathCI green on
50b6902(run 811). Refs #755.🤖 Generated with Claude Code