Files
FabledScribe/plugin/skills/verification/SKILL.md
T
bvandeusen 88106309f4
CI & Build / Python lint (push) Successful in 2s
CI & Build / TypeScript typecheck (push) Successful in 34s
CI & Build / Python tests (push) Successful in 49s
CI & Build / Build & push image (push) Successful in 1m12s
feat(plugin): add 4 Scribe-native process-skills (restore superpowers gap)
Superpowers was uninstalled but its replacements were never built (only
using-scribe shipped) — a live functional hole. Author the 4 the operator
wants back, each integrated with Scribe's toolset rather than generic copies:
- writing-plans     -> start_planning / kind=plan task, not local .md
- systematic-debugging -> capture issue (symptom->cause->fix, tag issue) on resolve
- verification      -> log results to the task work-log; honest done
- brainstorming     -> recall prior thinking first; capture the decision note

Skipped TDD + receiving-code-review per operator (well-covered by Claude/them).
Manifest + using-scribe list now advertise only the 4 that ship. Remove the
stale docs/superpowers/*.md reference in _INSTRUCTIONS (superpowers is gone).
Plugin 0.1.6 -> 0.1.7.

Refs plan 821 (Phase 3 of 755).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-13 20:52:34 -04:00

1.5 KiB

name, description
name description
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 at in_progress.
  • If verification surfaced a problem, capture it (tag 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.