Resurrection
Bring a dead system, service, or environment back to full operation from backups and artifacts.
What This Skill Does
Use this spell when a system has truly died — crashed, deleted, corrupted beyond repair — and needs to be rebuilt from whatever remains. Distinct from Speak with Dead, which queries dead systems for knowledge; Resurrection actually revives them.
In this grimoire, Resurrection is treated as a literal spell with a prototype delivery profile.
Canonical reference input: Resurrection (spell).
When To Use
- A production system has crashed or been destroyed and needs to be restored from backups or artifacts.
- A deleted repository, database, or environment needs to be rebuilt from available evidence.
- The system was alive, it died, and the goal is to bring it back — not to understand it, but to restore it.
Prerequisites
- No extra runtime dependencies beyond Hermes Agent and the normal toolset for this session.
Procedure
- Restate the target, the success condition, and any no-touch boundaries before taking action.
- Assess what remains: backups, artifacts, logs, snapshots, cached copies, and configuration fragments.
- Determine the most complete and recent restoration path from available materials.
- Execute the resurrection step by step, verifying each restored component before proceeding.
- Confirm the system is alive and functional, and report any components that could not be restored.
- Stop for explicit confirmation before taking a live action that changes access, triggers an alert, or touches a real system boundary.
- Package the result as the deliverables below, with confidence, assumptions, and unresolved risk called out explicitly.
Deliverables
- A restored and functional system, or the closest achievable approximation.
- A detailed log of every restoration step taken.
- A list of components that could not be recovered and their impact on system function.
Pitfalls / Guardrails
- Call out the glue, permissions, or missing infrastructure before you imply this is fully operational.
- Verify backup integrity before attempting restoration — do not restore from corrupted sources.
- Never overwrite live data with restoration data without explicit user confirmation.
- Log every step. Resurrection is high-stakes surgery and must be fully auditable.
Verification
- Check that the result includes every deliverable promised above.
- Check that confirmed facts, assumptions, and inferences are visibly separated.
- Check that the exact live target, confirmation gate, and rollback or recovery path are explicit.
- Check that any missing glue code, permissions, or future work is labeled before the skill is treated as ready.
Example Invocation
/resurrection bring this dead system back from whatever backups and artifacts remain, verifying each step
1---2name: resurrection-23description: Use this spell when a system has truly died — crashed, deleted, corrupted beyond repair — and needs to be rebuilt from whatever remains. Distinct from Speak with Dead, which queries dead systems for knowledge; Resurrection actually revives them.4license: CC0-1.05---6# Resurrection7Bring a dead system, service, or environment back to full operation from backups and artifacts.8## What This Skill Does9Use this spell when a system has truly died — crashed, deleted, corrupted beyond repair — and needs to be rebuilt from whatever remains. Distinct from Speak with Dead, which queries dead systems for knowledge; Resurrection actually revives them.10In this grimoire, Resurrection is treated as a literal spell with a prototype delivery profile.11Canonical reference input: Resurrection (spell).12## When To Use1314- A production system has crashed or been destroyed and needs to be restored from backups or artifacts.15- A deleted repository, database, or environment needs to be rebuilt from available evidence.16- The system was alive, it died, and the goal is to bring it back — not to understand it, but to restore it.1718## Prerequisites1920- No extra runtime dependencies beyond Hermes Agent and the normal toolset for this session.2122## Procedure23241. Restate the target, the success condition, and any no-touch boundaries before taking action.252. Assess what remains: backups, artifacts, logs, snapshots, cached copies, and configuration fragments.263. Determine the most complete and recent restoration path from available materials.274. Execute the resurrection step by step, verifying each restored component before proceeding.285. Confirm the system is alive and functional, and report any components that could not be restored.296. Stop for explicit confirmation before taking a live action that changes access, triggers an alert, or touches a real system boundary.307. Package the result as the deliverables below, with confidence, assumptions, and unresolved risk called out explicitly.3132## Deliverables3334- A restored and functional system, or the closest achievable approximation.35- A detailed log of every restoration step taken.36- A list of components that could not be recovered and their impact on system function.3738## Pitfalls / Guardrails3940- Call out the glue, permissions, or missing infrastructure before you imply this is fully operational.41- Verify backup integrity before attempting restoration — do not restore from corrupted sources.42- Never overwrite live data with restoration data without explicit user confirmation.43- Log every step. Resurrection is high-stakes surgery and must be fully auditable.4445## Verification4647- Check that the result includes every deliverable promised above.48- Check that confirmed facts, assumptions, and inferences are visibly separated.49- Check that the exact live target, confirmation gate, and rollback or recovery path are explicit.50- Check that any missing glue code, permissions, or future work is labeled before the skill is treated as ready.5152## Example Invocation53```text54/resurrection bring this dead system back from whatever backups and artifacts remain, verifying each step55```