---
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.