Signoff

/signoff — structured end-of-session ritual

Run this when the user intentionally wraps a session. Four core steps, none optional. Each step writes to durable state so the next session — yours or another agent's — can pick up cold.

The core insight: sessions don't fail at the start, they fail at the end. An unstructured ending means the next cold start re-derives everything from scratch. This skill makes the ending mechanical so the next beginning is instant.

When to invoke

The user types any of:

• /signoff
• wrap up
• update progress
• end session
• i'm stepping away
• let's wrap
• before I head out

Also invoke when:

• A meaningful build just completed (milestone hit, deploy shipped) and the conversation is naturally winding down
• The user message contains both "thanks" + a goal-state phrase ("that's it for now", "looks good")

DO NOT invoke when

• Mid-build with open todos
• The user asked an exploratory question and is still iterating
• The session is fewer than ~5 turns old (nothing to capture yet)

Auto-signing-off when the user didn't actually ask is worse than not having the skill. Mid-build "let me check something" is not a signal. The trigger phrases are explicit for a reason.

The four steps (run in order)

Step 1 — Snapshot what this session touched

Build a session changelog. Sources:

• Edit / Write / NotebookEdit calls this session — your own tool-call history is the ground truth
• Shell commands with side effects — deploys, package publishes, scheduled-task changes, gh pr create, migrations
• Git state if applicable — git status --short, git diff --stat
• New files created — grouped by directory

Output: a compact "what shipped" list, organized by workstream (rough top-level grouping by directory or project area).

Step 2 — Update PROGRESS.md

PROGRESS.md at the project root is the chronological log of what got done. (If the project uses a different progress file, use that — the shape below still applies.)

Insert a new dated section RIGHT BEFORE the most recent ## DONE header, so the newest entry is always on top. Template:

## DONE — {YYYY-MM-DD}: {one-line headline}

{One-paragraph summary of the arc — what was the goal of this session, what got there.}

### Workstreams

#### {Workstream name}

- {Specific change} — {file:line if applicable}
- {...}

### Open follow-ups

1. **{Item}** — {why it's open + next concrete step}
2. **{...}**

---

Keep it specific. File paths and line numbers beat vague descriptions.

If anything else writes to this file (a scheduled task, a watcher, another agent), do not use a read-then-edit flow — the file can change between your read and your write. Use an atomic rewrite instead: one small inline script that reads the file, inserts the new section, and writes the whole file back in a single operation.

Step 3 — Cross-check memory

If your setup has persistent memory (auto-memory, a MEMORY.md index, a notes directory), audit it against the session:

• New patterns: did this session reveal a repeatable preference, rule, or fact worth saving? If the user said "next time, do X instead" or "from now on", or you noticed a pattern crystallizing — save it.
• Stale memory: did this session change something an existing memory claims? Update or remove it.
• Index: if your memory system has an index file, make sure it points at everything you added or removed.

Rule of thumb: memory is for durable preferences, decisions, and project state — not for "we talked about X today." If it's only relevant to this session, it goes in PROGRESS.md, not memory. Quality over volume.

If your setup has no persistent memory, skip this step deliberately — don't fake it.

Step 4 — Propose the first action for next session

The most important step. Write a SINGLE concrete next action. File path + command if possible. This is what the next cold start lands on.

Format:

NEXT SESSION FIRST MOVE:
{specific command, file to open, or UI action — copy-pasteable}

Why: {one sentence — what state this leaves things in}

This block goes at the bottom of the new PROGRESS.md section AND gets echoed in the chat reply.

"Continue the API work" is not a first move. Open src/api/routes.py:142 and wire the new /export endpoint into the router — handler is written, registration is not is.

What to output in chat after running

A short, dense summary:

✓ /signoff complete.

Captured to PROGRESS.md:
  - {N} workstreams · {K} files touched · {D} deploys

Memory: {N saved · M updated · 0 stale}

NEXT SESSION FIRST MOVE:
{the one concrete action}

No filler, no "thanks for the session." The user is about to close the tab.

Done means

This skill completed successfully when ALL of these are true:

• ✓ PROGRESS.md has a new ## DONE — YYYY-MM-DD section above the previous one, with workstreams + open follow-ups + a NEXT SESSION FIRST MOVE block.
• ✓ Memory was either updated or deliberately confirmed current — not skipped by accident.
• ✓ The NEXT SESSION FIRST MOVE block is a SPECIFIC executable thing — exact command, exact file path, or exact UI action. Not "continue X" — that's not actionable cold.

If any of these is missing, the skill is incomplete. Do them before declaring done.

Anti-patterns — what wrecks a good signoff

• Vague headlines. "Various fixes" / "general improvements" — kills cross-session continuity. Name the surface that changed.
• Skipping the NEXT SESSION FIRST MOVE. Without it, tomorrow's cold start re-reads the whole chat to figure out where to begin. The block exists to eliminate that.
• Inflating the workstream count. If three "workstreams" are really one project with three files touched, it's ONE workstream. Padding makes the log less useful, not more.
• Read-then-edit on a file something else also writes. Race conditions are silent and cost real debugging time. Atomic rewrite (Step 2).
• Saving every conversation snippet to memory. If it's only relevant to this session, it belongs in PROGRESS.md, not memory.
• Auto-signing-off when the user didn't ask. The trigger phrases are explicit for a reason.

Extending for multi-agent setups

The four core steps assume a single agent and a single human. If you run multiple agents, specialists, or scheduled processes that need to know what happened, add steps between Step 3 and Step 4. Patterns that work:

• Cross-agent ledger — append one JSONL line per workstream to a shared ledger.jsonl ({ts, agent, workstream, subject, files_touched, summary}). Anything that builds a standup or morning brief reads from it.
• Agent resume bump — if agents have registry records (recent topics, recent files, last active), update yours so routing and handoffs stay accurate.
• Inbox heads-up — append a session_wrapped line to the inbox file of whatever agent runs the next coordination pass, with the headline and the next-session proposal.
• Routing-table maintenance — if your workspace has a routing/context document mapping tasks to folders, add rows only when this session created a new addressable surface (new endpoint family, new CLI subcommand, new integration). Don't touch it for routine changes inside existing surfaces.

Keep extensions in the same spirit: every added step must write durable state that something downstream actually reads. A step nothing consumes is ritual theater.

Why this exists

Sign-off used to be ad-hoc ("update progress before we stop"). Every session ended differently; sometimes the progress log got updated, sometimes memory got refreshed, sometimes neither. Inconsistent sign-offs mean cold starts lose context.

This skill makes the ritual mechanical. Same steps every time. The next session reads a uniform shape and lands running.