FabledScribe/plugin/skills/using-scribe/SKILL.md

---

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.

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.