// Use after an execution slice to reassess whether the current tactic still serves the user's north star, then keep course, pivot, replan, or stop. Designed for long-running loops where the agent should keep moving unless a real blocker or completed lane exists.
Create, verify, repair, and close Codex goals as durable, evidence-based objectives for long-running work; covers agent-native goal tool usage, measurable outcome gates, docs/plans goal plans, lifecycle handling, pass-gated lanes, blockers, budgets, completion audits, and template repair.
Work a task end-to-end with lean context gathering, implementation, and verification
Operate Clawpatch for semantic feature mapping, automated review, explicit finding fixes, revalidation, reports, and state recovery.
Triage and process the Slate v2 issue ledger with OpenClaw-style sweep discipline: archive-first discovery, duplicate proof, small-fix gates, exact claim rules, maintainer-safe issue output, and gitcrawl API refreshes.
Create or update Plate docs with conversational voice, lane-aware structure, explicit ownership, and code-backed accuracy. This is the source of truth for Plate docs style and workflow. Use for plugin pages, guides, install docs, serialization docs, API docs, and specs — anywhere both humans and agents need a clear, readable source of truth.
Turn an editor-test-harvester report into one lane-specific execution plan, e.g. process every Slate v2 candidate from a harvest through slate-plan without executing implementation.
| description | Use after an execution slice to reassess whether the current tactic still serves the user's north star, then keep course, pivot, replan, or stop. Designed for long-running loops where the agent should keep moving unless a real blocker or completed lane exists. |
| name | continue |
| metadata | {"skiller":{"source":".agents/rules/continue.mdc"}} |
Use this after a meaningful execution slice.
This is a progress governor, not a status update.
Its job is to keep long-running work honest:
Read only what is needed to decide the next move:
current_pass, current_pass_status, and current_pass_skill from the
completion state file, if presentDo not rely on chat history for durable state.
If it matters, read it from disk.
Before deciding, read the narrowest active state file for the current lane.
After every verdict, update that same file in the same turn.
The state file should record:
Good default homes:
docs/plans/*.md when the project uses plan filesdocs/**, .agents/**, or the project's task
directoryDo not keep updating a stale broad plan once the work has moved to a narrower owner.
If the active state file records current_pass_skill and
current_pass_status is pending, in_progress, or revise, load that skill
before deciding the next move.
If current_pass_skill is missing but current_pass names a known skill, infer
.agents/skills/<current_pass>/SKILL.md when that file exists, then record the
explicit current_pass_skill path in the state file.
Do not skip to the next owner while the current pass is still pending, in-progress, or revision-ready.
When the current pass closes, update the same state file with:
current_pass_statusnext_passKeep top-level status: pending while a later pass or runnable owner remains.
Do not call a lane complete while the state file still lists:
Green checks are evidence.
They are not completion unless the required owner list is empty or explicitly reclassified.
Do not stop just because you wrote a checkpoint.
If the checkpoint has Next move and no hard blocker exists, execute it.
blocked is a terminal stop state, not a partial-slice handoff state.
Use blocked only when no autonomous progress is possible because required
evidence, tooling, access, or a user decision is missing.
If any in-scope owner still has a runnable next move, the state is pending.
This is true even when the current slice is verified, a focused gate passed, or
the remaining work is large.
Answer these bluntly:
If the answer to 2, 3, 4, or 5 is yes, pivot or replan.
If a meaningful cluster of remaining work points to one owner, treat that owner as the problem until proven otherwise.
Do not chase scattered local symptoms once the cluster is obvious.
After two or three local fixes around the same owner, stop harvesting small wins.
Escalate to the deeper owner.
If a local win violates a higher-priority principle, it is not a clean win.
Common higher-priority principles:
Gate it, rework it, or cut it.
When deciding the next move:
Tests, examples, docs, and measurements can be wrong or too narrow.
Challenge any row that encodes:
Classify bad evidence as:
Synthetic proof only proves its own scope.
If the claim is user-facing, require a user-path or integration proof before closure.
If research or architecture review exposes a stronger path, replan even if the current tactic has local wins.
The goal is the best durable outcome, not the shortest path to a green check.
Every slice should identify:
Before the first milestone:
After the first milestone:
Keep separate:
Do not let a win in one lane hide a regression in another.
Use when:
Then continue immediately.
Use when:
Then execute the better next move immediately unless a real decision is missing.
Use when:
Update the plan, then execute the first new move unless blocked.
Use only when:
Do not stop when:
Before stopping:
status: pending when more autonomous work remainsstatus: done when the lane is completestatus: blocked only when no autonomous progress is possiblestatus: blocked when the checkpoint names a runnable next moveKeep it short and sharp.
Always include:
Verdict: keep course / pivot / replan / stopHarsh take: one blunt sentenceWhy: 1-3 concrete bulletsRisks: touched risks or none knownEarliest gates: safety gate + progress gateNext move: concrete actionDo not do: what to stop wasting time onThis is a milestone update, not a handoff.
If the verdict is not stop, execute the next move in the same turn.
When updating the mutable state file, append:
Bad:
There are several tradeoffs to consider.It may be worth exploring.A possible option is...Good:
This tactic is tapped out.We are patching the wrong owner.The number is green, but the architecture is wrong. Replan.This wins locally by bypassing the user contract. Gate it or cut it.Verdict: pivot
Harsh take: the local fixes bought the easy wins, but the remaining failures prove the owner is deeper.
Why:
- the same behavior family is still red after three local fixes
- the latest change moved symptoms, not the owner
- the active plan values end-state correctness over preserving this implementation shape
Risks:
- changing the deeper owner can affect existing callers
Earliest gates:
- safety: focused contract test for the owner
- progress: focused reproduction for the remaining red family
Next move:
- fix the deeper owner and rerun the focused contract gate
Do not do:
- do not patch more callers around the same owner