Skill
delegation-triggers
Use when deciding whether to spawn subagents — explicit rules for when delegation pays off and when direct work is faster. Opus 4.8 under-delegates by default;…
@vitaliikapliukView SkillDevelopment
Skill
/verification-loop
Use when a task spans more than a few steps or files — establishes a checkable definition of done, a verification cadence, and fresh-context verifier subagents before claiming completion.
Install
$ npx -y skills add vitaliikapliuk/modelharness --skill verification-loop --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/verification-loop
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when a task spans more than a few steps or files — establishes a checkable definition of done, a verification cadence, and fresh-context verifier subagents before claiming completion.
SKILL.md
verification-loop.SKILL.mdname: verification-loop
description: Use when a task spans more than a few steps or files — establishes a checkable definition of done, a verification cadence, and fresh-context verifier subagents before claiming completion.
Verification Loop
Fable 5 builds its own checking harness on long tasks. Reproduce that explicitly.
1. Define "done" before starting
Write down (in your todo list or a scratch note) the binary checks that prove the task is complete: which tests must pass, which command must produce which output, which behavior must be observable. If the user's request doesn't define them, derive them and state them in one sentence.
2. Verify on a cadence, not at the end
After each meaningful increment (a function implemented, a module refactored), run the relevant real check immediately — the actual test command, the actual build. Never batch all verification to the end of a long task; errors compound.
3. Fresh-context verification before completion claims
Before declaring a substantial task complete, dispatch a verifier subagent (`modelharness:verifier` agent, or a general-purpose subagent given the `agents/verifier.md` instructions). Give it: the original specification, the definition-of-done checks, and the current diff (`git diff` output or changed file list). A fresh context catches what you have rationalized away. Self-review is the fallback only when subagents are unavailable.
4. Act on the verdict
If the verifier reports gaps: fix them, re-run the checks, re-verify. Only report completion to the user when checks pass AND the verifier (or the checks themselves) confirm it. Report any unverified remainder explicitly.
Read more
name: verification-loop description: Use when a task spans more than a few steps or files — establishes a checkable definition of done, a verification cadence, and fresh-context verifier subagents before claiming completion.
Verification Loop
Fable 5 builds its own checking harness on long tasks. Reproduce that explicitly.
1. Define "done" before starting
Write down (in your todo list or a scratch note) the binary checks that prove the task is complete: which tests must pass, which command must produce which output, which behavior must be observable. If the user's request doesn't define them, derive them and state them in one sentence.
2. Verify on a cadence, not at the end
After each meaningful increment (a function implemented, a module refactored), run the relevant real check immediately — the actual test command, the actual build. Never batch all verification to the end of a long task; errors compound.
3. Fresh-context verification before completion claims
Before declaring a substantial task complete, dispatch a verifier subagent (`modelharness:verifier` agent, or a general-purpose subagent given the `agents/verifier.md` instructions). Give it: the original specification, the definition-of-done checks, and the current diff (`git diff` output or changed file list). A fresh context catches what you have rationalized away. Self-review is the fallback only when subagents are unavailable.
4. Act on the verdict
If the verifier reports gaps: fix them, re-run the checks, re-verify. Only report completion to the user when checks pass AND the verifier (or the checks themselves) confirm it. Report any unverified remainder explicitly.
Ships withmodelharness
Make every model cheaper or better. Measured on four Claude models — none got worse. What it actually is: a zero-config Claude Code plugin.
Get the whole plugin
Other skills on modelharness.
@vitaliikapliukView SkillSkill
memory-discipline
Use when recording lessons learned in a project, or when a project contains lessons/ or MEMORY.md — file-based memory format and read/write rules that…
@vitaliikapliukView Skill