workflow-recovery

Generates safe recovery plans for interrupted workflows from checkpoints, events, and handoff records.

Updated Aug 1, 2026
One-click install
npx skills add https://github.com/QuyDu/Skills-Orchestrator --skill workflow-recovery-quydu
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: workflow-recovery
Source: https://github.com/QuyDu/Skills-Orchestrator/tree/main/.github/skills/workflow-recovery
Command: npx skills add https://github.com/QuyDu/Skills-Orchestrator --skill workflow-recovery-quydu

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When an automated workflow crashes, gets interrupted, or partially applies changes, resuming blindly risks corrupting state or duplicating side effects. This Skill reconstructs what actually happened and produces a safe, evidence-backed recovery plan before any action is taken. ## Core Features & Use Cases - Timeline Reconstruction: Rebuilds the interrupted workflow from authoritative state, event logs, checkpoints, and handoff records. - Failure Classification: Categorizes the cause as transient, deterministic defect, policy block, missing approval, or external dependency outage. - Recovery Path Generation: Produces retry, rollback, compensation, or alternate-path options with explicit stop criteria, approval gates, and operator actions. - Use Case: A remediation rollout fails halfway after modifying external systems. The Skill identifies the last approved checkpoint, accounts for partial side effects, and outputs a compensation-first recovery plan in reports/recovery-plan.json and reports/recovery-plan.md. ## Quick Start Analyze the interrupted deployment workflow using the latest state and handoff records, then produce a recovery plan with rollback and retry options.

Frequently Asked Questions about workflow-recovery

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I recover a workflow that failed partway through execution?

Reconstruct the timeline from state and event logs, identify the last known good checkpoint and failed step, then classify the failure cause. The Skill generates retry, rollback, compensation, or alternate-path options with explicit stop criteria and writes them to recovery plan reports.

What inputs are needed to build a workflow recovery plan?

It requires current execution state and event history from workflow-state-manager outputs, continuity and blocker records from project-handoff outputs, plus recovery objectives, safety constraints, and allowed retry boundaries.

Can a failed workflow be resumed when external side effects already occurred?

Yes, but only through a compensation-first plan. The Skill accounts for partial external side effects and requires explicit approval before destructive rollback, external compensation, or irreversible actions.

When should I not use automated workflow recovery analysis?

Do not use it for normal planning of new workflows; it is scoped to interrupted, crashed, or partially applied executions. It also fails closed when execution history is incomplete or inconsistent rather than guessing a resume path.

Why does recovery analysis return a blocked status instead of a plan?

A blocked status is returned when no safe rollback or compensation path exists, or when unresolved side effects could corrupt state. The Skill never recommends resuming under those conditions and lists the approvals needed to proceed.