rename(547): what people read says Grimoire

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>

plugin/skills/brainstorming/SKILL.md

@@ -12,7 +12,7 @@ real options and a reasoned choice — not a single path defended after the fact
 
 ## Recall first
 
-`search` Scribe before generating from scratch — a prior decision, note, or
+`search` Grimoire before generating from scratch — a prior decision, note, or
 brainstorm on this often already exists. Build on it instead of repeating it.
 
 ## Open up
@@ -30,7 +30,7 @@ brainstorm on this often already exists. Build on it instead of repeating it.
 
 ## Capture the decision
 
-When a direction is chosen, record it in Scribe (`create_note`, e.g. tag
+When a direction is chosen, record it in Grimoire (`create_note`, e.g. tag
 `decision`): the choice, the alternatives weighed, and the reason. That's what
 keeps the same question from being re-litigated later — and what a future
 session reads to understand *why*, not just *what*.

plugin/skills/reporting-back/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: reporting-back
-description: Use when you are about to write the reply the operator will read and the delivered reply shape is not enough — work finished, stopping on a blocker, asking them to decide or to do something, answering "where are we", or proposing an approach. The long-form reference behind the reply shapes Scribe delivers: why sections are chosen rather than filled, who decides what, taking placement from the record, and a completion report worked in full. Triggers on reporting completion, handing off, asking a question, or summarising progress.
+description: Use when you are about to write the reply the operator will read and the delivered reply shape is not enough — work finished, stopping on a blocker, asking them to decide or to do something, answering "where are we", or proposing an approach. The long-form reference behind the reply shapes Grimoire delivers: why sections are chosen rather than filled, who decides what, taking placement from the record, and a completion report worked in full. Triggers on reporting completion, handing off, asking a question, or summarising progress.
 metadata:
   moments: reply.report
 ---
@@ -14,7 +14,7 @@ still unreadable to them. Shape it around **where the work stands**.
 
 ## The shapes arrive on their own
 
-Scribe delivers the default shape for each kind of reply as product, at the
+Grimoire delivers the default shape for each kind of reply as product, at the
 moment it is due: the core ("Reply shape · Every reply") with each turn, the
 completion report when a task closes, the asks when you put a question to the
 operator, the plan when you plan. A shape this session has already seen comes
@@ -61,7 +61,7 @@ and it costs the operator the decision twice.
 ## Take the placement from the record
 
 A remembered milestone title or "next step" reads exactly like a real one when
-it is wrong. So take placement from Scribe:
+it is wrong. So take placement from Grimoire:
 
 - `update_task` and `create_task` return a **`placement`** block — the project,
   the milestone, `position` (step N of M), `progress`, and `next` (the next open

plugin/skills/reusing-code/SKILL.md

@@ -41,7 +41,7 @@ through recall/auto-inject; this skill is the active reflex around that.
   turn's shapes — reuse from memory leaves no such evidence.
 - If auto-inject already surfaced a snippet title that looks relevant, that's
   your cue to `get_snippet` it rather than start from scratch.
-- **Prior art offered beside a write is not noise — read it.** When Scribe notes
+- **Prior art offered beside a write is not noise — read it.** When Grimoire notes
   that a snippet is already recorded for the file you just wrote or edited, open
   it before you go any further. Either it's the helper you were about to
   duplicate — reuse it and drop yours — or it isn't, and the record needs the new
@@ -59,7 +59,7 @@ through recall/auto-inject; this skill is the active reflex around that.
   YOUR edit's responsibility: if the edit changes the recorded shape,
   `update_snippet(id, code=…)` with the new form as part of the same task; if
   it doesn't, `verify_snippet(id, status="ok", commit_sha=…)` costs one call
-  and re-stamps the record as checked. Scribe never reads the repo — this
+  and re-stamps the record as checked. Grimoire never reads the repo — this
   moment, in the session that has the context, is the only place the record
   gets kept true.
 
@@ -115,7 +115,7 @@ shape is asked about once.
 
 ## A shared snippet is a suggestion, not a standard
 
-Scribe is multi-user, so a search can return snippets other people own. Those
+Grimoire is multi-user, so a search can return snippets other people own. Those
 come back marked `shared: true` with an `owner`.
 
 - Read one as **that person's suggestion**, not as the way things are done here.

plugin/skills/systematic-debugging/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: systematic-debugging
-description: Use when diagnosing a bug, failure, or unexpected behavior — investigate methodically instead of guessing. Triggers on "why is this failing/breaking", a stack trace, a flaky test, or any "it should work but doesn't". On resolution, capture the issue in Scribe so it isn't re-debugged from scratch.
+description: Use when diagnosing a bug, failure, or unexpected behavior — investigate methodically instead of guessing. Triggers on "why is this failing/breaking", a stack trace, a flaky test, or any "it should work but doesn't". On resolution, capture the issue in Grimoire so it isn't re-debugged from scratch.
 metadata:
   moments: work.debug
 ---
@@ -12,7 +12,7 @@ guessed fix that "seems to work" often just moves the bug somewhere else.
 
 ## Recall first
 
-Before digging in, `search` Scribe for the symptom — a prior issue
+Before digging in, `search` Grimoire for the symptom — a prior issue
 (`list_tasks(kind="issue")` or `search`) may already hold the cause and the fix.
 Don't re-debug what's already solved.
 
@@ -32,7 +32,7 @@ Don't re-debug what's already solved.
 
 ## Capture the issue (so it's findable)
 
-When resolved, record it in Scribe as its own issue (`create_task(kind="issue")`):
+When resolved, record it in Grimoire as its own issue (`create_task(kind="issue")`):
 **symptom → root cause → fix → how it was verified** in the body, optionally
 linked to the task it arose from (`arose_from_id`) and the subsystem it touches
 (`system_ids`). Even a problem fixed in passing is worth two lines — that's how

plugin/skills/using-scribe/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: using-scribe
-description: Use at the START of every session, and before answering anything about the operator's work or starting any task — establishes the Scribe-first reflex. You hold none of the operator's rules: they arrive by retrieval when your work matches one, and what_might_apply is how you ask before a consequential act — it returns the wide net of candidates with no bar. Call enter_project when a repo/project is in scope. Then recall before acting, update over duplicate, plan in Scribe not in files.
+description: Use at the START of every session, and before answering anything about the operator's work or starting any task — establishes the Grimoire-first reflex. You hold none of the operator's rules: they arrive by retrieval when your work matches one, and what_might_apply is how you ask before a consequential act — it returns the wide net of candidates with no bar. Call enter_project when a repo/project is in scope. Then recall before acting, update over duplicate, plan in Grimoire not in files.
 metadata:
   moments: session.start
 ---
 
-# Using Scribe
+# Using Grimoire
 
-Scribe is the operator's self-hosted system of record (notes, tasks, issues,
+Grimoire is the operator's self-hosted system of record (notes, tasks, issues,
 projects, milestones, systems) and rulebook, reachable
 through the bundled `scribe` MCP server. Its value is mostly in what it
 **already holds** — so make reading it a reflex, not something you wait to be
@@ -15,7 +15,7 @@ asked for.
 
 ## Do this first (every session)
 
-If the working directory maps to a Scribe project, call `enter_project(id)` —
+If the working directory maps to a Grimoire project, call `enter_project(id)` —
 it returns the project's goal, the milestones and open tasks worked on most
 recently, its Systems and the titles of its own rules in one shot.
 
@@ -26,30 +26,30 @@ 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
+## Grimoire holds these functions — keep one copy
 
-Scribe is the home for the operator's **rules, recall, and planning** — the
+Grimoire is the home for the operator's **rules, recall, and planning** — the
 jobs your client's own local memory files would otherwise do. Route those jobs
-to Scribe instead of also writing them locally: codify rules with
-`create_rule` / `create_project_rule`, capture durable knowledge as Scribe
-notes, and keep plans in Scribe milestones (via `start_planning`). One copy, in
-Scribe; let any existing local memory shrink as Scribe takes over.
+to Grimoire instead of also writing them locally: codify rules with
+`create_rule` / `create_project_rule`, capture durable knowledge as Grimoire
+notes, and keep plans in Grimoire milestones (via `start_planning`). One copy, in
+Grimoire; let any existing local memory shrink as Grimoire takes over.
 
 Two constraints on *how* that's achieved:
 
-- **Steer behaviour; leave the client's own settings as they are.** Scribe works
+- **Steer behaviour; leave the client's own settings as they are.** Grimoire works
   alongside a client's built-in memory at its defaults. You replace memory's
-  functions by *doing the work in Scribe*, so there is no reason to ask the
+  functions by *doing the work in Grimoire*, so there is no reason to ask the
   operator to switch a built-in feature off — a setting they didn't knowingly
   change is breakage they won't know to restore.
-- **A Scribe-shaped hole is acceptable.** If Scribe is later removed, the
+- **A Grimoire-shaped hole is acceptable.** If Grimoire is later removed, the
   operator recovers context over time — that's fine. Local memory doesn't need
   to be kept as a self-sufficient fallback.
 
 ## The reflex
 
 1. **Recall before acting.** Before answering a question about the operator's
-   work, or starting a task, `search` Scribe (and `list_tasks` / `list_notes`)
+   work, or starting a task, `search` Grimoire (and `list_tasks` / `list_notes`)
    for related prior work — an existing task, decision, or note — instead of
    re-deriving it or opening a duplicate. When a project is in scope, pass its
    `project_id` so results stay scoped.
@@ -129,7 +129,7 @@ Two constraints on *how* that's achieved:
 
    **Preferences shape how work is done, never what gets recorded.** They
    govern your conduct — how you report, how carefully you pace, which form
-   you reach for. What ends up in Scribe is decided by what the record is:
+   you reach for. What ends up in Grimoire is decided by what the record is:
    a preference never makes a task into a note, downgrades a rule, or keeps
    something out of the corpus that belongs there.
 
@@ -151,7 +151,7 @@ Two constraints on *how* that's achieved:
 3. **Update over duplicate.** When recording, prefer updating an existing
    note/rule/task over creating a new one. Search first; revise what's there.
 
-4. **When you plan, plan in Scribe.** Work with an *arc* — several steps toward
+4. **When you plan, plan in Grimoire.** Work with an *arc* — several steps toward
    one goal — gets a plan, and a plan is a milestone: `start_planning(project_id,
    title)` creates one whose `body` holds the design, each step is its own task
    under it (`create_task(milestone_id=...)`), progress goes in work-logs
@@ -174,7 +174,7 @@ Two constraints on *how* that's achieved:
    `/clear`, the operator wrapping up for the day — each is the last moment the
    reasoning behind the work lives anywhere but here. Log on the task you were
    holding where it stands, what you tried and ruled out, and the next move:
-   write down what the next session needs, because it arrives with Scribe's
+   write down what the next session needs, because it arrives with Grimoire's
    record and nothing else. Moving a task to `in_progress` or logging on it also
    claims it for this session — that claim is what hands the work back to you
    after a compaction, and it ends on its own when you stop, so there is nothing
@@ -211,14 +211,14 @@ Two constraints on *how* that's achieved:
    cover, and they plainly belong to that area, add them with `update_system`
    — which files are which area is your call, as naming the area was.
 
-8. **Name the record, never just its number.** Whenever you refer to a Scribe
+8. **Name the record, never just its number.** Whenever you refer to a Grimoire
    record — in a message to the operator, a commit message, a task body, a
    work-log — write the id *and* its title: `#3244 "the staleness signal"`,
    `milestone 323 "rule versioning"`. Not `#3244`.
 
    You have the record open; the operator does not. A bare id reads as
    complete to you and as homework to them — they have to look it up to know
-   what their own conversation is about, or guess. Scribe's own duplicate gate
+   what their own conversation is about, or guess. Grimoire's own duplicate gate
    already writes `id 412: "debounce helper"` for exactly this reason; match
    it everywhere else.
 
@@ -231,7 +231,7 @@ Two constraints on *how* that's achieved:
 
    **An id exists only once a create call returns it.** Never write the id you
    expect a record to get — every session and user draws from one sequence,
-   so the number goes to whoever creates next, and Scribe refuses a body that
+   so the number goes to whoever creates next, and Grimoire refuses a body that
    cites an id not yet assigned. Records that must cite each other are created
    together — `create_records` or `start_planning(steps=...)` — with
    `{{ref:N}}` where the Nth record's id belongs.
@@ -263,7 +263,7 @@ Two constraints on *how* that's achieved:
    order you did things in: which task or milestone it belongs to, what now
    works, what needs them, and what comes next. Take the placement from the
    `placement` block that `create_task` / `update_task` return — the milestone,
-   step N of M, the next open step — rather than from memory. Scribe delivers
+   step N of M, the next open step — rather than from memory. Grimoire delivers
    the shape for each kind of reply when it is due — the core with each turn,
    the completion report when a task closes, the asks when you put a question —
    and `list_reply_shapes` has them all; the `reporting-back` skill holds the
@@ -302,7 +302,7 @@ moment rather than on every turn:
 
 ## You are the judge of what the record says
 
-Scribe's shape exists to support how you work, so you are the judge of record
+Grimoire's shape exists to support how you work, so you are the judge of record
 for the work itself: what a shape is, which canon a thing belongs to, whether
 a finding holds, whether something is done. `classify_shapes`, `update_task`,
 `create_snippet` and the rest are where your judgment lands — under your own
@@ -342,8 +342,8 @@ token: `resolve_design_system(id)` for the values, or
 stated outside the system, so it can never follow a palette change — and
 nothing will tell you it drifted.
 
-## Other Scribe process-skills
+## Other Grimoire process-skills
 
-Scribe also ships focused process-skills — writing-plans, reporting-back,
+Grimoire also ships focused process-skills — writing-plans, reporting-back,
 systematic debugging, verification, and brainstorming. Reach for the matching one when its
 situation arises, the same way you reach for this skill.

plugin/skills/using-scribe/projects.md

@@ -13,7 +13,7 @@ a `.scribe` file naming the project:
     {"instance": "https://scribe.example.com", "project_id": 2, "project": "Homelab"}
 
 `instance` is what makes the id trustworthy. An id means nothing on its own —
-it is a different project on every Scribe — so a marker that has travelled to
+it is a different project on every Grimoire — so a marker that has travelled to
 another instance is ignored rather than followed to the wrong project. A bare
 `2` also works when writing the file by hand. When work plainly belongs to a
 project and the directory names none, offer to write the marker;

plugin/skills/using-scribe/writing-records.md

@@ -71,7 +71,7 @@ said twice at two strengths, which is worse than either alone: a session that
 retrieves the softer copy has been told that binding guidance is optional.
 
 **First ask whether it's a rule at all.** A rule is prose you have to remember
-and apply; Scribe's other entities are structure a tool can resolve and check.
+and apply; Grimoire's other entities are structure a tool can resolve and check.
 Visual standards belong in a **design system**, not a rulebook — a token can be
 inherited, resolved per mode, rendered to a stylesheet and diffed against code,
 and none of that survives being written as a rule. A repeatable procedure is a

plugin/skills/writing-plans/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: writing-plans
-description: Use when a piece of work has an arc — several steps toward one goal, worth tracking as a unit — and you want the approach reviewable before you start. Triggers when the user asks you to plan, design an approach, or scope an effort, or when work is about to sprawl across several steps. Not for single-step work. The plan lives in a Scribe milestone (via start_planning), not a local file.
+description: Use when a piece of work has an arc — several steps toward one goal, worth tracking as a unit — and you want the approach reviewable before you start. Triggers when the user asks you to plan, design an approach, or scope an effort, or when work is about to sprawl across several steps. Not for single-step work. The plan lives in a Grimoire milestone (via start_planning), not a local file.
 metadata:
   moments: work.plan
 ---
@@ -56,7 +56,7 @@ the project has the same title or reads as the same plan, they return it as
 `existing_milestone` and create nothing. Add to that plan, or pass `force=true`
 only when you have read it and this really is separate work.
 
-## When it does: start the plan in Scribe, not a file
+## When it does: start the plan in Grimoire, not a file
 
 Call **`start_planning(project_id, title)`** before designing or implementing —
 so the milestone exists to write into, rather than being backfilled from work
@@ -78,7 +78,7 @@ rules. The plan lives in that milestone:
 **Never write an id you have not been given.** A plan body that says "see
 #4012" before #4012 exists is a guess, and other sessions and users are
 creating records from the same sequence at the same time — the number goes to
-whoever creates next, and the plan then points at their record. Scribe refuses
+whoever creates next, and the plan then points at their record. Grimoire refuses
 a body citing an id that has not been assigned. Where the plan and its steps
 need to cite each other, write a placeholder instead: `{{ref:N}}` is the Nth
 step in the list, `{{ref:milestone}}` is the milestone. They are replaced with
@@ -88,7 +88,7 @@ the real id and title as the records are created.
 record, not a file on disk. A plan is never a task: `kind="plan"` is refused,
 and `start_planning` makes a milestone.
 
-Before designing from scratch, **recall**: `search` Scribe for a related prior
+Before designing from scratch, **recall**: `search` Grimoire for a related prior
 decision or note. Often the thinking (or half of it) already exists.
 
 ## What a good plan contains