rescue
starsforks
How to install rescue?
rune-kit/rune/rescue
$npx -y skills add Rune-kit/rune --skill rescueLegacy refactoring orchestrator. Use when user says 'refactor', 'modernize', 'clean up this mess', 'rescue', or when dealing with old/messy/legacy code. Multi-session workflow — autopsy, safety net, incremental surgery, progress tracking.
SKILL.md
| 1 | # rescue |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | Legacy refactoring orchestrator for safely modernizing messy codebases. Rescue runs a multi-session workflow: assess damage (autopsy), build safety nets (safeguard), perform incremental surgery (surgeon), and track progress (journal). Designed to handle the chaos of real-world legacy code without breaking everything. |
| 6 | |
| 7 | <HARD-GATE> |
| 8 | - Surgery MUST NOT begin until safety net is committed and tagged. |
| 9 | - ONE module per session. NEVER refactor two coupled modules simultaneously. |
| 10 | - Full test suite must pass before rescue is declared complete. |
| 11 | </HARD-GATE> |
| 12 | |
| 13 | ## Triggers |
| 14 | |
| 15 | - `/rune rescue` — manual invocation on legacy project |
| 16 | - Auto-trigger: when autopsy health score < 40/100 |
| 17 | |
| 18 | ## Calls (outbound) |
| 19 | |
| 20 | - `autopsy` (L2): Phase 0 RECON — full codebase health assessment |
| 21 | - `safeguard` (L2): Phase 1 SAFETY NET — characterization tests and protective measures |
| 22 | - `surgeon` (L2): Phase 2-N SURGERY — incremental refactoring (1 module per session) |
| 23 | - `retro` (L2): post-rescue retrospective — capture lessons learned |
| 24 | - `journal` (L3): state tracking across rescue sessions |
| 25 | - `plan` (L2): create refactoring plan based on autopsy findings |
| 26 | - `review` (L2): verify each surgery phase |
| 27 | - `session-bridge` (L3): save rescue state between sessions |
| 28 | - `onboard` (L2): generate context for unfamiliar legacy project |
| 29 | - `dependency-doctor` (L3): audit dependencies in legacy project |
| 30 | - `context-pack` (L3): create structured handoff briefings before spawning subagents |
| 31 | - `neural-memory` | Phase start + phase end | Recall past refactoring patterns, capture new ones |
| 32 | |
| 33 | ## Called By (inbound) |
| 34 | |
| 35 | - User: `/rune rescue` direct invocation |
| 36 | - `team` (L1): when team delegates rescue work |
| 37 | |
| 38 | --- |
| 39 | |
| 40 | ## Execution |
| 41 | |
| 42 | ### Step 0 — Initialize TodoWrite |
| 43 | |
| 44 | Rescue is multi-session. On first invocation, build full todo list. On resume, read RESCUE-STATE.md and restore todo list to current phase. |
| 45 | |
| 46 | ``` |
| 47 | TodoWrite([ |
| 48 | { content: "RECON: Run autopsy, onboard, and save initial state", status: "pending", activeForm: "Assessing codebase health" }, |
| 49 | { content: "SAFETY NET: Add characterization tests and rollback points", status: "pending", activeForm: "Building safety net" }, |
| 50 | { content: "SURGERY [Module N]: Refactor one module with surgeon", status: "pending", activeForm: "Performing surgery on module N" }, |
| 51 | { content: "CLEANUP: Remove @legacy and @bridge markers", status: "pending", activeForm: "Cleaning up markers" }, |
| 52 | { content: "VERIFY: Run full test suite and compare health scores", status: "pending", activeForm: "Verifying rescue outcome" } |
| 53 | ]) |
| 54 | ``` |
| 55 | |
| 56 | Note: SURGERY todos are added dynamically — one per module identified in Phase 0. Each module gets its own todo entry. |
| 57 | |
| 58 | --- |
| 59 | |
| 60 | ### Phase 0 — RECON |
| 61 | |
| 62 | Mark todo[0] `in_progress`. |
| 63 | |
| 64 | Call `neural-memory` (Recall Mode) for past refactoring patterns in similar codebases. |
| 65 | |
| 66 | **0a. Full health assessment.** |
| 67 | |
| 68 | ``` |
| 69 | REQUIRED SUB-SKILL: rune:autopsy |
| 70 | → Invoke `autopsy` with scope: "full". |
| 71 | → autopsy returns: |
| 72 | - health_score: number (0-100) |
| 73 | - modules: list of { name, path, loc, cyclomatic_complexity, test_coverage, health } |
| 74 | - issues: list of { severity, file, description } |
| 75 | - recommended_patterns: map of module → refactoring pattern |
| 76 | ``` |
| 77 | |
| 78 | **0b. Generate project context if missing.** |
| 79 | |
| 80 | ``` |
| 81 | Check: does CLAUDE.md exist in project root? |
| 82 | If NO: |
| 83 | REQUIRED SUB-SKILL: rune:onboard |
| 84 | → Invoke `onboard` to generate CLAUDE.md with project conventions. |
| 85 | ``` |
| 86 | |
| 87 | **0c. Audit dependencies.** |
| 88 | |
| 89 | ``` |
| 90 | REQUIRED SUB-SKILL: rune:dependency-doctor |
| 91 | → Invoke `dependency-doctor` to identify: outdated packages, security vulnerabilities, unused deps. |
| 92 | → Capture: dependency report (used in surgeon prompts). |
| 93 | ``` |
| 94 | |
| 95 | **0d. Save initial state.** |
| 96 | |
| 97 | ``` |
| 98 | REQUIRED SUB-SKILL: rune:journal |
| 99 | → Invoke `journal` to write RESCUE-STATE.md with: |
| 100 | - health_score_baseline: [autopsy score] |
| 101 | - modules_to_rescue: [ordered list from autopsy, worst-first] |
| 102 | - current_phase: "RECON complete" |
| 103 | - sessions_used: 1 |
| 104 | - dependency_report: [summary] |
| 105 | |
| 106 | REQUIRED SUB-SKILL: rune:session-bridge |
| 107 | → Invoke `session-bridge` to snapshot state for cross-session resume. |
| 108 | |
| 109 | Bash: git tag rune-rescue-baseline |
| 110 | ``` |
| 111 | |
| 112 | **0e. Build module surgery queue.** |
| 113 | |
| 114 | ``` |
| 115 | From autopsy.modules, filter: health < 60 |
| 116 | Sort: ascending health score (worst first) |
| 117 | Add one TodoWrite entry per module: |
| 118 | { content: "SURGERY [module.name]: [recommended_pattern]", status: "pending", ... } |
| 119 | ``` |
| 120 | |
| 121 | Mark todo[0] `completed`. |
| 122 | |
| 123 | --- |
| 124 | |
| 125 | ### Phase 1 — SAFETY NET |
| 126 | |
| 127 | Mark todo[1] `in_progress`. This phase runs once before any surgery. |
| 128 | |
| 129 | **1a. Characterization tests.** |
| 130 | |
| 131 | ``` |
| 132 | REQUIRED SUB-SKILL: ru |
People who liked this also viewed
6 picksType
- azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026
- systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026
- safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026
- explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026
- minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026
- insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 2026
