bvandeusen
9eddb8497c
Direction change (operator, see plan task #755 work-log): the plugin must NOT depend on disabling a native Claude function to work. It earns its place by steering behavior, not by toggling autoMemoryEnabled. Memory doctrine (no dual-write): - using-scribe SKILL.md gains "Scribe holds these functions — don't keep a second copy": route rules/recall/planning to Scribe, don't also write them to native auto-memory, never instruct disabling a native function, and accept a "Scribe-shaped hole" if the plugin is removed (recover over time). - mcp/server.py _INSTRUCTIONS: drop the paragraph that told the model to create/refresh a "rules live in Scribe" pointer in CLAUDE.md / ~/.claude memory. That was an active dual-write instruction; the SessionStart hook is the bridge now. Replaced with the no-dual-write / no-settings-dependency doctrine. Supersedes plan #755 Phase 6 ("set autoMemoryEnabled:false"). Project-scope discipline (stop cross-project bleed): - using-scribe SKILL.md gains "Stay inside the active project's scope": pass project_id to every read, only reference/offer work on the in-scope project, ask before switching. - _INSTRUCTIONS scope bullet extended from reads to referencing/offering, and flags get_recent as cross-project. - get_recent docstring gains a scope note steering to scoped list_* when a project is active. plugin.json 0.1.4 -> 0.1.5 so clients' caches actually refresh (re-shipping under the same version does not bust the cache). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
113 lines
5.9 KiB
Markdown
113 lines
5.9 KiB
Markdown
---
|
|
name: using-scribe
|
|
description: Use at the START of every session, and before answering anything about the operator's work or starting any task — establishes the Scribe-first reflex. FIRST ACTION of a session: call list_always_on_rules() (and enter_project when a repo/project is in scope) to load the operator's binding rules. Then recall before acting, update over duplicate, plan in Scribe not in files.
|
|
---
|
|
|
|
# Using Scribe
|
|
|
|
Scribe is the operator's self-hosted second brain (notes, tasks, projects,
|
|
milestones, events, typed entities) and rulebook, reachable through the bundled
|
|
`scribe` MCP server. Its value is mostly in what it **already holds** — so make
|
|
reading it a reflex, not something you wait to be asked for.
|
|
|
|
## Do this first (every session)
|
|
|
|
**Pull the standing rules yourself — do not wait for them to be handed to you.**
|
|
At the start of a session, before substantive work, call
|
|
`list_always_on_rules()` to load the operator's always-on rules. If the working
|
|
repo maps to a Scribe project (you're in a known repo, or `list_repo_bindings`
|
|
shows a binding), call `enter_project(id)` instead/as-well — it returns the
|
|
project plus its applicable rules, open tasks, and recent notes in one shot.
|
|
|
|
Do this actively. A SessionStart hook *may* also inject a rule index, but treat
|
|
that as a bonus, not a precondition: it can be absent (e.g. when the instance is
|
|
unreachable, or the token didn't reach the hook), so the reliable path is this
|
|
explicit pull. Rules loaded this way are **binding** for the session.
|
|
|
|
## Scribe holds these functions — don't keep a second copy
|
|
|
|
This plugin makes Scribe the home for the operator's **rules, recall, and
|
|
planning** — the jobs Claude's native auto-memory would otherwise do. When the
|
|
plugin is present, route those jobs to Scribe and **do not also write them to
|
|
native memory**: codify rules with `create_rule` / `create_project_rule`,
|
|
capture durable knowledge as Scribe notes, and keep plans in `kind=plan` tasks —
|
|
not in `MEMORY.md` or `CLAUDE.md`. One copy, in Scribe; let any existing local
|
|
memory shrink as Scribe takes over. Don't maintain both stores in parallel.
|
|
|
|
Two constraints on *how* that's achieved:
|
|
|
|
- **Steer behavior; never flip a native switch.** The plugin must work with
|
|
native auto-memory at its default (ON). Never tell the operator to set
|
|
`autoMemoryEnabled:false` or otherwise disable a built-in function to make
|
|
Scribe "win" — a setting the operator may not know was changed (and wouldn't
|
|
know to restore) is exactly the hidden breakage to avoid. You replace memory's
|
|
functions by *doing the work in Scribe*, not by turning memory off.
|
|
- **A Scribe-shaped hole is acceptable.** If the plugin is later removed, the
|
|
operator recovers context over time — that's fine. You do **not** need to keep
|
|
native memory as a self-sufficient fallback. The only thing to avoid is
|
|
breakage caused by a settings change the operator didn't make knowingly.
|
|
|
|
## The reflex
|
|
|
|
1. **Recall before acting.** Before answering a question about the operator's
|
|
work, or starting a task, `search` Scribe (and `list_tasks` / `list_notes`)
|
|
for prior art — an existing ticket, decision, or dev-log — instead of
|
|
re-deriving it or opening a duplicate. When a project is in scope, pass its
|
|
`project_id` so results stay scoped.
|
|
|
|
2. **Standing rules are binding.** Load them via `list_always_on_rules()` at
|
|
session start (see "Do this first"); treat every one as binding. Pull a
|
|
rule's full statement with `get_rule(id)` when it's about to bite. When a
|
|
project is in scope, `enter_project(id)` also returns its applicable rules.
|
|
|
|
3. **Update over duplicate.** When recording, prefer updating an existing
|
|
note/rule/task over creating a new one. Search first; revise what's there.
|
|
|
|
4. **Plans live in Scribe.** For non-trivial work call `start_planning(project_id,
|
|
title)` FIRST — the plan body + step checklist live in the `kind=plan` task,
|
|
progress goes in work-logs (`add_task_log`). Do not write plans/specs to local
|
|
`.md` files.
|
|
|
|
5. **Keep state honest.** Set a task `in_progress` when you start it, `done` the
|
|
moment it's complete; log progress as you go.
|
|
|
|
## Stay inside the active project's scope
|
|
|
|
Once a project is in scope — you called `enter_project`, or the working repo is
|
|
bound — confine the session to it:
|
|
|
|
- **Pass that `project_id` to every read** (`search`, `list_tasks`,
|
|
`list_notes`). An unscoped read bleeds every other project's work into your
|
|
context.
|
|
- **Only reference or offer work on the in-scope project.** Don't surface,
|
|
suggest, or start work on other projects unless the operator explicitly widens
|
|
scope.
|
|
- If something clearly belongs to a *different* project, say so and **ask before
|
|
switching** — never silently operate cross-project.
|
|
|
|
## Where a new rule goes
|
|
|
|
When codifying a rule, pick its home by **who it should bind** — and keep
|
|
shared homes general:
|
|
|
|
- **Always-on rulebook** (`create_rule` in an `always_on` rulebook) — universal
|
|
norms that bind *every* project. Cross-project standards only.
|
|
- **Subscribed rulebook** (`create_rule` + `subscribe_project_to_rulebook`) — a
|
|
reusable, *themed* module of general rules that binds only projects that opt
|
|
in (e.g. a design system → visual apps). Themed, but still project-agnostic.
|
|
- **Project rule** (`create_project_rule`) — anything specific to one project
|
|
(its files, paths, quirks).
|
|
|
|
Both rulebook tiers are shared, so their rules stay general; they differ in
|
|
**reach** (all vs opt-in), not generality. Names one project's specifics →
|
|
project rule; a standard a category shares → subscribed rulebook; a universal
|
|
norm → always-on rulebook. Never put project-specific detail in a shared
|
|
rulebook — it leaks to every other project that gets it.
|
|
|
|
## Other Scribe process-skills
|
|
|
|
This plugin also ships focused process-skills — brainstorming, systematic
|
|
debugging, test-driven development, writing-plans, verification, receiving code
|
|
review. Reach for the matching one when its situation arises, the same way you
|
|
reach for this skill.
|