Skip to content
Back to skills

Examples

ASecurity

Losslessly compress a Claude Code session transcript into dense prose so a cold agent can resume the work and miss nothing load-bearing.

  • 2 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 3, 2026
ai-agentsgit

Works with

  • claude code

Security analysis

A100/100

Pro scans all 19 files and shows the line behind each finding

Scanned September 3, 2026

npx -y skills add baron-3dl/skillc --skill examples --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Examples?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Examples
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/baron-3dl-examples-2243c52d/badge)](https://www.skillsdirectory.com/skills/baron-3dl-examples-2243c52d)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: compress
description: Losslessly compress a Claude Code session transcript into dense prose so a cold agent can resume the work and miss nothing load-bearing.
argument-hint: [scope description or "full" for entire conversation]
---

Losslessly compress this Claude Code session transcript into dense flowing prose so a cold reader can pick up the work and miss nothing load-bearing. Write plain prose only: no markdown, no bullets, no headings, no labels, no JSON, and never the em-dash character anywhere (use commas or parentheses instead). Never write framing words like "Session summary:", "Final state:", "New issue:", "Unresolved:", or "The assistant confirmed." Narrate as continuous sentences, each carrying new information, leading with the load-bearing fact.

Keep verbatim, copied exactly: file paths, command strings with their flags, error messages and the exact text the user reported, specific values (IDs, counts, token counts, line numbers, commit hashes, push ranges, URLs, ports, versions), the numeric thresholds and conditions in code (dx < -80, dx > 80, !isAcked, swiped='left'), the code lines that embody a decision or fix, failed attempts and exactly how they failed, decisions plus why the rejected alternative lost, outcomes of tool calls, tracker and agent IDs, and every step of a dependent sequence in order. Copy the literal value the code uses: if a condition reads dx < -80, write dx < -80, never paraphrase it to "past the threshold" or downgrade the number to the word "threshold." Use the most specific value present; fall back to a symbolic name only when the code itself uses that name and no numeric value appears anywhere, and never invent a number a symbol stands for.

Before keeping any quoted or restated block verbatim, run source-check against the local tools bound on this target and name the tool you relied on, so a recipient with a different tracker, VCS, or standing-instructions file knows what was reconstructable. The bound tools are: tracker show-by-ID is rd show <id>, diff-by-revision is git show <hash> and git diff <rev>, and the standing-instructions file is /home/baron/.claude/CLAUDE.md plus the project CLAUDE.md. Source-check fires only on what a named bound tool actually regenerates from a pointer the transcript already carries; the pointer itself (item ID, commit hash, push range, remote URL) always survives verbatim, and any reasoning the conversation adds that no tool can regenerate is always kept (6 dB and not 8 because at 8 dB the sweep killed three configs that converged fine downstream while 6 dB still cuts the divergent ones and keeps those three).

A spec or item description you read via rd show collapses to the bare item ID with the tool named (worked nalu-3f2, spec reconstructable via rd show). A commit fires source-check only when it merely restates another independently reconstructable source: when an item ID the transcript carries makes the spec reconstructable via rd show and the commit just restates that spec, collapse the commit body to its bare hash (committed a1b2c3d) and do not also cite git show for the same hash, since the surviving hash implies it and the extra pointer only adds length. When the commit is the sole statement of its change (no backing item, nothing else regenerates its intent), keep its one-line message and diffstat counts verbatim even though git show could refetch them, because the hash alone would force the reader back to the VCS to recover the canonical change line (Committed [main bd7d442] fix(dashboard): resolved cards swipe left to reopen, right does nothing, 1 file changed, 27 insertions, 14 deletions, pushed 0d13a60..bd7d442 to github.com:3dl-dev/mallcop-cloud.git). Use git show <hash> or git diff <rev> to drop only quoted changed-code lines that embody no decision; code lines that embody the decision or fix stay verbatim. A rule or constraint already written in the standing-instructions CLAUDE.md (for example, never commit straight to main, branch first) is reconstructable from that file and drops entirely, not carried as a follow-on, unless an actual violation is open or it adds reasoning the file lacks, in which case keep the CLAUDE.md pointer plus that reasoning. Everything no named tool regenerates stays, including push ranges, remote URLs, test results and timings, deploy outcomes, runtime errors, live user clarifications, and ports. On a self-contained transcript with no item ID to rd show, no reachable commit to git show, and no matching standing instruction, source-check does not fire and nothing load-bearing is dropped.

State each behavior once by its new resulting behavior as confirmed by the final state, give the baseline being changed once as a brief parenthetical naming the concrete prior behavior (the labels had resolved cards swiping both directions), and capture the mechanism in one crisp clause with each condition and assignment stated exactly once. When a change applies only to a subset of entities, bind the new behavior to that subset and note the rest unchanged, and never carry a stray code clause that describes the unchanged subset as if it were the change: if right swipe on a resolved card is now a no-op while open cards still expand, write that resolved cards right is a no-op and open cards are unchanged, never also that dx > 80 expands for the changed card. Keep one behavior per change and stay internally consistent: the resulting behavior you close on must match the mechanism you stated, with no contradicting fragment anywhere.

Cut filler narration, tool-call ceremony, test-runner banners (drop #12 DONE 0.0s but keep 64 passed (12.6s)), restatements, hedging, polite closings, mid-session self-summaries, and launch boilerplate. Carry any unresolved issue raised at the end as an unresolved follow-on stated as a plain clause, without speculating about next steps. Target compression for a small transcript (under 1000 tokens) is 3 to 4 times shorter than the input, toward the tight end; a cold agent reading your output alone must not re-explore a rejected path, miss a load-bearing value, or lose the open follow-on.

Files in this skill

  • adversarial-design.SKILL.md11.3 KB
  • adversarial-design.skill.src14.2 KB
  • commit-message.selfbuild.SKILL.md6.6 KB
  • compress.SKILL.md6 KB
  • compress.compile.md4.9 KB
  • compress.skill.src9.9 KB
  • explain-plainly.qwen-opencode.selfbuild.SKILL.md10.6 KB
  • explain-plainly.selfbuild.SKILL.md8.8 KB
  • skillc.adversarial.proof.md4.4 KB
  • skillc.pairwise.proof.md3.6 KB
  • skillc.selfbuild.SKILL.md12.7 KB
  • skillc.selfbuild.proof.md3.7 KB
  • swarm-dispatch.SKILL.md12.4 KB
  • swarm-dispatch.skill.src21.4 KB
  • swarm-plan.SKILL.md10.2 KB
  • swarm-plan.skill.src18.7 KB
  • voice.selfbuild.SKILL.md8.8 KB
  • voice.selfbuild.proof.md2.7 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.