bvandeusenandClaude Opus 5.5
c5eeec471f
Step 3 of the Scribe -> Grimoire rename. - Plugin `grimoire` in marketplace `grimoire-plugin`, MCP server key `grimoire`, so tools reach a session as mcp__plugin_grimoire_grimoire__*. - hooks/scribe_* -> hooks/grimoire_*, their shell functions and the TMPDIR ledgers with them; SCRIBE_URL / SCRIBE_TOKEN / SCRIBE_HOOK_DIR / SCRIBE_LEDGER_DIRS -> GRIMOIRE_*; the project marker is `.grimoire`. - skills/using-scribe -> using-grimoire, /grimoire:sync, stored processes arrive as grimoire-proc-<slug>; moment_actions names them the same way. - Migration 0124 rewrites stored skill names (rule_moments, rule_moment_judgments, moment_mappings) from scribe:/scribe-proc- to grimoire:/grimoire-proc-, so a rule mounted on a skill keeps firing. - Settings' install commands and MCP-only defaults, the docs and the tests follow. - scripts/check_plugin.py drops the smoke event for a report-check hook that has no file in plugin/hooks. Kept on purpose: the secret-sealing label, and the names that let backups written as Scribe restore and be counted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2.0 KiB
Projects: binding a directory, and starting one
Part of the using-grimoire 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 .grimoire file naming the project:
{"instance": "https://grimoire.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.