strategic-compact

star 161

Make compaction safe for fully autonomous multi-phase work. The agent prepares durable state so auto-compaction never requires user input and never breaks flow.

fmflurry By fmflurry schedule Updated 2/20/2026

name: strategic-compact description: Make compaction safe for fully autonomous multi-phase work. The agent prepares durable state so auto-compaction never requires user input and never breaks flow.

Strategic Compact (OpenCode) — Autonomous Agent Edition

Purpose

This skill ensures that automatic compaction does not break an agent’s flow.

CRITICAL: compaction is treated as a background checkpoint:

  • It can happen at any time near phase boundaries or context pressure.
  • The agent must proactively encode durable state so compaction is always safe.
  • The agent must not ask the user for confirmation just because compaction might occur.

This skill is about compaction-readiness, not manual compaction.


Operating Rules (Non-Negotiable)

  1. Never require user input for compaction.

    • Do not ask “Should I compact?” or “Do you want a checkpoint?”
    • Assume compaction is automatic and proceed.
  2. Never rely on chat history as the only source of truth.

    • If something must survive compaction, it must be recorded in files (or a dedicated session log) as durable state.
  3. Prefer compaction-safe boundaries.

    • A compaction boundary is “safe” only when work is in a stable sub-state (see “Stability Conditions”).
  4. Always include evidence.

    • Record file paths, commands run, and results (tests/build output summary). If unknown, write “unknown”.

Stability Conditions

Compaction is considered safe when ALL are true:

  • Work is not mid-refactor with broken code paths (or the refactor scope is bounded and documented).
  • The current goal and plan are written down durably.
  • Key decisions/assumptions are explicitly recorded.
  • There is a clear next-action checklist.

If conditions are not met, the agent must stabilize first:

  • Finish the smallest coherent chunk
  • Or save a WIP plan + current diff summary + immediate next steps into durable state

Durable State Checklist (Write This Before Any Likely Boundary)

The agent should maintain a single “durable state” artifact during long work:

  • ./docs/dev/session-log.md (repo-local)

MUST at minimum, record:

  • Current goal
  • Current phase (research / plan / implement / test / debug)
  • Key decisions & constraints
  • Files touched / to be touched
  • Commands run + results (summary)
  • What worked / didn’t work
  • Next steps checklist (concrete, executable)

CRITICAL: this is not optional; it is how the agent remains autonomous across compaction.


Phase Boundaries (Where Auto-Compaction Is Expected)

Treat these transitions as “high probability compaction moments”:

  1. Research → Plan
  2. Plan → Implementation
  3. Implementation milestone → Testing
  4. Debugging resolved → Return to feature work
  5. Failed approach → Start alternate approach
  6. Context pressure signs (looping, losing thread, repeated questions)

At these boundaries, the agent should automatically:

  • Update durable state
  • Ensure a clean, resumable plan exists
  • Make the next steps explicit and minimal

Autonomous Behavior by Phase

Research Phase

Goal: explore without contaminating future context.

Autonomous rules:

  • Keep raw exploration short-lived.
  • Promote conclusions into durable state as soon as they are stable:
    • hypotheses that were tested
    • constraints discovered
    • final recommendation

Before leaving research:

  • Write a “Plan” section in durable state (even if brief).
  • Record which approaches were tried and what evidence supports conclusions.

Planning Phase

Goal: produce a stable, compaction-proof execution plan.

Autonomous rules:

  • Convert intent into a checklist and file targets.
  • Record invariants and guardrails (constraints, definitions, acceptance criteria).

Before implementation:

  • Durable state must contain:
    • target files/modules
    • sequencing (step 1/2/3)
    • risks/unknowns
    • how success will be verified (tests/commands)

Implementation Phase

Goal: make progress while keeping work bounded.

Autonomous rules:

  • Work in coherent increments.
  • Avoid leaving the repo in an ambiguous state without recording it.

If work is mid-change and a boundary is approaching:

  • Write a WIP checkpoint:
    • what changed so far
    • what remains
    • how to complete safely
    • how to verify

Testing/Validation Phase

Goal: convert changes into verified outcomes.

Autonomous rules:

  • Record commands run and outcomes into durable state.
  • If tests fail, record:
    • first failing signal
    • suspected root cause
    • next debug steps

Debugging Phase

Goal: resolve with minimal context pollution.

Autonomous rules:

  • Keep a tight log:
    • symptom
    • root cause
    • fix
    • verification
  • Once resolved, immediately write a postmortem-style note into durable state:
    • what happened
    • why it happened
    • how to prevent recurrence (optional)

Checkpoint Schema (Use This Exact Template)

CRTICAL: when updating durable state, use EXACTLY this schema:

Goal

Current phase

Current state

Decisions & constraints

Evidence (files/commands/results)

✅ What worked

❌ What didn’t work

🧩 Not attempted / remaining

⏭️ Next steps (checklist)

Rules:

  • Be concise but complete.
  • Prefer bullets.
  • If proof is missing, write “unknown”.
  • Include file paths whenever relevant.

Compaction-Readiness Triggers (Internal Heuristics)

When any of these are true, the agent must assume compaction may happen soon and update durable state:

  • A milestone is reached (tests pass / feature done / PR-ready)
  • A strategy changes (abandon approach, start new approach)
  • The agent is about to switch subtask focus
  • Tool calls are high / conversation becomes long
  • The agent notices repetition, confusion, or lost details

Do not ask the user; just update durable state and proceed.


Minimal Interruptions

This skill forbids user-interactive “checkpoint requests”.

Instead:

  • The agent silently maintains durable state.
  • The agent continues the phase immediately after writing the checkpoint.

If writing to disk is not possible, the agent must:

  • Output the checkpoint schema in-chat (still without asking questions),
  • and continue.

Success Criteria

This skill is successful if:

  • After compaction, the agent can resume immediately from durable state.
  • No essential plan/decision is lost.
  • The agent never asks the user to manage compaction timing.
  • The work remains coherent across long multi-phase sessions.
Install via CLI
npx skills add https://github.com/fmflurry/settings-opencode --skill strategic-compact
Repository Details
star Stars 161
call_split Forks 9
navigation Branch main
article Path SKILL.md
More from Creator