bvandeusenandClaude Opus 5.5
e99f1169f7
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>
42 lines
2.0 KiB
Markdown
42 lines
2.0 KiB
Markdown
# 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.
|