bvandeusen
51e5c22818
CI & Build / Plugin hooks (push) Failing after 2s
CI & Build / Python lint (push) Successful in 8s
CI & Build / integration (push) Successful in 31s
CI & Build / TypeScript typecheck (push) Successful in 33s
CI & Build / Python tests (push) Successful in 55s
CI & Build / Build & push image (push) Successful in 20s
`plugin/` is not built into the image; installs fetch it from this repo via .claude-plugin/marketplace.json, so a push IS the release. It was absent from the workflow's `paths:` filter entirely, meaning plugin changes ran no CI at all. Two separate defects reached a live install through that gap: #2198 — all four hook scripts inert (lowercase userConfig env vars, line-oriented `jq -rR`, line-oriented `cut -c`) #2209 — the fix for #2198 couldn't reach an install because the manifest version wasn't bumped, so the installer never refreshed its cache Adds `plugin/**` + `.claude-plugin/**` to `paths:` and a `plugin` job running scripts/check_plugin.py: 1. `bash -n` on every hook. 2. The three known-bad patterns from #2198. Verified by replay against c569cdd^ — all three are caught. Narrow by design; see below. 3. Shipped plugin content differs from origin/main => the manifest version must differ too. Stated against the base branch, not per-commit, so a batch needs one bump rather than one per commit. Replayed againstc569cdd: correctly fails. The checker found a real outstanding bug on its first run: the `cut -c1-2000` prompt cap in scribe_autoinject.sh was still line-oriented. Only the prior-art hook's copy got fixed inc569cdd. Now `head -c`. It then failed on this very commit for a missing version bump, which is the third time that rule has mattered and the first time something other than memory enforced it. Manifest bumped to 0.1.20. WHAT THIS DOESN'T COVER, and why. shellcheck is the right tool for check 2 and is NOT in ci-python; nor is jq, which every hook requires and silently bails without — so a "runs and stays silent" smoke test would pass vacuously today and prove nothing. Both need those two packages added to the CI image in the CI-runner repo, which is a separate change to a separate repo (rule #5: the toolchain comes from the image, not from apt-get at job start). Verified against CI-runner's Dockerfile and scripts/install-common.sh rather than assumed (rule #37). `plugin` is not in the build job's `needs`: the plugin doesn't ship in the image, and blocking the build wouldn't un-publish a bad hook — the push already did. A failed job still reddens the run. Closes #2204 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs
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. Toggle in Settings → Knowledge auto-inject.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.