long-task-continuation
long-task-continuation is a protocol skill for managing multi-phase tasks that may span context resets, involve subagents, or risk losing state before completion. It establishes checkpoints, drift detection, and evidence gating through structured artifacts stored in dated work directories, without itself executing plans, dispatching subagents, or making final completion decisions.
git clone --depth 1 https://github.com/GanyuanRan/Aegis /tmp/long-task-continuation && cp -r /tmp/long-task-continuation/skills/long-task-continuation ~/.claude/skills/long-task-continuationSKILL.md
# 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. ## 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 | For medium+ complexity tasks only. Low-complexity tasks skip work/. Planless Slice Lane: - Use this lane when a parent plan or parent spec already owns the long-task workstream and the current micro-slice only executes or refines one bounded parent task. - Record a compact Slice Card instead of creating another durable plan/spec: ```text Slice Card: - Goal: - Parent plan/spec: - Files: - Boundary: - Verification: - Stop: ``` - Slice Card `Goal` anchors slice-level completeness only. - It does not by itself grant whole-task completion. - Final completion still requires `verification-before-completion` Goal Closure against the parent plan/spec and any active goal frame. - Do not create new plan/spec files for micro-slices that stay inside the parent plan, existing compatibility boundary, and known verification path. - Update the existing checkpoint, evidence, and drift records when persistent state is needed. - Escalate out of this lane only when a new owner, contract, schema, public API, architecture boundary, migration, persistence, security/permission, distribution/release surface, or unclear verification boundary 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 configured Aegis workspace support or installed Aegis workspace support is available, use it for the target project workspace and lifecycle records: 1. Initialize before writing work records: ```bash python <aegis-workspace-helper> init --root <target-project-root> ``` 2. For a new medium+ 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-evidence --root <target-project-root> --work YYYY-MM-DD-<slug> ... python <aegis-workspace-helper> add-drift-check --root <target-project-root> --work YYYY-MM-DD-<slug> ... ``` 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. Create the first checkpoint: - current todo - active slice - completed todos - evidence refs - blocked-on items - next step 7. If baseline refs ar
|
Deprecated - use the aegis:brainstorming skill instead
Deprecated - use the aegis:executing-plans skill instead
Deprecated - use the aegis:writing-plans skill instead
Use when retiring old logic, collapsing duplicate owners, removing fallbacks, or touching schema, persistence, or source-of-truth boundaries while deciding whether to delete old paths, retain compatibility, or stop for confirmation.
Use when defining new features, product behavior, UI/component design, architecture choices, contract changes, or ambiguous medium/high-complexity work before implementation.
Use when the user asks for caveman mode, fewer tokens, brief responses, compressed communication, or otherwise explicitly requests a much shorter answer.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies