compact-handoff

Estrellas12

Forks1

Actualizado11 de julio de 2026 a las 09:09

This skill should be used when a session is being compacted/summarized (context is full or the user runs a compact command), or when writing any handoff summary that a later session or subagent will continue from. Defines what to preserve versus drop so the continuation doesn't waste tokens re-reading files and re-deriving state. Part of the HarnessTrim token-economy stack; the OpenCode adapter injects this guidance automatically via experimental.session.compacting.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

giuliastro

giuliastro/HarnessTrim

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	compact-handoff
description	This skill should be used when a session is being compacted/summarized (context is full or the user runs a compact command), or when writing any handoff summary that a later session or subagent will continue from. Defines what to preserve versus drop so the continuation doesn't waste tokens re-reading files and re-deriving state. Part of the HarnessTrim token-economy stack; the OpenCode adapter injects this guidance automatically via experimental.session.compacting.
version	0.1.0
license	MIT

compact-handoff

A compaction summary is the seed context for everything that follows. If it drops the wrong things, the next turns re-read files, re-run searches, and re-decide settled questions — spending far more tokens than the summary ever saved. Optimize the summary for resumption, not brevity.

Preserve

The task and its acceptance criteria — what "done" means, verbatim if the user stated it.
Decisions made and alternatives rejected — with the reason, so they aren't re-litigated.
Hard-won specifics — exact file paths, symbol names, commands that worked, config values, version numbers, API signatures discovered. These are the expensive-to-rediscover facts.
Current state — what is done, what is verified (and how), what is still failing and the last error seen.

Drop

Step-by-step narration of what was already done ("first I opened X, then I ran Y").
Raw tool output that has already been acted on (test logs, file dumps, search results).
Anything trivially reconstructable from the current diff or a single cheap command.
Restatements of the codebase's structure that the next session can read directly.

Shape

Write the summary as short labeled sections (Task / Decisions / Key facts / State), not prose. A resuming agent should be able to act from it without re-reading the whole transcript.

Más de este repositorio

mismo repositorio

delegate-bulk

giuliastro/HarnessTrim

This skill should be used when deciding whether to hand volumetric or noisy work to an isolated subagent (or another harness) instead of doing it in the main context — e.g. reading many files, digesting long logs/docs, wide searches, or bulk mechanical generation. It gives the rule for when isolation saves tokens versus when it just multiplies them. Part of the HarnessTrim token-economy stack.

2026-07-1112

scaffold-fast

giuliastro/HarnessTrim

This skill should be used for mechanical, low-novelty coding work — generating boilerplate, wiring up a component from an existing pattern, adding a CRUD endpoint like the others, writing repetitive tests, or applying a rote transformation across files. It keeps reasoning effort low and output terse for work whose shape is already decided. Part of the HarnessTrim token-economy stack; the lean-scaffold preset pairs it with low reasoning effort.

2026-07-1112

debug-log-slim

giuliastro/HarnessTrim

This skill should be used before pasting, printing, or otherwise embedding test-runner output, build logs, or CI output into the conversation — whenever a test suite, linter, or build was just run and its raw output is large. Filters logs down to failure/error signal before they enter context. Part of the HarnessTrim token-economy stack (see packages/core/src/reducers/test-output-slim.ts for the reference implementation the OpenCode adapter automates this with).

2026-07-1112

delta-response

giuliastro/HarnessTrim

This skill should be used for every response produced in a coding harness (Claude Code, Codex, OpenCode, Pi) — not only when explicitly requested. Enforces terse, structured, information-dense output instead of narrated verbosity, to cut output-token cost. Part of the HarnessTrim token-economy stack (see delta-response/references/examples.md for before/after samples).

2026-07-1112

review-delta

giuliastro/HarnessTrim

This skill should be used when asked to review code, review a pull request, or review a diff. Focuses the review on problems worth fixing rather than restating or summarizing what changed. Part of the HarnessTrim token-economy stack.

2026-07-1112

name	compact-handoff
description	This skill should be used when a session is being compacted/summarized (context is full or the user runs a compact command), or when writing any handoff summary that a later session or subagent will continue from. Defines what to preserve versus drop so the continuation doesn't waste tokens re-reading files and re-deriving state. Part of the HarnessTrim token-economy stack; the OpenCode adapter injects this guidance automatically via experimental.session.compacting.
version	0.1.0
license	MIT

compact-handoff

Preserve

The task and its acceptance criteria — what "done" means, verbatim if the user stated it.
Decisions made and alternatives rejected — with the reason, so they aren't re-litigated.
Hard-won specifics — exact file paths, symbol names, commands that worked, config values, version numbers, API signatures discovered. These are the expensive-to-rediscover facts.
Current state — what is done, what is verified (and how), what is still failing and the last error seen.

Drop

Step-by-step narration of what was already done ("first I opened X, then I ran Y").
Raw tool output that has already been acted on (test logs, file dumps, search results).
Anything trivially reconstructable from the current diff or a single cheap command.
Restatements of the codebase's structure that the next session can read directly.

Shape

Write the summary as short labeled sections (Task / Decisions / Key facts / State), not prose. A resuming agent should be able to act from it without re-reading the whole transcript.