Damage Control
Recover safely when an agent session hits context limits so you do not duplicate work or contradict earlier decisions.
Overview
Damage Control is a journey-wide agent skill that reconstructs decision context when the context window is exhausted mid-session—usable whenever a solo builder needs to checkpoint and continue without replaying lost agen
Install
npx skills add https://github.com/athola/claude-night-market --skill damage-controlWhat is this skill?
- Stop-and-checkpoint recovery protocol with task list as durable ground truth outside the context window
- Symptom checklist: missing prior decisions, repeated work, invisible tool results, contradictory second-half outputs
- Explains why overflow is worse than a crash—no error surface, agent keeps running with amnesia
- Handoff summaries and safe continuation without re-deriving constraints agreed with the user
- Parent leyline:damage-control module; ~260-token procedural slice for infrastructure context recovery
- Recovery protocol Step 1: stop and checkpoint to durable anchors with task list as primary ground truth
- Parent module leyline:damage-control; SKILL frontmatter estimates ~260 tokens for this slice
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
Your agent keeps answering but no longer sees earlier tool results, agreements, or completed steps, so it duplicates work and contradicts itself with no error message.
Who is it for?
Long multi-step agent sessions where task lists or specs live outside the chat and you need a explicit overflow recovery ritual.
Skip if: Sessions that already ended cleanly with an approved handoff document, or one-shot tasks with no prior in-session decisions worth reconstructing.
When should I use this skill?
Context window is near or at its limit and the agent cannot reliably recall earlier decisions, completed steps, or rationale—especially when it redoes work or contradicts the first half of the session.
What do I get? / Deliverables
You stop safely, persist current state to durable anchors like the task list, and resume with a handoff summary so the next stretch of work aligns with prior decisions.
- Checkpoint of known state anchored to task list or external doc
- Handoff summary for safe continuation without replaying lost context
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
After a long API integration thread, tool results scroll out of view and the agent proposes re-implementing an endpoint you already merged.
During a security review pass, the agent forgets severity tiers agreed earlier and you checkpoint findings to the task list before continuing.
While triaging production errors, contradictory remediation advice appears because early log analysis left the window.
Sprint tasks drift when the agent cannot locate rationale for scope cuts made hours earlier in the same session.
How it compares
Use as structured overflow recovery instead of hoping the model remembers—or blindly continuing chat after contradictory outputs.
Common Questions / FAQ
Who is damage-control for?
Solo and indie builders who run lengthy agent coding sessions and need a repeatable way to survive context window limits without silent rework.
When should I use damage-control?
Use it when the window is near capacity or symptoms show—missing earlier decisions, repeated completed work, invisible tool output, or contradictory answers—in Build, Ship, or Operate sessions alike.
Is damage-control safe to install?
It is procedural guidance only; review the Security Audits panel on this Prism page before installing any skill from the repo.
SKILL.md
READMESKILL.md - Damage Control
# Context Overflow ## When This Module Applies Use this module when the context window is near or at its limit and the agent can no longer reliably recall earlier decisions, completed steps, or the rationale behind current state. Symptoms: - Agent references a decision it cannot locate in the current window - Agent re-does work already done in the same session - Earlier tool call results are no longer visible - The session produces contradictory outputs (second half disagrees with first half) ## Why Context Overflow Is Dangerous Unlike a crash, context overflow produces no error. The agent continues running but loses access to prior context. It may: - Re-implement work already completed, creating duplicates - Make decisions that contradict earlier reasoning - Omit dependencies established in the now-invisible portion - Silently discard constraints agreed on with the user ## Recovery Protocol ### Step 1: Stop and checkpoint Before taking any further actions, write the current known state to a durable anchor. The task list is the primary anchor: it is outside the context window and survives session boundaries. For each task currently `in_progress`: 1. Record the last completed step in the task description 2. List any decisions made that affect downstream tasks 3. List any constraints or agreed deviations from the plan ### Step 2: Establish ground truth from durable sources Context is gone. Recover state from sources that are not inside the window: | Source | What it tells you | |---|---| | Task list | Which tasks are done, in progress, or pending | | `git log --oneline -20` | What was committed and when | | `git diff HEAD` | Uncommitted work in progress | | `git status` | Staged vs. unstaged state | | Test results | Whether the last committed state is valid | Do not trust the agent's recall of anything not confirmed by one of these sources. ### Step 3: Summarize for continuation Before ending the session or handing off to a new agent, write a handoff summary. Place it as a comment in the task description or in a temporary scratch note that the next agent can read at session start: ``` ## Handoff Summary — [timestamp] ### Completed this session - [task IDs and one-line description of what was done] ### Decisions made (not yet committed anywhere) - [decision: rationale] ### In-progress state - Task T042: completed steps 1-3; step 4 (write tests) not yet started - Files modified but not committed: src/auth/token.py ### Constraints to carry forward - [any deviations agreed with human, constraints on implementation] ### Recommended next action - Resume T042 at step 4 ``` ### Step 4: Hand off or end session cleanly If handing off to a new agent: - Commit all completed work before handoff - Push the handoff summary to the task list - The new agent reads the handoff summary before starting work If ending the session: - Stash or commit any in-progress work - Do not leave staged changes without a note explaining them ### Recovering in the same session (partial overflow) If context is not fully exhausted but early reasoning is no longer visible: - Run `git log --oneline` to anchor what was committed - Re-read the task list to anchor task state - Proceed only with actions the current visible context can fully justify. Do not act on half-remembered prior context ## Exit Criteria - A handoff summary exists recording completed work, in-progress state, and decisions made - All completed work is committed or stashed with a descriptive message - The task list reflects the current completion status of every task touched this session - The next agent (or resumed