fix(#4022): instruction surfaces stop describing the always-on tier milestone 394 removed
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 12s
CI & Build / integration (push) Successful in 47s
CI & Build / TypeScript typecheck (push) Successful in 58s
CI & Build / Python tests (push) Successful in 1m41s
CI & Build / Build & push image (push) Successful in 28s
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 12s
CI & Build / integration (push) Successful in 47s
CI & Build / TypeScript typecheck (push) Successful in 58s
CI & Build / Python tests (push) Successful in 1m41s
CI & Build / Build & push image (push) Successful in 28s
Skill bodies and tool docstrings still taught the deleted model: using-scribe said always-on rules "arrive whether or not you ask" and that SessionStart may inject a rule index; create_project, decide_project_inception and enter_project said an undecided project gets "every always-on rulebook"; create_rule pointed standards at "the always-on one"; the verification sweeps and retrieval_telemetry listed always-on paths and a live preload. Every passage now describes the current model: every rule is retrieved, a rulebook binds only by subscription, an undecided project inherits nothing, and the preload survives only in telemetry rows older than 394. Also repairs three sentences left half-replaced by the 394 edits: the static context's "If you have not loaded the no rule has arrived", create_rule's "an A subscribed rulebook", and create_project's doubled subscribe_rulebooks entry. Plugin version minted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "scribe",
|
||||
"description": "Scribe system-of-record for Claude Code: MCP tools over your notes/tasks/projects/rules, a session-start push channel that surfaces your active-project context, process-skills (writing-plans, reporting-back, systematic-debugging, verification, brainstorming, reusing-code), and your saved Scribe Processes auto-surfaced as skills (/scribe:sync). Replaces superpowers + file-memory with one app-backed plugin.",
|
||||
"version": "2026.09.14.1411",
|
||||
"version": "2026.09.14.1438",
|
||||
"author": {
|
||||
"name": "Bryan Van Deusen"
|
||||
},
|
||||
|
||||
@@ -17,9 +17,9 @@ for the operator's work, and as your own working memory across sessions.
|
||||
commit / push, or any other hard-to-reverse or outward-facing action, the
|
||||
operator's Scribe rules decide what to do — NOT generic conventions baked
|
||||
into the harness or your defaults (e.g. "branch before committing," "open a
|
||||
feature branch per task," "push to a fork"). If you have not loaded the
|
||||
no rule has arrived for the act in front of you, `search(content_type=
|
||||
"rule")` BEFORE acting rather than falling back on a default habit. When a
|
||||
feature branch per task," "push to a fork"). If no rule has arrived for the
|
||||
act in front of you, `search(content_type="rule")` BEFORE acting rather than
|
||||
falling back on a default habit. When a
|
||||
retrieved rule and a default habit disagree, the rule wins; if no rule
|
||||
speaks to it, ask rather than assume.
|
||||
- **Rules bind; preferences do not.** A record's `kind` says which. A **rule**
|
||||
|
||||
@@ -27,10 +27,9 @@ If the working repo maps to a Scribe project (you're in a known repo, or
|
||||
project plus the rules bound to the areas it works in, open tasks, and recent
|
||||
notes in one shot.
|
||||
|
||||
Do this actively. A SessionStart hook *may* also inject a rule index, but treat
|
||||
that as a bonus, not a precondition: it can be absent (e.g. when the instance is
|
||||
unreachable, or the token didn't reach the hook), so the reliable path is this
|
||||
explicit pull. Rules loaded this way are **binding** for the session.
|
||||
Do this actively. Nothing is handed to a session up front to stand in for it —
|
||||
rules arrive by retrieval, when your work or the operator's message matches
|
||||
one — so asking and entering the project are the reliable path.
|
||||
|
||||
## Scribe holds these functions — don't keep a second copy
|
||||
|
||||
@@ -88,17 +87,16 @@ Two constraints on *how* that's achieved:
|
||||
asks. If what you learned is that something MUST be done a certain way,
|
||||
that is a rule to propose, not a preference to harden in place.
|
||||
|
||||
Rules come in two tiers. **Always-on** rules are delivered — they arrive
|
||||
whether or not you ask. **Conditional** rules are RETRIEVED, and one binds
|
||||
just as hard for never having been handed to you. So before a consequential
|
||||
act, `search(content_type="rule")` on what you are about to do. An empty
|
||||
loaded set is not evidence that no rule applies; it is only evidence that
|
||||
none was pushed, and those are different claims.
|
||||
Every rule is RETRIEVED: one reaches you when a command, the code you are
|
||||
writing or the operator's message resembles what it is about, and a rule
|
||||
binds just as hard for never having been handed to you. So before a
|
||||
consequential act, `search(content_type="rule")` on what you are about to
|
||||
do. An empty session is not evidence that no rule applies; it is only
|
||||
evidence that nothing has matched yet, and those are different claims.
|
||||
|
||||
The tier split exists because delivery does not scale: every resident rule
|
||||
costs tokens in every session forever, so a rulebook that grows past a few
|
||||
dozen either stops growing or stops fitting. Retrieval is what lets the
|
||||
rulebook keep growing — but retrieval only fires if something asks.
|
||||
Retrieval is what lets a rulebook keep growing — a rule costs nothing in a
|
||||
session it has nothing to do with — but retrieval only fires if something
|
||||
asks.
|
||||
|
||||
**Ask hardest where you feel most certain.** Rules about which TOOL to reach
|
||||
for — use the forge's MCP client rather than curling its API, don't stand up
|
||||
|
||||
Reference in New Issue
Block a user