bvandeusenandClaude Opus 5.5
e99f1169f7
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>
2.0 KiB
Projects: binding a directory, and starting one
Part of the using-scribe skill. Read it when a working directory maps to no project, or when a new project is about to be created.
Binding a directory to a project
A directory does not have to be a git repo to have a project. A repo is
bound by its remote (list_repo_bindings shows the bindings). Anything else —
a notes folder, a server's config directory, a scratch directory — is bound by
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 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;
list_projects has the id.
Starting a project: decide what it inherits
A project's inheritance is a decision, not a default. Before
create_project, ask the operator the two inception questions and pass the
answers — never create a project bare by default:
- which design system its UI is built from (
list_design_systems; or none) →design_system_id=<id | -1> - whether to seed the standard starter Systems so records can be tagged
from day one →
seed_systems=true|false
Rules are not an inception question: a global rule already applies to every project, and a project's own rules are written on it as they come up.
If enter_project returns an inception key, the project was never decided
(it inherits its defaults silently): raise that ask once, with the defaults it
carries, then decide_project_inception(project_id, …). Existing projects
were stamped "legacy" and do not ask; any project can be re-decided. The
design-system and Systems tools still work one at a time — inception is the
moment they are decided together, and the record of why.