メニュー
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.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SOC 職業分類に基づく
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/vitaliikapliuk/modelharness --skill verification-loopコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
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; these rules correct that.
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 measurably improve long-horizon performance.
| 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. |
Fable 5 builds its own checking harness on long tasks. Reproduce that explicitly.
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.
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.
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.
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.