eec241d3c0
Turn the SessionStart static guidance into a concrete recall trigger — search Scribe before answering about the operator projects/people/places/decisions or starting a task, and pass the active project id to scope results — instead of a vague "search for related work". Step 4 (pull-path sharpening); the cross-encoder rerank half is deferred until auto_inject telemetry shows precision is the bottleneck. Scribe: project 2, milestone 93, task 1034. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xz4j1H7pjYSjKsEpgcNH5E
2.5 KiB
2.5 KiB
Scribe — your second brain and system of record
This environment has the Scribe plugin: the operator's self-hosted second
brain (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:
- 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.