bvandeusen
1983e8f4b1
The SessionStart push channel cannot reliably deliver a sensitive API token to the hook subprocess (upstream Claude Code bug anthropics/ claude-code#62442 — sensitive plugin userConfig is not persisted and is absent on a normal session). Stop depending on that push for standing rules: make the using-scribe bootstrap skill own the load instead. - description: name the FIRST ACTION (list_always_on_rules + enter_project when a repo/project is in scope) so it auto-surfaces at session start - add a 'Do this first' block instructing an active pull; demote the SessionStart hook to a bonus, not a precondition (it fail-opens and may be absent) - reflex step 2: rules come from list_always_on_rules(), not from an assumed SessionStart injection The hook + hooks.json are left in place: they fail-open and resume adding value automatically if #62442 is fixed or the token is made non-sensitive. Refs #755 (Phase 1: push channel descoped to optional; pull is load-bearing) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3.0 KiB
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.
The reflex
-
Recall before acting. Before answering a question about the operator's work, or starting a task,
searchScribe (andlist_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 itsproject_idso results stay scoped. -
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 withget_rule(id)when it's about to bite. When a project is in scope,enter_project(id)also returns its applicable rules. -
Update over duplicate. When recording, prefer updating an existing note/rule/task over creating a new one. Search first; revise what's there.
-
Plans live in Scribe. For non-trivial work call
start_planning(project_id, title)FIRST — the plan body + step checklist live in thekind=plantask, progress goes in work-logs (add_task_log). Do not write plans/specs to local.mdfiles. -
Keep state honest. Set a task
in_progresswhen you start it,donethe moment it's complete; log progress as you go.
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.