debug-log-slim

Estrellas12

Forks1

Actualizado11 de julio de 2026 a las 09:01

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).

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

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas·SOC 15-1253

SKILL.md

readonly

name	debug-log-slim
description	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).
version	0.1.0
license	MIT

debug-log-slim

Raw test/build output is mostly noise: hundreds of PASS/OK lines for every one line that actually matters. Don't paste it all into context — filter first.

Rule

Before showing test/build/lint output to the user or reasoning over it at length, reduce it to:

Every FAIL / ERROR / Exception / Traceback / assertion line.
A few lines of context around each (the stack frame or expected/received diff — usually 3–5 lines is enough to act on).
The final summary line (e.g. 12 passed, 3 failed), always kept verbatim.
Everything else collapsed into a single count, e.g. … 40 passing lines omitted … — never silently dropped without saying how much was cut.

How to apply it

If the HarnessTrim OpenCode adapter is installed, this happens automatically via tool.execute.before — no manual filtering needed, this skill is then just a fallback for contexts where the adapter isn't wired in.
Without the adapter: when a command produces long output, pipe it through a targeted filter before reading it in full — e.g. grep -E 'FAIL|ERROR|Exception' -A 5 (adjust the pattern to the test runner's failure markers) — rather than reading the entire raw log.
Never summarize-then-discard: if you filtered, the user should still be able to ask "show me the full log" and get it — filtering is about what enters reasoning context by default, not deleting the underlying artifact.

What NOT to filter out

Warnings that indicate a real (if non-fatal) problem — e.g. deprecation notices tied to the change just made.
Anything the user explicitly asked to see in full.

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

compact-handoff

giuliastro/HarnessTrim

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.

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	debug-log-slim
description	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).
version	0.1.0
license	MIT

debug-log-slim

Raw test/build output is mostly noise: hundreds of PASS/OK lines for every one line that actually matters. Don't paste it all into context — filter first.

Rule

Before showing test/build/lint output to the user or reasoning over it at length, reduce it to:

Every FAIL / ERROR / Exception / Traceback / assertion line.
A few lines of context around each (the stack frame or expected/received diff — usually 3–5 lines is enough to act on).
The final summary line (e.g. 12 passed, 3 failed), always kept verbatim.
Everything else collapsed into a single count, e.g. … 40 passing lines omitted … — never silently dropped without saying how much was cut.

How to apply it

If the HarnessTrim OpenCode adapter is installed, this happens automatically via tool.execute.before — no manual filtering needed, this skill is then just a fallback for contexts where the adapter isn't wired in.
Without the adapter: when a command produces long output, pipe it through a targeted filter before reading it in full — e.g. grep -E 'FAIL|ERROR|Exception' -A 5 (adjust the pattern to the test runner's failure markers) — rather than reading the entire raw log.
Never summarize-then-discard: if you filtered, the user should still be able to ask "show me the full log" and get it — filtering is about what enters reasoning context by default, not deleting the underlying artifact.

What NOT to filter out

Warnings that indicate a real (if non-fatal) problem — e.g. deprecation notices tied to the change just made.
Anything the user explicitly asked to see in full.