---
name: long-task-continuation
description: "Use when a task is multi-step, may span context resets or sessions, uses subagents, or risks losing state before completion."
---

# Long Task Continuation

## Overview

Use this skill to keep long tasks checkpointed, resumable, drift-aware, and evidence-gated.

This is a protocol skill. It does not execute plans, dispatch subagents, run tests, or grant completion authority.

## Authority Boundary

Current owner:

- Method Pack protocol discipline

Not owned here:

- plan execution
- subagent dispatch
- host daemon / watchdog / automatic retry
- authoritative `GateDecision`
- evidence sufficiency final judgment
- completion authority

## When To Use

Use this skill when any of these are true:

- the task has multiple phases or more than one meaningful work slice
- the task may be interrupted, compacted, resumed, or handed off
- the task uses subagents
- the user explicitly asks for long-task continuity, resume safety, or avoiding drift
- the task changes architecture, contracts, shared workflows, or verification gates

For short direct answers or one-command checks, do not force this protocol.

Multi-step, todo-driven, possible-compaction, and subagent use do not force
durable records by themselves. Use `work/` for medium+ complexity or when work
actually crosses sessions, needs handoff, or requires resumable state;
otherwise keep an inline checkpoint.

## Required Artifacts

Maintain artifacts under `docs/aegis/work/YYYY-MM-DD-<slug>/`:

| Artifact | File | When |
|----------|------|------|
| TaskIntentDraft | `10-intent.md` and optional `task-intent-draft.json` | Start protocol |
| BaselineReadSetHint | `10-intent.md` (inline) | Start protocol |
| BaselineUsageDraft | `10-intent.md` (inline) and optional `baseline-usage-draft.json` | Start protocol and when baseline usage changes |
| ImpactStatementDraft | `10-intent.md` (inline) | Start protocol |
| TodoCheckpointDraft | `20-checkpoint.md` and optional `todo-checkpoint-draft.json` | Each checkpoint |
| ResumeStateHint | `20-checkpoint.md` (inline) | Each pause/handoff |
| DriftCheckDraft | `20-checkpoint.md` (inline) and optional `drift-check-draft.json` | Per-slice protocol |
| EvidenceBundleDraft | `90-evidence.md` and optional `evidence-bundle-draft.json` | Per-slice protocol |
| Reflection | `99-reflection.md` | Completion candidate |

The table applies only when the durable-record rule above selects `work/`.

`Execution Readiness View` may be included inline in `10-intent.md` or the
active checkpoint when the workstream is medium/high, subagent-driven,
handoff-prone, long-running, architecture / contract sensitive, or
compatibility / retirement sensitive. It is a human-readable rendering of
existing drafts and any parent plan, not a new JSON artifact or completion
authority.

Planless Slice Lane:

- Use this lane when an existing parent plan/spec owns the current micro-slice
  and it executes or refines one bounded parent task, or through the no-parent
  branch for a direct bounded mechanical request with no new durable or unclear
  verification boundary.
- Record a compact Slice Card instead of creating another durable plan/spec:

  ```text
  Slice Card:
  - Goal:
  - Parent plan/spec: <ref> | none — direct bounded request
  - Files:
  - Boundary:
  - Verification:
  - Stop:
  ```

- Slice Card `Goal` anchors slice-level completeness only, never whole-task
  completion.
- Final completion still requires `verification-before-completion` Goal Closure
  against the parent when present or the direct bounded request otherwise, plus
  any active goal frame, through the unified Aegis impact/safety receipt unless
  audit detail is requested.

- Do not create a plan/spec merely to supply a parent for an otherwise bounded
  slice.
- Parent-owned slices reuse existing checkpoint/evidence/drift records.
  No-parent low-complexity slices use an inline checkpoint; durable records
  follow the rule above.
- Escalate out of this lane only when a new owner, contract, schema, public API,
  architecture boundary, migration, persistence, security/permission,
  distribution/release surface, unclear verification boundary, or mismatch
  with the parent scope or acceptance appears.

When durable architecture decisions are in scope, these work records are the
preferred ADR Auto Backfill source. Preserve ADR signals, source refs,
alternatives, compatibility boundaries, drift checks, retirement notes, and
baseline-sync questions in the work record instead of relying on memory at
completion time.

These are draft / hint / projection inputs. They are not authoritative runtime records.

## Workspace Helper Protocol

When this rule selects `work/` and configured or installed Aegis workspace
support is available, use it for target-project lifecycle records:

1. Initialize before writing work records:

   ```bash
   python <aegis-workspace-helper> init --root <target-project-root>
   ```

2. For a new durable task process trail, prefer helper-backed lifecycle
   creation over hand-created files:

   ```bash
   python <aegis-workspace-helper> new-work --root <target-project-root> --date YYYY-MM-DD --slug <slug> --title "<title>" --requested-outcome "<outcome>" --scope "<scope>" --change-kind <kind>
   ```

3. After each slice, update checkpoint, evidence, and drift through the helper:

   ```bash
   python <aegis-workspace-helper> add-checkpoint --root <target-project-root> --work YYYY-MM-DD-<slug> ...
   python <aegis-workspace-helper> add-baseline-usage --root <target-project-root> --work YYYY-MM-DD-<slug> ...
   python <aegis-workspace-helper> add-attempt --root <target-project-root> --work YYYY-MM-DD-<slug> --slice-id <slice-id> --attempt-id <attempt-id> --attempt-status failed ...
   python <aegis-workspace-helper> add-evidence --root <target-project-root> --work YYYY-MM-DD-<slug> --slice-id <slice-id> --evidence-status <terminal-status> ...
   python <aegis-workspace-helper> add-drift-check --root <target-project-root> --work YYYY-MM-DD-<slug> ...
   ```

   Use `add-attempt` for a failed verification retry inside the current slice.
   Use `add-evidence` only after the slice reaches `evidence-finalized`,
   `blocked`, or `abandoned`. Do not let a failed attempt create another slice
   or a formal evidence sidecar.

4. Before pause, handoff, or completion candidate, assemble a structural proof
   bundle and check the workspace:

   ```bash
   python <aegis-workspace-helper> bundle --root <target-project-root> --work YYYY-MM-DD-<slug>
   python <aegis-workspace-helper> check --root <target-project-root>
   ```

These helper checks validate workspace structure, index coverage, and JSON
sidecar shape only. They do not determine evidence sufficiency, do not produce
authoritative `GateDecision`, and do not grant completion authority.

## Start Protocol

Before long-task execution:

1. State the requested outcome, scope, non-goals, and risk hints.
2. If goal framing exists, restate goal, success evidence, stop condition, and
   non-goals. Stop condition must allow done, blocked, needs-verification, and
   scope-exceeded outcomes.
3. Identify baseline refs that must be read before changing files.
4. Record baseline usage state:
   - required baseline refs
   - optionally delivered context refs when the host can project them
   - acknowledged before plan refs
   - cited in plan refs
   - missing refs
5. Create or update the todo map.
6. If the parent plan or workstream needs an execution handoff, render or link
   an `Execution Readiness View`:
   - intent lock
   - scope fence
   - baseline lock
   - owner / contract constraints
   - compatibility boundary
   - retirement boundary
   - task batches
   - test obligations
   - review gates
   - drift / rewind rules
   - evidence required before completion
   - advisory boundary
7. Create the first checkpoint:
   - current todo
   - active slice
   - completed todos
   - evidence refs
   - blocked-on items
   - next step
8. If baseline refs are missing, pause in `needs-baseline-readback`.
9. If this rule selects `work/` and the helper is available, use
   `aegis-workspace.py new-work` to create/index the first `docs/aegis/work/`
   files and run `check --root <target-project-root>` before continuing.

## Retry Convergence Protocol

A failed verification is another attempt in the current slice, not a new slice.

- Reuse the current `activeSlice` as the `--slice-id`.
- Record each retry with `add-attempt`, not `add-evidence`.
- Do not append failed attempts to `90-evidence.md`.
- Do not create a normal commit for attempt telemetry.
- A process-only diff under `docs/aegis/` does not restart completed business-code verification.
- When `add-attempt` reports `process-artifact-pressure`, stop auto-retry and route to `systematic-debugging` or `verification-before-completion`.

Only terminal evidence (`evidence-finalized`, `blocked`, or `abandoned`) is
eligible for `bundle`.

## Per-Slice Protocol

Before each work slice, restate:

1. current goal
2. current todo
3. intended edits
4. explicit non-edits
5. verification command or manual check
6. `Execution Readiness View` alignment when one exists

For bounded parent-plan or no-parent slices inside the lane guards, state the
Planless Slice Card instead of opening a new planning/specification artifact.

After each work slice, update:

1. completed todos
2. evidence refs
3. baseline usage if newly required refs were acknowledged, cited, or found missing
4. blockers
5. next step
6. drift check
7. when an active helper-backed work record exists, update JSON sidecars through
   `aegis-workspace.py add-checkpoint`,
   `aegis-workspace.py add-baseline-usage`, `aegis-workspace.py add-evidence`, and `aegis-workspace.py add-drift-check`
   when available
8. failed verification: `add-attempt` with the current `--slice-id`; do not add
   terminal evidence or create a process-only commit

When patch-shape/ripple triage, an H-class finding, or a bounded compatibility
mitigation fired, a locally green result does not clear that direction. Reuse
checkpoint prose and evidence refs to retain `PatchShape`, `CanonicalOwner`,
`UpwardDrillSignal`, decision, latest outcome, and one bounded evidence ref;
do not copy raw logs or full diffs.

If no fresh evidence exists, the state is `needs-verification` or `partial`.

## Resume Protocol

When resuming:

1. Read latest checkpoint.
2. Read latest resume hint if present.
3. Re-read original task intent.
4. Re-read required baseline refs.
5. Passively re-read relevant active `CONTEXT.md` language for non-trivial work.
6. Re-read the `Execution Readiness View` if present.
7. Compare current worktree state with checkpoint claims.
8. Compare the slice with the view's intent, scope, baseline, compatibility,
   retirement, test, and review locks.
9. If any disagreement exists among the checkpoint, baseline, context, view, and
   worktree, compose `establishing-project-context` for a semantic conflict; for
   any other disagreement, pause or return to planning.
10. Before an unplanned repair, read retained invariant, owner seam, patch shape,
   and causal topology and route comparison to `systematic-debugging`; a new
   carrier name alone does not prove a new direction.

Never resume from memory alone.

## Drift Check

Answer these after each slice:

- Does the current work still serve the original task intent?
- Does the current work still serve the goal and stop condition?
- Did the slice stay inside the compatibility boundary?
- Did any new owner, fallback, adapter, or branch appear?
- Is the retirement track still explicit?
- Did the evidence bundle grow enough to support the next claim?
- If an `Execution Readiness View` exists, does the active slice still match
  its intent lock, scope fence, baseline lock, compatibility boundary,
  retirement boundary, test obligations, and review gates?

Allowed decisions:

- `continue`
- `pause-for-user`
- `needs-baseline-readback`
- `needs-verification`
- `blocked`

Forbidden decisions:

- `gate-passed`
- `completion-granted`
- `authoritatively-safe`

## Completion Candidate Protocol

Before saying work is complete:

1. Use aegis:verification-before-completion.
2. Confirm every todo has a status.
3. Confirm blockers are resolved or externalized.
4. Confirm evidence refs cover the acceptance criteria.
5. Confirm drift check has no blocking state.
6. Run `python <aegis-workspace-helper> bundle --root <target-project-root>
   --work YYYY-MM-DD-<slug>` if the helper is available and a work record
   exists.
7. Run `python <aegis-workspace-helper> check --root <target-project-root>`
   if the helper is available and the task wrote `docs/aegis/` records.
8. Treat the generated `GateInputPack` as future-runtime input only.
9. If durable architecture decisions were in scope, pass the work record,
   proof bundle, drift checks, evidence refs, and ADR signals into
   aegis:verification-before-completion for ADR Backfill Check.

Method Pack output is verified evidence and advisory judgment only. It is not authoritative completion.

## Minimal Reporting Shape

Use this shape for long-task updates:

- `Aegis Visibility`: why checkpoint, resume, drift, handoff, or parent-plan
  discipline is shaping the next step
- `TodoCheckpointDraft`: current todo, completed todos, active slice, next step
- `BaselineUsageDraft`: required refs, acknowledged refs, cited refs, missing refs, decision
- `Execution Readiness View`: present | absent | refreshed | stale, and the
  alignment signal when present
- `Evidence`: commands, files, logs, or manual checks
- `Process Artifact Pressure`: attempted slices, retry count, terminal state,
  and whether convergence-stop is active
- `DriftCheckDraft`: scope, compatibility, retirement, decision
- `Risk / Unknown`: unresolved blockers or missing evidence
- `Next`: the next smallest safe action