debug-log-slim

Stars12

Forks1

UpdatedJuly 11, 2026 at 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).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

giuliastro

giuliastro/HarnessTrim

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·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.

More from this repository

same repository

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.