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/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