| name | greater-restoration |
| description | Lesser Restoration = one thing is wrong, fix it directly (reset a flag, clear a cache, remove a curse).
Greater Restoration = many things are wrong because they decayed together over time, and fixing one thing without fixing the others will fail. |
| user-invocable | true |
Greater Restoration
Undo deep corruption and restore a system degraded by accumulated damage.
Overview
Greater Restoration is interpreted here as a metaphorical spell with a shipping-now execution model.
Canonical source: Greater Restoration (spell)
Provider target: OpenClaw
When To Use
- Activate Greater Restoration when the user describes systemic degradation that accumulated over time and requires a comprehensive, multi-step restoration plan — not a hotfix.
- Time + decay: "over N months/years", "accumulated", "gradually degraded", "drift", "bloat", "sprawl"
- Multiplicity: multiple related problems listed (inconsistent configs, orphaned resources, stale artifacts)
- Scope words: "comprehensive", "systematic", "full audit", "restore to health", "clean and restore"
- Failure of incremental fixes: "no single fix will work", "triage is insufficient", "band-aids made it worse"
- Domains: schema drift, tech debt, IaC drift, alert fatigue, bloated images, tangled dependencies, stale flags, decayed docs, corrupted data pipelines
Workflow
- Scope the degradation: Inventory all affected subsystems. How many? How interconnected? What does "healthy" look like?
- Find the root cause(s): What introduced the decay? Is the cause still active (e.g., a broken CI step still running, a misconfig still applied)?
- Design the restoration plan: Ordered steps with dependencies. What must be fixed first? What can be parallelized? Include verification checkpoints between stages.
- Execute with checkpoints: Do NOT batch all changes without verification. Each stage must confirm improvement before proceeding.
- Post-restoration health check: Confirm the system is back to full function. Document what changed and how to prevent recurrence.
Deliverables
- A restoration plan: ordered steps to undo accumulated damage.
- Root-cause identification: what caused the degradation and how to prevent recurrence.
- A post-restoration health check confirming the system is back to full function.
Guardrails
- Do not use for: Single incident/hotfix: "API crashing after deploy", "null pointer exception" → route to Cure Wounds or Lesser Restoration
- Do not use for: Simple toggle/reset: "circuit breaker tripped", "flag stuck enabled" → Lesser Restoration
- Do not use for: Resurrection from backup: "deleted account, restore from backup" → different spell (resurrection/backup-restore)
- Do not use for: Migration/relocation: "move from Heroku to AWS" → not restoration, it's relocation
- Do not use for: Self-healing/continuous: "auto-restart pods, maintain 99.99% uptime" → ongoing automation, not one-time restoration
- Do not use for: Preventive maintenance: "add monitoring", "set up linting" → proactive, not restorative
Default Invocation
Use $greater-restoration to assess this [system/codebase/database] for accumulated damage and design a comprehensive restoration plan.
