User Correction Impact Analysis Prompt on Pending Tasks

This prompt is designed for copilot and assistant systems where a user's mid-session correction—such as changing a fact, preference, or constraint—invalidates previously planned work. Its job is to analyze the current list of pending tasks against the user's correction and produce a structured diff: which tasks are unaffected, which need re-evaluation, and which should be cancelled outright. The ideal user is an AI engineer or product developer building a task-oriented assistant that maintains an explicit pending action queue, such as a coding copilot with a task list, a travel booking assistant with an itinerary, or a support agent with a multi-step resolution plan.

Use this prompt when your application already maintains a structured list of pending tasks and you have detected a user correction that changes a foundational assumption. The prompt requires three concrete inputs: the user's correction statement, the current pending task list with descriptions and dependencies, and the specific fact or preference that was corrected. It is not a general-purpose clarification handler or a task generation prompt. Do not use it when the correction is ambiguous and requires clarification first, when the task list is implicit or unstructured, or when the correction is purely stylistic and does not affect task validity. The prompt assumes the correction has already been parsed and confirmed; it does not handle the disambiguation dialogue itself.

The output is a machine-readable diff, not a conversational response. This prompt is a middleware component that should sit between your correction detection layer and your task execution engine. After running this prompt, your application should programmatically update the task queue, notify the user of changes, and re-prioritize affected items. For high-stakes domains where incorrect task cancellation could cause data loss, financial impact, or safety issues, always route the diff through a human review step before applying changes to the live task queue. The prompt includes a confidence scoring field to help automate triage decisions for low-risk items while escalating uncertain cases.

This prompt is designed to be the core reasoning step in a copilot system where a user's mid-session correction can invalidate prior context. When a user corrects a fact, preference, or constraint, the system must not only update its understanding but also re-evaluate all pending tasks that were derived from the now-invalidated information. The template below accepts the user's correction, the current pending task list, and the relevant conversation context, then outputs a structured analysis of which tasks are affected and how.

textCopy
You are an AI copilot analyzing the impact of a user correction on a list of pending tasks. Your goal is to identify which tasks are invalidated, need re-evaluation, or can remain unchanged.

## INPUTS

### User Correction
[USER_CORRECTION]

### Pending Task List
[PENDING_TASK_LIST]

### Conversation Context (last N turns)
[CONVERSATION_CONTEXT]

### Output Schema
[OUTPUT_SCHEMA]

## INSTRUCTIONS

1. Parse the user correction to identify the specific fact, preference, or constraint being changed.
2. For each task in the Pending Task List, determine if the task's assumptions, inputs, or validity depend on the corrected information.
3. Classify each affected task into one of these categories:
   - **INVALIDATED**: The task's foundation is directly contradicted by the correction and must be cancelled.
   - **NEEDS_RE-EVALUATION**: The task may still be valid but its parameters, priority, or output need adjustment.
   - **UNCHANGED**: The task is independent of the corrected information.
4. For each INVALIDATED or NEEDS_RE-EVALUATION task, provide:
   - The original task description
   - The specific dependency on the corrected information
   - A brief explanation of why the correction affects this task
   - A recommended action (cancel, re-plan, adjust parameters)
5. Produce a summary of the overall impact, including the count of tasks in each category.
6. If the correction creates a cascading effect where re-evaluating one task may affect others, flag this as a **CASCADE RISK**.

## CONSTRAINTS

- Do not modify the Pending Task List directly; only produce the analysis.
- If the user correction is ambiguous, flag it as **NEEDS CLARIFICATION** before proceeding.
- If no tasks are affected, explicitly state this with confidence.
- Preserve the original task IDs or references in your output for traceability.
- If [RISK_LEVEL] is HIGH, include a recommendation for human review before any automated task cancellation.

To adapt this template, replace the square-bracket placeholders with your application's actual data structures. The [PENDING_TASK_LIST] should be a serialized list of task objects with unique IDs, descriptions, and any metadata your system tracks. The [OUTPUT_SCHEMA] placeholder should be replaced with your desired JSON schema or structured format specification. For high-stakes workflows where incorrect task cancellation could cause data loss or user harm, set [RISK_LEVEL] to HIGH and ensure your implementation harness enforces human approval before acting on INVALIDATED classifications. Test this prompt against edge cases where the correction is partially overlapping with task dependencies, where multiple tasks form a dependency chain, and where the correction itself is later corrected.

This prompt is designed to be called as a post-correction hook within a stateful AI copilot. After a user explicitly corrects a fact, preference, or constraint (e.g., 'Actually, the budget is $5k, not $10k'), the application should capture the correction, the corrected value, and the current pending task list. The prompt then performs a dependency analysis, returning a structured diff of tasks that are now invalid, need re-evaluation, or can be cancelled. This is not a real-time, per-turn prompt; it is a discrete analysis step triggered by a high-signal user correction event.

To wire this into an application, implement a state management layer that maintains a canonical list of pending tasks, each with a unique ID, description, and the key facts or constraints they depend on. When a user correction is detected—either by a separate classification prompt or a simple UI flag—the application should call this prompt with the [CORRECTED_FACT], the [PREVIOUS_VALUE], and the full [PENDING_TASK_LIST] in a structured JSON format. The model's response, a JSON array of affected task IDs with impact rationales and recommended actions, must be validated against the actual task IDs in your state to prevent hallucinated identifiers. For high-stakes workflows, such as financial or legal copilots, the system should not automatically cancel or modify tasks based on the model's output. Instead, present the diff to the user for explicit confirmation, treating the model's output as a recommendation engine.

For logging and observability, record the full input payload, the model's raw output, and the validated diff. This trace is critical for debugging cases where the model missed an impacted task (a false negative) or flagged a task that was not actually dependent on the corrected fact (a false positive). Implement a retry strategy with a maximum of two attempts if the initial output fails JSON schema validation or contains task IDs not present in the input. If validation fails after retries, escalate to a human operator and log the failure for prompt refinement. Avoid using this prompt on every user message; it is a targeted, event-driven analysis tool, and overuse will introduce latency and unnecessary processing costs.