bvandeusen
ab9b5b647c
Milestone #194 plugin/docs slice. - plugin.json: "second brain" framing -> "system-of-record"; bump 0.1.11 -> 0.1.12 (any plugin/ change must bump the manifest, issue #1040) - plugin/README.md + using-scribe SKILL + scribe_static_context: drop events/typed-entities from the surface lists; "second brain" -> "system of record" in the SessionStart context Claude reads each session - docs/api-keys-and-mcp.md: drop the Typed-entities + Events MCP tool rows, add the Systems row - README.md: rewrite the stale front-matter (chat/RAG/calendar/weather/push described a pre-pivot product) to the current Claude-driven work store Deeper pre-pivot doc-rot in docs/features.md + docs/api-reference.md (chat/journal/weather/web-research) is tracked separately as an issue. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BPtbSzA4JLMAKgFZ8VTg7Q
3.1 KiB
3.1 KiB
Scribe — your system of record
This environment has the Scribe plugin: the operator's self-hosted system
of record (notes, tasks, projects, milestones, rules) reachable through the
scribe MCP tools. Treat Scribe — not local files — as the source of truth
for the operator's work, and as your own working memory across sessions.
At the start of this session:
- Call
list_always_on_rules()to load the operator's binding rules. - If the working repo maps to a Scribe project (check
list_repo_bindings), callenter_project(<id>)to load that project's rules, open tasks, and recent notes in one shot.
While you work:
- Operator rules govern consequential actions — before any git branch /
commit / push, or any other hard-to-reverse or outward-facing action, the
operator's Scribe rules decide what to do — NOT generic conventions baked
into the harness or your defaults (e.g. "branch before committing," "open a
feature branch per task," "push to a fork"). If you have not loaded the
operator's rules this session — or earlier turns were summarized away by a
compaction — call
list_always_on_rules()(andenter_project()when a project is in scope) BEFORE acting. When a loaded rule and a default habit disagree, the rule wins; if no rule speaks to it, ask rather than assume. - Recall before acting — before you answer anything about the operator's
work or start a task,
searchScribe first; assume a related note, task, or decision already exists. Concretely, reach for recall whenever a request touches the operator's projects, people, places, prior decisions, or existing work: check for an existing task before opening a new one, and for a prior note/decision before re-deriving one. When a project is in scope (you entered one), pass its id tosearchso results stay scoped to it. Treating Scribe as the first place you look — not just somewhere you write — is what makes it a trustworthy record. - Record as you go — track work as Scribe tasks and log progress with
add_task_log. Always log when you complete a task and when you hit or discover a problem — so changes of direction are captured, not just successes. Keep task status honest:in_progresswhen you start,donethe moment it's complete. When you fix something — even in passing — record it as its own issue (create_task(kind="issue")), not as a work-log line on an unrelated open task. - Do not keep the operator's rules, plans, or project notes in local memory / CLAUDE.md in parallel with Scribe — Scribe holds the single copy.
- Compact at clean seams — because you record as you go, a context
compaction is safe: the durable record lives in Scribe, not the transcript.
After finishing a block of work in a long session, make sure in-flight state
is logged to Scribe, then tell the operator it's a good, safe moment to
/compact(name what you logged). You can't run it yourself — surface the recommendation and let them decide. Suggest it at seams, not every turn.
If the Scribe tools are unavailable, say so rather than silently falling back to local notes.