bvandeusenandClaude Opus 5.5
f1fdc4a951
Loading a procedure now also reaches the moment it is for. Loading the reporting procedure is a report; loading the release procedure is a delivery. - Bundled skills: each SKILL.md declares `metadata: moments:`. The same declaration ships as Skill defaults (BUNDLED_SKILL_MOMENTS), because the server never sees the plugin's files. test_skill_moments holds the two together and pins the plugin name that qualifies the skill. - Stored processes: `moments` on create_process and update_process, stored in the note's data and returned by get_process. A `scribe-proc-<slug>` load resolves its process through the sync manifest at load time. The moments are not copied into the stub, which would go stale mid-session. - reachable_tools lists the skill loader whenever anything is mounted, since a process's moments are known only when it loads. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2.1 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| systematic-debugging | Use when diagnosing a bug, failure, or unexpected behavior — investigate methodically instead of guessing. Triggers on "why is this failing/breaking", a stack trace, a flaky test, or any "it should work but doesn't". On resolution, capture the issue in Scribe so it isn't re-debugged from scratch. |
|
Systematic debugging
Find the root cause, don't patch the symptom. Move one step at a time — a guessed fix that "seems to work" often just moves the bug somewhere else.
Recall first
Before digging in, search Scribe for the symptom — a prior issue
(list_tasks(kind="issue") or search) may already hold the cause and the fix.
Don't re-debug what's already solved.
The loop
- Reproduce — get a reliable, minimal repro. If you can't reproduce it, you can't confirm you fixed it.
- Observe — read the actual error / log / state. Don't theorize past the data you have.
- Isolate — narrow to the smallest failing case; change one variable at a time so each result actually means something.
- Hypothesize → test — state the single most likely cause, then test that one thing. Confirm or rule it out before moving on; don't stack guesses.
- Root cause — keep going until you can explain why it failed, not just what made it stop. "It works now" without "because X" is unfinished.
- Fix + verify — fix the cause, then re-run the repro to confirm it's gone.
Capture the issue (so it's findable)
When resolved, record it in Scribe as its own issue (create_task(kind="issue")):
symptom → root cause → fix → how it was verified in the body, optionally
linked to the task it arose from (arose_from_id) and the subsystem it touches
(system_ids). Even a problem fixed in passing is worth two lines — that's how
the next person (or you) avoids re-deriving it. Record it discretely; don't bury
it as a work-log line on an unrelated open task. If the work was already tracked
as its own task, log the resolution there and set it done.