bvandeusenandClaude Opus 5.5
f1fdc4a951
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 13s
CI & Build / TypeScript typecheck (push) Successful in 55s
CI & Build / integration (push) Successful in 1m3s
CI & Build / Python tests (push) Failing after 1m25s
CI & Build / Build & push image (push) Skipped
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>
42 lines
2.1 KiB
Markdown
42 lines
2.1 KiB
Markdown
---
|
|
name: systematic-debugging
|
|
description: 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.
|
|
metadata:
|
|
moments: work.debug
|
|
---
|
|
|
|
# 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
|
|
|
|
1. **Reproduce** — get a reliable, minimal repro. If you can't reproduce it, you
|
|
can't confirm you fixed it.
|
|
2. **Observe** — read the actual error / log / state. Don't theorize past the
|
|
data you have.
|
|
3. **Isolate** — narrow to the smallest failing case; change one variable at a
|
|
time so each result actually means something.
|
|
4. **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.
|
|
5. **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.
|
|
6. **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`.
|