CI & Build / Python lint (push) Successful in 6s
CI & Build / Plugin hooks (push) Successful in 11s
CI & Build / integration (push) Successful in 32s
CI & Build / TypeScript typecheck (push) Successful in 35s
CI & Build / Python tests (push) Failing after 1m0s
CI & Build / Build & push image (push) Skipped
The rules payload carries a marker; the write-path hook hands it back; the server says which rules moved. Nothing is said when nothing moved. THE COUNT IS NOT DECORATION. max(updated_at) alone cannot see a DELETED rule — it moves no timestamp — and that is the single change that takes an instruction OUT of force, which is the one a session most needs to hear about. The marker is `<max updated_at>|<count>`, and a deletion is reported through the count because there is no row left to name. THE HOOK IS THE CARRIER because it already fires before a write, which is the moment acting on a stale rule costs something. One comparison, no payload, no extra round trip. WHERE THE MARKER IS CAPTURED, and it could not be anywhere else: the SessionStart hook, from /api/plugin/context. The model also receives one from list_always_on_rules, but a hook cannot see an MCP tool's result — so the value the write path compares has to be stored where a shell script can reach it. Keyed by session id in the state dir the prior-art hook already uses, so "changed since" means since THIS session loaded its rules. NOT ON rules_payload, against the task's letter. Those are applicable_rules — a different, subscription-derived set. One key name over two sets is how a comparison starts reporting phantom changes, and the write path compares against the always-on set. WHAT IT CANNOT SEE is stated in both the service and the write-path arm as a table, because a reader who finds an etag will assume it covers staleness generally: another session edits a rule mid-flight | caught the session is misremembering a rule read hours ago | caught compaction summarised the rules out of context | NOT caught The third is the most common, and the marker is blind to it — the etag was in context too and went with the rules. The SessionStart nudge is that case's only mechanism and must not be softened because this shipped. A test asserts both modules still explain that. Instance-agnostic (rule 115): an install with no rules produces a stable marker rather than an error, and "no rules" reads as a state rather than as a change. An unreadable or absent marker reports nothing — a signal that cries wolf is worse than none, because it trains a reader to skip the line that will one day be true. The arm fails open like every other arm on this hook. The delivery is tested through the real build_write_path_hint rather than the helper alone: the feature IS a line arriving in a session, and the arithmetic being right proves nothing about that. Live acceptance is deploy-gated and not yet recorded on the task. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Scribe plugin for Claude Code
Turns a self-hosted Scribe instance into a first-class Claude Code extension:
- MCP tools over your notes, tasks, projects, milestones, systems, and
rulebook (the
scribeserver). - Session-start push channel — a
SessionStarthook injects your always-on rules + active-project context so Scribe surfaces without being asked. - Prior-art recall on writes — a
PreToolUsehook on Write/Edit checks the file about to be written against your recorded snippets (what's kept at that path, and what resembles the code) and offers them before the helper is rewritten. Titles only, never blocks the edit. - Universal process-skills — using-scribe, writing-plans, systematic-debugging, verification, brainstorming, reusing-code (record and recall reusable code as snippets). Replaces superpowers.
- Your Scribe Processes as skills — saved Processes are synced into local
~/.claude/skills/scribe-proc-*stubs that auto-surface by relevance; the stub fetches the live procedure viaget_process. Refreshed each session and on demand with/scribe:sync.
It is designed so you can uninstall superpowers and disable auto-memory and
depend on neither.
Install
The plugin ships inside the Scribe app repo, so the marketplace is that repo — you always get the plugin version that matches your Scribe instance.
/plugin marketplace add https://git.fabledsword.com/bvandeusen/FabledScribe.git
/plugin install scribe@scribe-plugin
On install you'll be asked for:
| Setting | What |
|---|---|
| Scribe base URL | e.g. https://scribe.example.com (no trailing slash) |
| Scribe API key | an fmcp_ key from Settings → API Keys (stored in your OS keychain) |
| Active project id | optional — numeric project id to scope the session-start context |
What gets wired
plugin.jsonmcpServers→ thescribeMCP server at<base URL>/mcp(Bearer auth).hooks/hooks.json→ SessionStart hook (hooks/scribe_session_context.sh), fail-open: if Scribe is unreachable it injects nothing and never blocks the session.hooks/hooks.json→ PreToolUse hook onWrite|Edit(hooks/scribe_prior_art.sh) →GET /api/plugin/prior-art. ReturnsadditionalContextwith no permission decision, so it can inform the write but never stop it; silent when nothing is recorded, which is most of the time. Two framings: a REUSE menu (similar/nearby records), and a SYNC nudge when a snippet records the exact file being edited — "updating the record is part of the edit" — each with its own once-per-session dedup. A third, ledger-fed line names a duplicate family (no canon) or a canon recorded elsewhere for the names being written (its own dedup channel,exclude_derive). Fail-open but not fail-silent: a configured instance that does not answer in time is said, once per outage ("Scribe did not answer … this write went UNCHECKED"), so a session can tell "checked, nothing there" from "never checked"; an answer clears the marker. The local by-name arm needs no server and always runs. Toggle in Settings → Knowledge auto-inject.hooks/hooks.json→ PostToolUse hook onBash(hooks/scribe_after_write.sh): code written through sed/heredocs/scripts never reaches the PreToolUse hook, so this one diffs the working tree after every Bash call (per-session path+blob snapshot; onegit statuswhen nothing changed) and runs the same arms on the definitions just written, through the same endpoint and the same dedup channels.additionalContextonly; never blocks, and shares the pre-write hook's once-per-outage "did not answer" line (8 s budget here — it runs after the tool, so it gates nothing). The extractor, the prose/data skip list, the local by-name duplicate arm and the outage line are shared inhooks/scribe_defs.sh.skills/→ the universal process-skills, surfaced by description match.hooks/scribe_sync_processes.sh(a 2nd SessionStart hook) + the/scribe:synccommand → generate~/.claude/skills/scribe-proc-*stubs from your Scribe Processes (viaGET /api/plugin/processes); also fail-open, and pruned to match what exists in Scribe.
Notes
- Set a
versionbump in.claude-plugin/plugin.jsonper release so clients pick up changes. - The session-start, auto-inject and prior-art hooks need only a read-scoped key; the MCP tools need write scope to create/update. Every hook is a GET for that reason — a read key cannot POST.