Interrupted Multi-Step Task Resume Prompt

This prompt is for AI engineers and product teams building copilots or agents that execute sequential, multi-step workflows—such as onboarding checklists, deployment runbooks, or data processing pipelines—where a user interjects with a correction, question, or new instruction mid-execution. The core job-to-be-done is to safely pause the workflow, produce a structured checkpoint of what has been completed and what is now in doubt, and generate a resume plan that avoids re-executing finished work or violating new constraints introduced by the interruption. It is not a general conversation-repair prompt; it assumes a known, ordered task graph exists and that the primary risk is state corruption from the interruption, not ambiguity about the task itself.

Use this prompt when your system has a defined sequence of steps with dependencies, and an interruption may invalidate some completed or in-progress work. The ideal user is a developer integrating this into an agent harness where the task plan is represented as a list of steps with statuses (e.g., pending, in_progress, completed, blocked). Required context includes the original task plan, the execution log up to the interruption point, and the user's interjection text. Do not use this prompt for open-ended conversations, single-turn corrections, or workflows where steps are independent and can be safely retried without coordination. It is also inappropriate when the interruption is a full task cancellation—this prompt assumes the user wants to resume, not abort.

Before wiring this into production, define the schema for your task plan and execution log. The prompt expects structured input, not freeform history. You must also implement a post-generation validator that checks the resume plan for step duplication, missing dependencies, and ordering violations. For high-stakes workflows—such as financial operations or infrastructure changes—require human approval of the checkpoint summary before the agent resumes execution. The next section provides the copy-ready prompt template you can adapt to your task schema and interruption-handling logic.

This prompt template is designed for copilots and agents executing sequential workflows that get interrupted by user interjection. It instructs the model to produce a structured checkpoint of completed steps, pending dependencies, and the interruption's impact, then generate a resume plan that avoids re-executing completed work. The template uses square-bracket placeholders that you replace with your application's specific task definitions, conversation history, and output schema requirements before sending to the model.

codeCopy
You are a task-resume assistant for a multi-step workflow system. Your job is to analyze an interrupted task, produce a checkpoint of what was completed, and generate a safe resume plan.

# TASK DEFINITION
[TASK_STEPS]

# CONVERSATION HISTORY
[CONVERSATION_HISTORY]

# INTERRUPTION DETAILS
Interruption type: [INTERRUPTION_TYPE]
User's interjection: [USER_INTERJECTION]
Step being executed when interrupted: [INTERRUPTED_STEP_ID]

# OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "checkpoint": {
    "completed_steps": [
      {
        "step_id": "string",
        "step_description": "string",
        "output_summary": "string",
        "validation_status": "valid|needs_review|invalidated_by_interruption"
      }
    ],
    "in_progress_step": {
      "step_id": "string | null",
      "partial_output": "string | null",
      "recovery_notes": "string"
    },
    "pending_steps": [
      {
        "step_id": "string",
        "step_description": "string",
        "depends_on": ["step_id"]
      }
    ],
    "interruption_impact": {
      "invalidated_steps": ["step_id"],
      "context_changes": ["string"],
      "new_constraints": ["string"]
    }
  },
  "resume_plan": {
    "restart_from_step": "string",
    "steps_to_skip": ["step_id"],
    "steps_to_repeat": ["step_id"],
    "revised_step_sequence": ["step_id"],
    "rationale": "string"
  },
  "requires_user_confirmation": true,
  "confirmation_question": "string | null"
}

# CONSTRAINTS
- Do not re-execute steps marked as completed and valid unless explicitly invalidated by the interruption.
- If the interruption changes a dependency, mark dependent steps for re-execution.
- If the interruption introduces ambiguity about prior outputs, flag those steps as needs_review.
- If the interruption is a correction to a prior step, treat that step and all dependents as invalidated.
- If the interruption is a new request unrelated to the current task, propose completing the current task first unless the user explicitly demands priority change.
- Set requires_user_confirmation to true if the resume plan changes the task outcome, skips user-visible steps, or re-executes work the user may have already seen.
- If the interruption intent is unclear, set requires_user_confirmation to true and ask a specific clarification question.

# EXAMPLES
[FEW_SHOT_EXAMPLES]

# RISK LEVEL
[RISK_LEVEL]

Analyze the interruption and produce the checkpoint and resume plan.

To adapt this template, replace the square-bracket placeholders with your application data. [TASK_STEPS] should contain the ordered list of steps with their IDs, descriptions, and dependency relationships. [CONVERSATION_HISTORY] should include the full turn history up to the interruption point. [INTERRUPTION_TYPE] classifies the interruption as a correction, new request, clarification, or unrelated input. [FEW_SHOT_EXAMPLES] should include 2-3 examples of interrupted workflows with correct checkpoint and resume plan outputs, covering at least one correction scenario and one new-request scenario. For high-risk workflows where incorrect step ordering could cause data loss, financial impact, or safety issues, set [RISK_LEVEL] to "high" and ensure your application layer enforces human approval before executing the resume plan. Always validate the output JSON against your schema before acting on the resume plan, and log both the checkpoint and the final executed plan for auditability.

This prompt is designed to be called as a recovery subroutine within an agent execution loop, not as a standalone chat turn. When the main agent loop detects a user interjection—either through an explicit interruption signal in a real-time interface or by classifying an incoming user message as a correction or new instruction—the loop should pause the current task, capture the execution state, and invoke this prompt. The prompt expects a structured snapshot of the original plan, completed steps with their outputs, pending steps, and the user's interjection text. Its output is a machine-readable resume plan that the agent executor can consume directly.

Wire the prompt into your agent harness with a strict JSON schema for both input and output. The input should include: [ORIGINAL_PLAN] as an ordered list of step objects with id, description, and status; [COMPLETED_STEPS] as a list of step objects with id, output_summary, and artifacts; [PENDING_STEPS] as the remaining ordered list; and [USER_INTERJECTION] as the raw text. The output schema must enforce resume_plan (ordered list of steps to execute, with step_id, action, and reuse_completed_output boolean), invalidated_steps (list of completed step IDs that must be re-executed), and interruption_impact_summary (string). Validate the output before passing it to the agent executor: confirm no completed step appears in the resume plan unless explicitly invalidated, verify step ordering preserves declared dependencies, and reject plans that re-execute work without justification.

For model choice, use a model with strong instruction-following and JSON mode support—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate. Set temperature=0 to maximize deterministic step ordering. Implement a retry loop: if the output fails schema validation, re-invoke the prompt with the validation error appended to the [CONSTRAINTS] field, up to two retries. After two failures, escalate to a human operator with the original plan, completed steps, and interjection for manual resumption. Log every invocation with the input plan, interjection text, raw output, validation result, and final resume plan for debugging and audit. This prompt is high-risk in production because incorrect step ordering can duplicate work, skip critical actions, or violate task dependencies—always run the eval suite described in the testing section before deploying changes to the prompt or the surrounding harness.