bvandeusen
f2ab02ba2b
Plain-language 'related prior work' instead of 'prior art'; replace the dev-shaped 'meaningful landing (a merge, a shipped feature, a finished plan)' with concrete neutral triggers — log on task completion and when a problem is found, so direction pivots are captured, not just successes. Keeps the static mandate domain-neutral (pre-empts B9 drift in plan 812). Refs task 809 / plan 812 item A1. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.4 KiB
1.4 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 —
searchScribe for related prior work before answering a question about the operator's work, starting a task, or re-deriving a decision. Assume a related note, task, or decision already exists. - 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. - 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.
If the Scribe tools are unavailable, say so rather than silently falling back to local notes.