fix(410): using-scribe states the retrieval reflex once, and the adapter stops restating it (#4039)
CI & Build / Python lint (push) Successful in 2s
CI & Build / Plugin hooks (push) Successful in 8s
CI & Build / TypeScript typecheck (push) Successful in 53s
CI & Build / integration (push) Successful in 55s
CI & Build / Python tests (push) Successful in 1m27s
CI & Build / Build & push image (push) Successful in 13s

Step 7's live check (#4034 "a real session shows each topic stated once")
found nothing copied across surfaces, but found the owner repeating itself:
using-scribe said "rules are retrieved; ask before a consequential act; an
empty session is not an empty rulebook" in "Do this first", in reflex 2, and
twice more further down reflex 2.

- using-scribe: reflex 2 now holds the one full statement (how rules arrive,
  why that is the surface working, what silence means, when to ask). "Do this
  first" keeps the enter_project step and a short lead-in pointing at reflex
  2. "A retrieved rule outranks a default habit" and "Ask hardest where you
  feel most certain" stay, since each adds something.
- Adapter static context: "Lines injected beside your work" keeps only the
  Claude Code timing and leaves "never the whole set" to the skill. "Keep one
  copy" names CLAUDE.md and auto-memory and points at using-scribe, which
  already says to leave a client's settings as they are.
- The ownership registry's markers and statement for the topic still sit on
  using-scribe, and nothing else changed owner. Plugin version minted.

Sizes: using-scribe 18,823 -> 18,197 chars; scribe_static_context.md
1,797 -> 1,714.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-09-14 16:01:34 -04:00
co-authored by Claude Opus 5
parent 21343dc3aa
commit 9071cb05da
3 changed files with 23 additions and 36 deletions
+1 -1
View File
@@ -1,7 +1,7 @@
{
"name": "scribe",
"description": "Scribe for Claude Code: connects the scribe MCP server, adds the hooks that deliver live project state and relevant records at the right moment, ships the shared client-neutral Scribe skills (using-scribe, writing-plans, reporting-back, systematic-debugging, verification, brainstorming, reusing-code, shape-accounting), and syncs your saved Scribe Processes as skills (/scribe:sync).",
"version": "2026.09.14.1723",
"version": "2026.09.14.2001",
"author": {
"name": "Bryan Van Deusen"
},
+5 -6
View File
@@ -10,15 +10,14 @@ shape-accounting) carry their arcs.
What only Claude Code needs said:
- **Keep one copy — in Scribe, not Claude Code's local memory.** The
operator's rules, plans and project notes go to Scribe, not also to
`CLAUDE.md` or auto-memory. Leave auto-memory at its default setting: you
replace its job by doing the work in Scribe, not by switching it off.
- **Keep one copy — in Scribe, not Claude Code's local memory.** Claude
Code's local memory is `CLAUDE.md` and auto-memory: the operator's rules,
plans and project notes go to Scribe instead, and using-scribe says how
Scribe works alongside them.
- **Lines injected beside your work are retrieval.** When the operator sends a
message, and before a write or a command, Scribe may add rules, preferences,
notes and prior art that resemble what you are doing. Open the ones that
apply. They are what matched, never the whole set — using-scribe says how to
ask for the rest.
apply; using-scribe says what a quiet turn means.
- **Compact at clean seams.** Because work is recorded as you go, a compaction
is safe once in-flight state is logged. After finishing a block of work in a
long session, log it to Scribe, then tell the operator it's a good moment to
+17 -29
View File
@@ -13,23 +13,14 @@ asked for.
## Do this first (every session)
**You are not holding the operator's rules, and no call loads them all.**
There is no standing set to pull. A rule reaches you when what you are about to
do matches it — a command, code you are writing, or what the operator just
asked for — and on most turns none will. That is the surface working.
**So the reflex is to ASK, not to load.** Before a consequential act — anything
hard to reverse or outward-facing — `search(content_type="rule")` for the thing
you are about to do. An empty session is not evidence of an empty rulebook.
If the working repo maps to a Scribe project (you're in a known repo, or
`list_repo_bindings` shows a binding), call `enter_project(id)` — it returns the
project plus the rules bound to the areas it works in, open tasks, and recent
notes in one shot.
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.
Then **ask before you act**: before anything hard to reverse or outward-facing,
search the rules for what you are about to do. Reflex 2 below is why asking,
not loading, is how the operator's rules reach you.
## Scribe holds these functions — keep one copy
@@ -59,12 +50,20 @@ Two constraints on *how* that's achieved:
re-deriving it or opening a duplicate. When a project is in scope, pass its
`project_id` so results stay scoped.
2. **Rules are binding, and silence does not mean there are none.** Nothing
is preloaded, so "no rule arrived" means "nothing matched" — never "no rule
exists". Ask with `search(content_type="rule")` before a consequential act,
and pull a record's full statement with `get_rule(id)` when it is about to
bite. When a project is in scope, `enter_project(id)` also returns the rules
bound to its areas.
2. **Rules are binding, and they reach you by retrieval.** No call loads the
operator's rules and no standing set is handed to a session. A rule arrives
when what you are about to do resembles what it is about — a command, the
code you are writing, the operator's message — and on most turns none will.
That is the surface working: it is what lets a rulebook keep growing, since
a rule costs nothing in a session it has nothing to do with. A rule binds
just as hard for never having been handed to you.
So "no rule arrived" means "nothing matched", never "no rule exists" — an
empty session is not evidence of an empty rulebook. Retrieval fires when
something asks: before a consequential act, `search(content_type="rule")` on
what you are about to do, and pull a record's full statement with
`get_rule(id)` when it is about to bite. When a project is in scope,
`enter_project(id)` also returns the rules bound to its areas.
**`kind` says how much force a record carries, and it is never something to
infer.** A **rule** must be followed: ignoring it breaks something or
@@ -84,17 +83,6 @@ 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.
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.
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.
**A retrieved rule outranks a default habit.** Before a hard-to-reverse or
outward-facing act — changing shared state, publishing, deleting, sending
something outside the session — the operator's rules decide what to do, not