bvandeusenandClaude Opus 5
106e396b09
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 11s
CI & Build / TypeScript typecheck (push) Successful in 55s
CI & Build / integration (push) Successful in 56s
CI & Build / Python tests (push) Successful in 1m36s
CI & Build / Build & push image (push) Successful in 12s
Step 4 of milestone 410 "One owner per piece of guidance". The plugin's static session context was a second copy of using-scribe and the server index. It now says only what Claude Code needs said: 8,705 -> 1,791 chars. scribe_static_context.md: - points at using-scribe for how to work with Scribe, and names the process skills - Claude Code specifics: keep one copy in Scribe rather than CLAUDE.md or auto-memory (leave auto-memory at its default); injected lines are retrieval, not the whole set; compact at clean seams; stored Processes arrive as scribe-proc-* skills with /scribe:sync; say so when the tools are unavailable - retired: the restated reflexes, "how the surfaces divide the work", and the "follow the surface that assumes least" precedence (decision #4027) Hook behaviour is unchanged. The SessionStart hook header says what the static tier now carries, and the unreachable-instance status points at the using-scribe skill instead of "the standing guidance above". README and manifest describe the plugin as the Claude Code adapter over the shared, client-neutral skills. Fixed along the way: the README said the SessionStart hook "injects your rules" and suggested disabling auto-memory, both contradicting the product since milestone 394. Tests: the session-start rules guards now pin the owner (using-scribe) and the index (_INSTRUCTIONS) rather than every surface; the Systems-reflex and snippet-trigger guards pin their owners; the reporting-reflex guard pins using-scribe. The loss guard and client-neutral guard stay green. Plugin version minted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1.8 KiB
1.8 KiB
Scribe — Claude Code adapter
This session is connected to Scribe, the operator's system of record for
their work, through the scribe MCP tools. How to work with Scribe is stated
once, in the using-scribe skill: reach for it at the start of the session
and whenever you are unsure what Scribe expects. Each tool's contract is in its
description, and the process skills (writing-plans, reporting-back,
reusing-code, systematic-debugging, verification, brainstorming,
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.mdor auto-memory. Leave auto-memory at its default setting: you replace its job by doing the work in Scribe, not by switching it off. - 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.
- 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
/compactand name what you logged. You can't run it yourself; suggest it at seams, not every turn. - Stored Processes arrive as skills (
scribe-proc-*), refreshed at session start. After a Process is added or edited,/scribe:syncmakes it available straight away. - If the Scribe tools are unavailable, say so rather than silently falling back to local notes.