Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Loop /do cycles until done-criteria verify or budget stops.
.claude/skills/notque-objective-loop/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-05 | ✗→✓ | ▲ Improved | 43% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 15% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 143% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 2% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 77% | 0% |
The toolkit's iterate-until-verified-done loop. A user states an objective with verifiable done-criteria; each iteration routes one /do cycle, verifies the criteria by executing them, and reschedules itself via ScheduleWakeup until verified-done or budget-stop. This skill is a planner/verifier wrapped around the /do router — it executes no work inline. Objectives over tasks: describe what done looks like and how to verify it; the loop finds the path.
Gather the objective spec from the request. Interview only for missing fields.
| Field | Required | Default | |---|---|---| | Objective statement | yes | — | | DONE-CRITERIA | yes | — | | Iteration budget | no | 5 | | Token-budget note | no | orchestration.token_budget from .claude/settings.json (500000 when absent) | | NOT-DONE-YET guardrails | no | empty |
DONE-CRITERIA are verifiable checks. Each criterion has a type: command (default, preferred) or rubric.
command — a deterministic command with an expected exit code/output: pytest -q exits 0; gh pr view N --json state -q .state prints MERGED; validate-doc-counts.py reports zero drifts. A criterion the model reasons about is not a criterion; each needs a command plus an expected observable.rubric — allowed only where no mechanical check exists, per the PHILOSOPHY.md verification ranking (exit code > fresh-context grader > self-critique). Store the rubric verbatim in the state file at SPEC time: pass conditions plus the evidence the grader must cite. Frozen once the loop starts — changes require the user, same as a guardrail.NOT-DONE-YET guardrails name what may never be done to satisfy a criterion (e.g. "never weaken a gate to make it pass"). They bind every iteration: inject them verbatim into each /do dispatch.
Gate: spec complete. Proceed to Phase 2.
Write .objective/<slug>/state.md from the template in references/state-file.md: objective, criteria table, guardrails, per-iteration log, next planned step.
.objective/ mirrors .feature/'s ephemerality but stays separate: .feature/ is feature-lifecycle's phase machine, managed only by feature-state.py, and its presence reroutes /do into feature phases. Objectives are arbitrary goals..objective/ unstaged; stage repo files by name only.Gate: state file written. Proceed to Phase 3.
Plan the smallest next step toward the unmet criteria, then route it through the /do phases: classify → route → dispatch agents → evaluate. The loop dispatches work exclusively through /do — catching yourself editing or analyzing inline means stop and route. Multi-part objectives may dispatch parallel agents per /do's rules.
Learning capture is automatic. Every iteration dispatches through /do, so routing rows and outcomes record via the /do learning hooks. Add no manual capture.
Gate: dispatch evaluated, iteration log updated in the state file. Proceed to Phase 4.
Run every done-criterion check. A worker's "criterion passes" claim never substitutes for the re-run.
command — run the command; paste the exit code and the decisive output line into the iteration log.rubric — dispatch a fresh-context sub-agent that did NOT produce the work. Input is the artifact plus the rubric, nothing else — no iteration history. It returns PASS/FAIL plus cited evidence (file:line or output excerpt), pasted into the iteration log exactly like an exit code.Then:
ScheduleWakeup.Criteria-gaming guard (hard rule). A criterion may never be satisfied by weakening a hook, gate, test, or safety control — and a rubric is never weakened to pass. When the only visible path to "pass" weakens a control or the rubric text, stop the loop and report the conflict to the user.
| State | Action | |---|---| | All criteria pass | Final report; stop — no wakeup call | | Unmet + iterations remain | Update state file (log, next planned step); call ScheduleWakeup {delaySeconds, reason, prompt} with prompt = "Read .objective/<slug>/state.md, then resume the objective-loop skill from that state file." | | Budget exhausted | Honest NOT-DONE report: per-criterion status with last evidence, remaining gaps, suggested next step; stop — no wakeup call |
Delay table (prompt-cache aware; ScheduleWakeup clamps 60–3600s):
| Wait type | Delay | Cache economics | |---|---|---| | Active polling (CI run, PR merge expected soon) | 270s or less | Keeps the Anthropic prompt cache warm (5-min TTL) | | Idle / long agent work | 1200s+ | Pays one cache miss; right for long gaps | | ~300s band | skip it | Worst case — pays the miss with none of the idle benefit |
Harness fallback. When ScheduleWakeup is absent from your tool list, run iterations sequentially in-session against the same state file and budgets. For a single until-condition wait inside an iteration, the Monitor tool fits; loop boundaries use ScheduleWakeup.
ScheduleWakeup: session-scoped, dies with the session, zero persistence.CronCreate or system crontab survives the session and requires the owner's explicit OWNER-APPROVED-PERSISTENCE phrase per the home CLAUDE.md. Stop and ask before any cron-mode loop; on approval, route to headless-cron-creator.| Error | Cause | Solution | |---|---|---| | State file missing on wakeup | .objective/<slug>/ removed mid-loop | Report and stop; ask the user to restate the objective rather than re-deriving it from memory | | Criterion command fails to run (not just non-zero) | Tool missing, bad path | Fix the check command in the state file first; a broken check verifies nothing | | Unmet-criteria set unchanged across 2 iterations (read from the Last result column, not judged from memory) | Plan stuck | Change approach: re-route through /do with a different agent or skill; unchanged after a third iteration, spend the report on what blocked progress and stop | | Wakeup arrives with fresh context | Normal — wakeups carry only the prompt | Resume entirely from the state file per references/state-file.md |
| Signal | Load These Files | Why | |---|---|---| | Writing or resuming the state file | state-file.md | Template, slug rules, resume protocol |
${CLAUDE_SKILL_DIR}/references/state-file.md — state-file template, slug rules, and the wakeup resume protocol| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 2,495 | 9,610 | +285% | 1 | 1 | 0% | 274 | 2,199 | +703% | 0 | 0 | — |
case-02 | fail→fail | 5,066 | 6,499 | +28% | 1 | 1 | 0% | 274 | 2,127 | +676% | 0 | 0 | — |
case-03 | fail→fail | 2,836 | 14,199 | +401% | 1 | 1 | 0% | 365 | 2,193 | +501% | 0 | 0 | — |
case-04 | pass→pass | 13,531 | 6,790 | -50% | 1 | 1 | 0% | 1,992 | 2,707 | +36% | 0 | 0 | — |
case-05 | fail→pass | 10,601 | 3,923 | -63% | 1 | 1 | 0% | 1,674 | 2,389 | +43% | 0 | 0 | — |
case-06 | pass→pass | 9,045 | 2,677 | -70% | 1 | 1 | 0% | 1,468 | 2,186 | +49% | 0 | 0 | — |
case-07 | pass→pass | 10,875 | 5,654 | -48% | 1 | 1 | 0% | 1,776 | 2,595 | +46% | 0 | 0 | — |
case-08 | fail→pass | 11,526 | 2,758 | -76% | 1 | 1 | 0% | 1,900 | 2,187 | +15% | 0 | 0 | — |
case-09 | fail→pass | 5,144 | 1,941 | -62% | 1 | 1 | 0% | 851 | 2,071 | +143% | 0 | 0 | — |
case-10 | fail→pass | 14,335 | 3,445 | -76% | 1 | 1 | 0% | 2,186 | 2,233 | +2% | 0 | 0 | — |
case-11 | fail→fail | 8,104 | 2,863 | -65% | 1 | 1 | 0% | 1,335 | 2,135 | +60% | 0 | 0 | — |
case-12 | fail→pass | 7,276 | 2,188 | -70% | 1 | 1 | 0% | 1,144 | 2,024 | +77% | 0 | 0 | — |
case-13 | fail→pass | 13,498 | 3,832 | -72% | 1 | 1 | 0% | 1,987 | 2,306 | +16% | 0 | 0 | — |
case-14 | pass→pass | 9,683 | 2,249 | -77% | 1 | 1 | 0% | 1,613 | 2,028 | +26% | 0 | 0 | — |
case-15 | fail→pass | 9,938 | 2,752 | -72% | 1 | 1 | 0% | 1,655 | 2,171 | +31% | 0 | 0 | — |
case-16 | fail→pass | 11,571 | 2,190 | -81% | 1 | 1 | 0% | 1,678 | 2,102 | +25% | 0 | 0 | — |
case-17 | pass→pass | 12,720 | 3,473 | -73% | 1 | 1 | 0% | 1,913 | 2,273 | +19% | 0 | 0 | — |
case-18 | fail→pass | 15,100 | 1,989 | -87% | 1 | 1 | 0% | 2,400 | 1,974 | -18% | 0 | 0 | — |
case-19 | fail→pass | 11,545 | 1,784 | -85% | 1 | 1 | 0% | 1,713 | 1,969 | +15% | 0 | 0 | — |
case-20 | pass→pass | 9,981 | 1,935 | -81% | 1 | 1 | 0% | 1,472 | 1,993 | +35% | 0 | 0 | — |
case-21 | fail→pass | 12,985 | 2,648 | -80% | 1 | 1 | 0% | 1,909 | 2,074 | +9% | 0 | 0 | — |
case-22 | pass→fail | 6,312 | 3,856 | -39% | 1 | 1 | 0% | 949 | 2,316 | +144% | 0 | 0 | — |
case-23 | pass→fail | 5,550 | 4,282 | -23% | 1 | 1 | 0% | 827 | 2,341 | +183% | 0 | 0 | — |
case-24 | fail→fail | 6,939 | 4,493 | -35% | 1 | 1 | 0% | 1,044 | 2,246 | +115% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 24 cases were attempted, and 21 counted toward the lift figure. The other 3 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +38 percentage points is the difference between those two pass rates over the 21 comparable cases. 2 cases got worse with the skill loaded, and they are included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.