bvandeusen
5fbee18a94
CI & Build / Python lint (push) Successful in 3s
CI & Build / integration (push) Successful in 15s
CI & Build / TypeScript typecheck (push) Successful in 34s
CI & Build / Python tests (push) Successful in 46s
CI & Build / Build & push image (push) Successful in 1m3s
Plan #825 (T2 — Issues task_kind) shipped S1–S4 but its S5 docs slice never landed, so every behavioral surface the plugin pushes to the agent still described the pre-kind convention ("tag `issue`" on a create_note). Result: agents fixed bugs without reaching for kind=issue and dumped the work as logs on unrelated open tasks. - _INSTRUCTIONS: rewrite the "record a problem" bullet to create_task(kind="issue") with symptom→cause→fix + arose_from_id / system_ids, and an explicit "not a work-log on an unrelated task"; add Issue + System to the hierarchy section. - skills/systematic-debugging, verification: drop "tag `issue`" / create_note-issue, point at create_task(kind="issue"). - skills/using-scribe: add issues/systems to the entity list + reflex #6. - hooks/scribe_static_context: fix → its own issue on the keyless floor. Instance-agnostic, prose-only; no schema or tool-behavior change. Pairs with always-on rule #118. Issue: #855. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
34 lines
1.5 KiB
Markdown
34 lines
1.5 KiB
Markdown
---
|
|
name: verification
|
|
description: 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 at `in_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.
|