# Signoff

> End-of-session ritual. When the user says "/signoff", "wrap up", "i'm stepping away", "end session", or "update progress", run this — captures what shipped, updates the progress log, cross-checks memory, and proposes the first action for the next session. Replaces every ad-hoc "update progress before we stop" request.

- Skill: `luckycody/signoff` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add luckycody/signoff`
- Raw SKILL.md: https://api.skillmd.com/api/skills/luckycody/signoff/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: LuckyCody (https://skillmd.com/u/luckycody)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/luckycody/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:

```markdown
## 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.