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>
57 lines
3.0 KiB
Markdown
57 lines
3.0 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.
|
|
|
|
## 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.
|
|
|
|
## 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.
|