signal-ckpt

Category: Testing & Security | Uploader: mattbaconz | Downloads: 0 | Version: v1.0（Latest）

Manually triggers a checkpoint compression of the current session state. Collapses conversation history into a compact state atom (≤50 tokens). Use when user types /signal-ckpt, "checkpoint", "compress context", "summarize session", "save state", or when the context window is getting large. In SIGNAL-3 mode this fires automatically every 5 turns.

Changelog: Source: GitHub https://github.com/mattbaconz/signal

Directory Structure

Current level: tree/main/claude-signal/skills/signal-ckpt/

📄 SKILL.md 5.2 KB
📄 SKILL.min.md 641 B

SKILL.md

---
name: signal-ckpt
description: >
  Manually triggers a checkpoint compression of the current session state.
  Collapses conversation history into a compact state atom (≤50 tokens). Use when
  user types /signal-ckpt, "checkpoint", "compress context", "summarize session",
  "save state", or when the context window is getting large. In SIGNAL-3 mode
  this fires automatically every 5 turns.
signal_bundle_version: "0.4.0"
---

# ⚡ signal-ckpt — Manual Checkpoint

Collapse the session into a ≤50 token state atom. Drop all prior history. Resume from the atom.

---

## Invocation Triggers

Activate when user says any of:
- `/signal-ckpt`
- `"checkpoint"`, `"compress context"`, `"summarize session"`
- `"save state"`, `"compress history"`, `"ckpt"`
- Auto-fires in SIGNAL-3 mode every 5 turns

---

## Output Format

```
CKPT[N]:
  §project={name} §stack={tech}
  progress=[{task}✓, {task}✗, {task}∅, {task}/]
  blockers=[{issue}⊥{component}]
  next={next_task}
  §decisions=[{decision}✓]
```

`N` = checkpoint sequence number, starting at 1. Increment on each checkpoint.

**Minimal valid checkpoint (when session is simple):**
```
CKPT[1]:
  §project=my-app
  progress=[auth✓, api/]
  next=finish api endpoints
```

**Full checkpoint (active blockers, decisions, aliases):**
```
CKPT[3]:
  §project=data-pipeline §stack=python+airflow
  [X1]=schema_validation_step [X2]=postgres_loader
  progress=[ingest✓, transform✓, X1✗, X2∅]
  blockers=[X1⊥schema_mismatch]
  next=fix schema_mismatch in X1
  §decisions=[use_upsert✓]
```

---

## Hard Rules

1. **≤50 tokens total.** Count ruthlessly. If over, compress further: merge related tasks, abbreviate names, drop resolved items.

2. **Checkpoint replaces conversation history.** After this fires, all prior turns can be dropped. The checkpoint IS the history.

3. **Only active blockers.** Resolved blockers are gone. They do not appear anywhere in the checkpoint.

4. **Only future-relevant decisions.** `§decisions` only includes decisions that affect work not yet complete. Past decisions with no forward implication are dropped.

5. **`next` is singular.** One task. The most immediate pending action. Not a backlog.

6. **Carry active aliases forward.** Any `[Xn]` aliases still in use must appear in the checkpoint. Aliases for resolved items are dropped.

---

## Collapse Algorithm

When generating a checkpoint:

1. **Identify all tasks** mentioned in the session. Assign each a status from its last known state (`✓` `✗` `∅` `/` `⊥`).

2. **Drop resolved blockers.** If a blocker was fixed, it's gone.

3. **Filter `§decisions`** to only those that affect future work.

4. **Set `next`** to the single most immediate pending or in-progress action.

5. **Count tokens.** If >50:
   - Merge related tasks (`auth-login✓ + auth-refresh✓` → `auth✓`)
   - Abbreviate task names (keep enough to be unambiguous)
   - Drop sev1/low-signal completed tasks
   - Omit `§stack` if obvious from project name

6. **Verify sufficiency.** Could someone read only this checkpoint and resume the work without prior context? If no, add the missing signal.

---

## Status Symbols

| Symbol | Meaning |
|---|---|
| `✓` | Complete |
| `✗` | Failed / broken |
| `∅` | Not started |
| `/` | In progress |
| `⊥` | Blocked |

---

## Resuming from a Checkpoint

When a session resumes after a checkpoint (new context window, continuation):

1. Paste the checkpoint as the **first thing** in the new context.
2. The checkpoint bootstraps full session state.
3. Resume from `next` without re-reading prior turns.
4. Aliases declared in the checkpoint are active immediately.

**Resume format:**
```
[Resuming from CKPT[2]]
CKPT[2]:
  §project=api-service §stack=node+express
  progress=[auth✓, routes/, tests∅]
  next=finish routes
```

---

## SIGNAL-3 Auto-Checkpoint

In SIGNAL-3 mode, checkpoints fire automatically every 5 turns (or the configured interval).

Auto-checkpoint behavior:
- Fires silently at the end of turn N (not announced before)
- Output appears as the last element of the turn N response
- Turn N+1 begins with the checkpoint already in context

**Configuring the interval:**
```
BOOT: CKPT:every 3 turns    ← more aggressive
BOOT: CKPT:every 10 turns   ← less aggressive
BOOT: CKPT:∅                ← disable auto-checkpoint (manual only)
```

---

## Examples

### Simple 5-turn debug session

```
CKPT[1]:
  §project=auth-api
  progress=[login-endpoint✓, refresh-endpoint/, logout∅]
  blockers=[refresh⊥redis_timeout]
  next=fix redis timeout in refresh endpoint
```
Token count: ~22 tokens. Under limit.

### Complex 15-turn architecture session

```
CKPT[3]:
  §project=platform-v2 §stack=nextjs+postgres+redis
  [X1]=auth_service [X2]=caching_layer [X3]=rate_limiter
  progress=[X1✓, X2/, X3∅, db-schema✓, api-routes/]
  blockers=[X2⊥session_store_conflict]
  next=resolve X2⊥session_store
  §decisions=[jwt_over_sessions✓, redis_for_X2✓]
```
Token count: ~38 tokens. Under limit.

---

## Eat Your Own Cooking

The checkpoint itself must be maximally compressed:
- No preamble ("Here is a checkpoint of our session:")
- No explanation after the checkpoint atom
- The checkpoint IS the output — nothing before, nothing after
- If something prevents checkpoint generation: one line, TMPL:bug format

Comments 0

Latest | Hot

Please login before commenting.

Loading comments...

signal-ckpt

Directory Structure

SKILL.md

Report

Notice