CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 12s
CI & Build / TypeScript typecheck (push) Successful in 52s
CI & Build / integration (push) Successful in 1m1s
CI & Build / Python tests (push) Successful in 1m55s
CI & Build / Build & push image (push) Successful in 36s
Step 1 of the Scribe -> Grimoire rename: every capitalised "Scribe" in prose
becomes "Grimoire" ("Fabled Scribe" -> "Fabled Grimoire") across the UI,
the PWA manifest and page title, the MCP instructions and tool docstrings,
hook and skill text, docs and README, with the tests that assert on that
prose moving with it. Old migrations keep their wording.
Identifiers are untouched here: the package, plugin name, MCP server key,
hook file names, env vars, the .scribe marker and FabledScribe repo/image
names move in steps 2 and 3, along with prose that quotes them.
The sweep matched "Scribe" only as a whole word, so describe/subscribe and
friends are untouched. The longer name took the MCP instructions one
character over their 1,600 budget; two phrases are shortened to fit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
7.8 KiB
7.8 KiB
Packaging Grimoire for an agent client
This is the maintainer contract for shipping Grimoire into an agent client: what every client package shares, what each one adds, and where a new client's files go. One principle governs it: the server orients, the skills hold the depth, and a client adapter only times delivery and says what that one client needs said.
Claude Code is the only client built today. The layout below is kept so adding another one means adding files, not moving or rewriting any.
Shared by every client package
| Piece | Where | What it is |
|---|---|---|
| The skills | plugin/skills/*/SKILL.md |
Agent Skills (the open SKILL.md format). They state every Grimoire reflex in full and name no client. tests/test_guidance_ownership.py fails if a skill names a particular client, or references anything outside its own folder. Every client package ships this folder verbatim. |
| The MCP server | <base URL>/mcp |
HTTP, Authorization: Bearer <fmcp_ key>. Its _INSTRUCTIONS is a client-neutral orientation — the workflow across tools (≤1,600 chars); each tool's description carries its contract; in-band responses (placement, report_back, systems_hint, the duplicate gate, the guessed-id refusal) fire in every client. |
| The adapter API | <base URL>/api/plugin/* |
Endpoints any client's hooks can call with the same key. GET, so read scope is enough: context (live session state), retrieve (rules, preferences and notes for a message), prior-art (records and shape-ledger hints for code being written), tool-rules (rules for a command about to run), moment-tools (which tools reach a mounted moment), shape-check (definitions written this turn that nobody has judged), claim-session / release-session (task claims), processes (stored Processes to expose as skills). POST, so write scope: moment (rules mounted on the moments a tool call reaches), rule-opened (a rule was read), reply-rules (the finished reply, held for an unopened rule or — when the turn closed a task — for missing completion sections). |
| The API key | Grimoire → Settings → MCP Access | One fmcp_ key per install. Write scope covers the MCP tools and every hook; a read key runs only the GET hooks. |
Added by each client
| Piece | What it holds | Rule of thumb |
|---|---|---|
| A manifest | Name, version, how to reach the MCP server with the key, where the skills and hooks are | Only that client's format. |
| Hooks | Scripts in that client's hook format that call the adapter API at the right moment and print what comes back | Timing and transport only. A hook may print status lines (unconfigured, unreachable, running version) and pointers; guidance text comes from the server or the adapter's own static text. |
| Commands | That client's command wrappers, e.g. a process sync | Optional. |
| Adapter static text | What only that client needs said: its local memory files, its compaction command, its commands | Never a copy of a skill or of _INSTRUCTIONS. The loss guard and ownership registry in tests/test_guidance_ownership.py cover it. |
The worked example: Claude Code
| File | Role |
|---|---|
.claude-plugin/plugin.json |
Manifest: mcpServers.scribe (HTTP, Authorization: Bearer ${user_config.api_token}), userConfig for the base URL and key, version (minted, never hand-edited; see README). |
../.claude-plugin/marketplace.json (repo root) |
The marketplace entry pointing at ./plugin. |
hooks/hooks.json |
Wires the scripts to Claude Code events. |
hooks/scribe_session_context.sh |
SessionStart: adapter static text + running version + GET /api/plugin/context; a reload banner after compaction. |
hooks/scribe_autoinject.sh |
UserPromptSubmit: GET /api/plugin/retrieve for the message. |
hooks/scribe_prior_art.sh |
PreToolUse on editor writes: GET /api/plugin/prior-art. |
hooks/scribe_after_write.sh |
PostToolUse on shell commands: the same check for code written through the shell. |
hooks/scribe_tool_rules.sh |
PreToolUse on shell commands: GET /api/plugin/tool-rules. |
hooks/scribe_moment.sh |
PreToolUse on every tool: the rules mounted on the moments the call reaches, POST /api/plugin/moment; skips tools GET /api/plugin/moment-tools says reach nothing mounted, and Grimoire's own (their responses carry moment_rules). |
hooks/scribe_reply_check.sh |
Stop: sends the finished reply to POST /api/plugin/reply-rules — the rules mounted on the reply moments, and the reply against every rule's trigger, and — when the turn closed a task — the completion-section check; holds once per rule, with the reason the server returns, and never holds the rewrite. |
hooks/scribe_shape_check.sh |
Stop: sends the definitions the turn wrote (the write hooks' <sid>.written.ids ledger) to GET /api/plugin/shape-check; blocks once, with the reason the server returns, so the agent judges what it built. |
hooks/scribe_record_opened.sh |
PostToolUse on get_rule: notes the rule as read in the session ledger and POST /api/plugin/rule-opened. |
hooks/scribe_record_outcome.sh |
PostToolUse on rule_outcome: notes the rule as acted on, locally, for the session-scoped readout. |
hooks/scribe_claim_session.sh |
PostToolUse on update_task / add_task_log: GET /api/plugin/claim-session, so the task comes back after a compaction. |
hooks/scribe_precompact_preserve.sh |
PreCompact: tells the summarizer what to keep literally. Local, and never blocks. |
hooks/scribe_session_end.sh |
SessionEnd: GET /api/plugin/release-session releases the session's claims. |
hooks/scribe_sync_processes.sh + commands/sync.md |
GET /api/plugin/processes → ~/.claude/skills/scribe-proc-* stubs; /scribe:sync on demand. |
hooks/scribe_defs.sh |
Shared shell helpers: config, dedup ledgers, outage line. |
hooks/scribe_static_context.md |
The adapter static text. |
Hook config arrives as CLAUDE_PLUGIN_OPTION_API_ENDPOINT / CLAUDE_PLUGIN_OPTION_API_TOKEN (uppercased by Claude Code), with SCRIBE_URL / SCRIBE_TOKEN as an override.
How other clients would map
Researched, not tested. Re-check each client's current docs before building.
- Agent Plugins 1.0 (Codex, Cursor, GitHub Copilot / VS Code, Kiro, ChatGPT): a root
plugin.json, askills/folder, and anmcp.json. That is the sameplugin/skills/plus two small files. Hooks, commands and rules are not part of v1; each client adds its own under a reverse-domain directory (e.g.com.<client>/) that other clients ignore. - Gemini CLI:
gemini-extension.jsonconfiguring the MCP server, a context file, and bundled skills. - Client-native formats also exist (
.codex-plugin/,.cursor-plugin/) where a client wants more than the shared standard carries. - Claude Code does not read Agent Plugins: only
.claude-plugin/plugin.json.
Open questions for whoever builds the second package
- Passing the key to the MCP server. Claude Code substitutes
${user_config.api_token}into the header. Agent Plugins'mcp.jsonand Gemini's extension config have their own variable and secret handling. Decide per client, and keep the key out of files that get committed. - Coexistence in one folder. Whether a root
plugin.json(Agent Plugins) beside.claude-plugin/plugin.jsonchanges how Claude Code loads the plugin is untested. Test it before shipping both fromplugin/, or give the second client its own package directory that reusesplugin/skills/. - Hook parity. Other clients' hook events differ and are partly implemented. Map each Grimoire hook to the nearest event, and where none exists, leave that timing to the in-band server responses rather than writing a copy of the guidance.
- Process skills. The Claude Code sync writes
~/.claude/skills. Another client needs its own skills location, or the MCP skills extension (SEP-2640) once a client supports it.