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>
1.5 KiB
1.5 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| verification | Use before claiming a task is done or a change works — confirm it actually does, then record that you did. Triggers when you're about to report completion, mark a task done, or say "it works" / "fixed". Guards against declaring success on unverified work. |
|
Verification before completion
"Done" means verified, not "written." Before you claim a change works or set a
task done, confirm it against reality and record what you checked.
Verify against reality
- Exercise the actual behavior — run it, test it, observe the output. Prefer the real path over "it should work by inspection."
- Check the thing the user actually asked for, not a proxy for it.
- If you can't verify something (no environment, needs hardware, needs the operator), say so explicitly — name what's unverified rather than letting it read as passed.
Record the result, then close
- Log what you verified, and how, to the task with
add_task_log— the check is part of the record, not a private step. - Only then set the task
done. Never mark finished work you haven't confirmed, and never leave confirmed work sitting atin_progress. - If verification surfaced a problem, capture it as its own issue
(
create_task(kind="issue")) and keep the task open — a found problem is a pivot to record, not something to quietly skip.
Honesty over optimism
A truthful "verified X; could not verify Y" is worth more than a confident
"done." The record is only useful if done reliably means done.