# Continuation Guard — Anti-Idle Execution Continuity

## What This Skill Does

The Continuation Guard prevents agents from slowing down, going implicitly idle, or losing execution continuity after replies, interruptions, or quiet periods. It ensures that agents keep working without user nudges, especially in autonomous operation, task queues, and multi-agent systems.

**The core problem:** AI agents treat every response as a potential stop signal. They answer the user and then wait. In an autonomous system, that's a bug — work should continue until the task list is empty, not until the conversation pauses.

## Core Outcome

For every meaningful task, the system must preserve five things:
1. **Current state** — what phase is this task in?
2. **Last real progress** — when did something concrete last change?
3. **Exact next action** — what specific step comes next?
4. **Restart handle** — if interrupted, how do you resume?
5. **Proof artifact** — what evidence shows real work happened?

If any of these are missing, the agent is vulnerable to idle drift.

## Work States

Use a strict state machine — no vague states:

| State | Meaning |
|---|---|
| `doing` | Actively being worked on right now |
| `blocked` | Cannot proceed — waiting on external dependency |
| `waiting_on_human` | Requires operator input or approval |
| `parked` | Intentionally paused with a restart handle |
| `completed` | Work finished, output delivered |
| `verified` | Work finished AND verified correct |

**Never leave a task in a vague state** like "active" with no restart note, or "in progress" with no next action.

## Restart Handles

Before switching away from any task, record:

| Field | Required | Example |
|---|---|---|
| `resume_next_action` | Yes | "Check vendor API for shipping status, then update tracking log" |
| `parked_state` | Yes | "Completed steps 1-3 of 5. Step 3 output saved to results.md" |
| `last_update` | Yes | "2026-03-22 14:30 HST" |
| `proof_path` | Yes | "ops/results/vendor-check-2026-03-22.md" |
| `restart_note` | Yes | "Resume from step 4: API rate limit resets at 15:00" |
| `resume_command` | When applicable | "python3 scripts/process.py --resume --from-step 4" |

**Good restart note:** "Resume from data reconciliation by checking the three unmatched records in staging.md, then update the final report and notify the operator."

**Bad restart note:** "Continue later."

## Proof-of-Work Standards

Count as real progress ONLY when something concrete changed:
- File edited or created
- Task state updated with new information
- Command/tool result obtained and recorded
- Artifact generated (report, analysis, output)
- Message sent with substantive content
- Configuration changed and verified

**NOT proof of work:**
- Status updates that repeat previous state
- "Monitoring" without new findings
- Checking something and finding no change
- Time passing

## Resume-After-Reply Rule

After answering the user, **automatically resume** the highest-priority unfinished task unless:
- The user explicitly reprioritized
- The task is blocked on an external dependency
- The task is waiting on operator approval
- A higher-priority task entered `doing` state

A reply to the user is NOT a stop signal. It is a communication event within ongoing work.

## Anti-Drift Checks (Run by Wisdom Every Cycle)

1. **State hygiene:** Does every active task have a defined work state?
2. **Restart handle:** Does every paused task have a concrete restart handle?
3. **Proof freshness:** In the last 30 minutes, has the agent produced concrete artifacts?
4. **Post-reply continuation:** After the last user reply, did the agent resume work?
5. **Parked task review:** Are any tasks parked for more than 2 hours without reason?
6. **Idle detection:** Is the agent in a state where it has pending work but isn't doing any?

## Scoring (Wisdom Integration)

| Finding | Score | Classification |
|---|---|---|
| All tasks have state + handle + proof | 0.0 | PASS |
| Missing restart handles on parked tasks | 0.3 | WATCH |
| No proof-of-work in 30+ minutes | 0.5 | FLAG |
| Agent idle after reply with pending work | 0.7 | ALERT |
| Agent declared "monitoring" when execute is instructed | 0.8 | CRITICAL |

## Design Rules

- Prefer fewer canonical state files over many partial mirrors
- Keep one source of truth for task state
- Make stalled work obvious instead of silently optimistic
- Preserve restartability before elegance
- Treat autonomous continuation as an execution-system requirement, not a personality trait
