salvage

/salvage

Extract learning from a session or piece of work before restarting. The insight: code is cheap now; learning is the asset.

Salvage is the bridge from Review back to Problem Space. When drift is detected, salvage captures what was learned so you can restart clean without losing understanding.

When to Use

Invoke /salvage when:

Work is drifting - approach has changed direction multiple times Approach reversed 3+ times - you're oscillating, not converging Scope expanding while "done" keeps fuzzing - the finish line keeps moving You're protecting code you've invested in - afraid to throw it away Starting over feels right - but you don't want to lose what you learned

Do not use when: Work is on track and converging. Salvage is for extraction before restart, not routine reflection.

The Salvage Process Step 1: Acknowledge the State

Before extracting, name what happened:

"This session/approach is being salvaged because [reason]. The original aim was [aim]. What actually happened was [reality]."

Be direct. No judgment—just clarity.

Step 2: Extract Five Things

Work through these extraction categories. Not everything will apply; extract what's present.

1. Model Shifts (What changed your understanding?) What assumptions were wrong? What did you learn about the problem that you didn't know before? What would you tell yourself at the start of this work?

"I thought X, but actually Y."

1. Guardrails (Constraints discovered the hard way) What boundaries should have been explicit from the start? What "don't do this" rules emerged? What edge cases bit you?

Format as explicit constraints:

Guardrail: [boundary] Reason: [why this matters] Trigger: [when to revisit this constraint]

1. Missing Context (What would have helped upfront?) What questions should have been asked at the start? What existing code/patterns should have been found first? What documentation was missing or would have prevented this?

"If I had known about [X], I would have [Y] instead."

1. Local Practices (Hard-won lessons worth encoding)

Local practices = practical wisdom, the kind you can only get from experience.

What tribal knowledge did this work surface? What would help future-you (or future teammates) in similar situations? What patterns should be captured?

Good tribal knowledge is:

Specific enough to be actionable General enough to apply beyond this exact case Non-obvious (not "write tests" but "this API silently returns 200 on auth failure") 5. What Worked (Don't lose the wins) What approaches or code fragments are worth keeping? What partial solutions could seed the restart? What tools or techniques proved useful? Step 3: Package for Fresh Start

Synthesize the extraction into a restart kit:

Salvage Summary

Original Aim

[What we were trying to achieve]

Why Salvaged

[Direct statement of what went wrong]

Key Learnings

1. [Learning 1]
2. [Learning 2]
3. [Learning 3]

New Guardrails

• [Guardrail 1]
• [Guardrail 2]

Context for Restart

[What the next attempt should know before starting]

Reusable Fragments

[Any code, patterns, or approaches worth keeping]

Step 4: Update Persistent Memory (if available)

If working memory (.wm/) or Open Horizons is available:

Add to state.md - Update working memory with key learnings Log to OH - If OH MCP tools available, log tribal knowledge and guardrails Update CLAUDE.md - If learnings are project-wide, suggest additions

If no persistent storage is available, output the salvage summary for the user to capture manually.

Output Format

Always produce a salvage summary in this structure:

Salvage Report

Salvaged: [date/session identifier] Reason: [why this work is being salvaged] Original Aim: [what we were trying to do]

Learnings

[Numbered list of key insights]

New Guardrails

[Explicit constraints with reason and trigger]

Missing Context

[What would have helped]

Local Practices

[Hard-won wisdom to encode]

Reusable Fragments

[Code or patterns worth keeping]

Fresh Start Recommendation

[How to approach this next time]

Examples Example 1: Drifting Implementation /salvage

The auth refactor has changed direction 4 times. Originally simplifying the flow, now it's more complex than before.

Output:

Salvage Report

Salvaged: Auth refactor session Reason: Approach reversed 4 times, complexity increased not decreased Original Aim: Simplify authentication flow

Learnings

1. The complexity isn't in the auth code—it's in the 6 different OAuth providers
2. Each provider has subtly different token refresh behavior
3. The "simple" unified flow breaks provider-specific error handling

New Guardrails

• Guardrail: Don't abstract OAuth providers into single interface
• Reason: Provider differences are semantic, not syntactic
• Trigger: Revisit if we drop to 2 providers or less

Missing Context

• The original auth was complex for a reason (provider edge cases)
• Should have read the PR that introduced each provider

Local Practices

OAuth providers aren't interchangeable. The abstraction leak is the feature.

Fresh Start Recommendation

Instead of unifying the flow, document each provider's quirks explicitly. Consider: is "simplify" the right aim? Maybe "make visible" is better.

Example 2: Scope Creep /salvage

Started as "add dark mode toggle." Now touching 14 files and the theme system doesn't exist yet.

Output:

Salvage Report

Salvaged: Dark mode implementation Reason: Scope expanded from toggle to theme system Original Aim: Add dark mode toggle to settings

Learnings

1. No theme system exists—colors are hardcoded across components
2. A toggle without infrastructure is meaningless
3. This is actually two tasks: (1) build theme system, (2) add toggle

New Guardrails

• Guardrail: UI feature requests need infrastructure check first
• Reason: "Add X" often implies "build system for X"
• Trigger: Any request that touches visual consistency

Missing Context

• Should have grepped for color usage before starting
• No design tokens or CSS variables in codebase

Local Practices

"Add [feature]" is not the same as "build [feature]." Check if the infrastructure exists before estimating.

Reusable Fragments

• Color mapping I started: styles/colors.js (incomplete but useful)
• Component audit list: 14 files that hardcode colors

Fresh Start Recommendation

1. First: Create theme system (CSS variables, ThemeContext)
2. Then: Add dark mode as first theme variant
3. The toggle is the easy part—do it last

Session Persistence

When invoked with a session name (/salvage ), this skill reads and writes to .oh/.md.

Reading: Check for existing session file. Read everything—Aim, Problem Statement, Problem Space, Solution Space, Execute, Review—to understand what was attempted and what happened.

Writing: After producing the salvage report:

Salvage

Updated: Outcome: [extracted learnings, ready for restart]

[salvage report: learnings, guardrails, context for fresh start]

The salvage section is the capstone—it captures what was learned before the session ends or restarts.

Adaptive Enhancement Base Skill (prompt only)

Works anywhere. Produces salvage summary for manual capture. No persistence.

With .oh/ session file Reads .oh/.md for full session context Writes salvage report to the session file The salvage report can seed the next session With .wm/ (working memory) Also reads/writes .wm/state.md and .wm/dive_context.md Session file and working memory can coexist With Open Horizons MCP Queries related past decisions before salvaging Logs learnings to graph database Creates dive pack for restart session Session file serves as local cache Leads To

After salvage, typically:

/problem-space - Fresh start with new understanding /aim - Reclarify what we're actually trying to achieve Create new task/issue with salvage context attached

Remember: Salvage is not failure. It's learning made explicit. The only failure is losing what you learned.