agentleFS
ZunoSmartLabsZunoSmartLabs/zsl-superpowers/skills/productivity/handoff/SKILL.md

handoff

Skill2 starsChanged 53 days agoMITView on GitHub

Compact the current conversation into a handoff document so a fresh agent (or session) can continue the work cleanly. Saves to the OS temp directory, redacts secrets, references existing artifacts by path instead of duplicating them, and suggests which skills the next session should invoke. Use when the user wants to end a session, hand off to a teammate, switch agents, says "wrap this up for next time", or mentions "/handoff".

  • Reads credentials

191 other projects use a version of this, 80 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use setup-ts-deep-modules, to-questionnaire and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • liufeng1976Skill

    setup-ts-deep-modules

    Wire dependency-cruiser into a TypeScript repo so each package is a deep module — implementation hidden in subfolders, reachable only through its entry-point files. User-invoked.

    Also in 42 projects that use this

  • AWSSkill

    to-questionnaire

    Turn a decision you can't fully answer into a questionnaire for someone else to fill in.

    Also in 93 projects that use this

  • GoogleSkill

    ask-matt

    Ask which skill or flow fits your situation. A router over the skills in this repo.

    Also in 87 projects that use this

  • RoentekSkill

    loop-me

    Grill me about specs for the workflows I want to build, within this workspace.

    Also in 51 projects that use this

  • LesaniSkill

    writing-beats

    Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.

    Also in 54 projects that use this

  • LesaniSkill

    writing-fragments

    Grilling session that mines the user for fragments — heterogeneous nuggets of writing (claims, vignettes, sharp sentences, half-thoughts) — and appends them to a single document as raw material for a future article. Use when the user wants to develop ideas before imposing structure, or mentions "fragments", "ideate", or "raw material" for writing.

    Also in 55 projects that use this

  • +1 more from Lesani

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 172 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write a handoff document summarising the current conversation so a fresh agent can continue the work without re-deriving context from …

    line 9
  2. Distinctive:

    If a handoff file with the same slug already exists for today, read it first before writing so existing content is preserved or appended …

    line 37
  3. Very specific:

    When in doubt, redact. Replace with <redacted: kind> (e.g.

    line 69
  4. Very specific:

    If the user passed an argument to /handoff, treat it as a description of what the next session will focus on.

    line 73
  5. Distinctive:

    If no argument was passed, write a general-purpose handoff covering everything substantive in the session.

    line 75

“Common” is measured: kept by at least 6 in 10 of the 172 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Handoff

Write a handoff document summarising the current conversation so a fresh agent can continue the work without re-deriving context from scratch.

flowchart LR
    cur["Current session<br/>(conversation context)"] --> scan["Scan for secrets<br/>· API keys / JWTs<br/>· hostnames / .env vars"]
    scan --> compact["Write handoff.md<br/>· state at handoff<br/>· open decisions<br/>· don't redo<br/>· pointers (path:line)"]
    compact --> tmp[("$TMPDIR / %TEMP%<br/>zsl-handoff-YYYYMMDD-slug.md")]
    tmp --> next["Next session<br/>cat &lt;path&gt; or paste"]
    next --> sug["Suggested skills<br/>/zsl:tdd · /zsl:triage · …"]
    sug -.->|"resume in the loop"| loop["the engineering loop"]

    classDef step fill:#e0e7ff,stroke:#3f51b5;
    classDef artifact fill:#dcfce7,stroke:#16a34a;
    classDef external fill:#fef3c7,stroke:#d97706;
    class cur,scan,compact,next,sug step
    class tmp artifact
    class loop external

Where to save

The OS temp directory — not the current workspace. The handoff is ephemeral session metadata, not a project artifact.

  • macOS / Linux: $TMPDIR/zsl-handoff-<YYYYMMDD>-<short-slug>.md (fallback /tmp/...)
  • Windows: %TEMP%\zsl-handoff-<YYYYMMDD>-<short-slug>.md

Tell the user the absolute path after writing so they can hand it to the next session via cat <path> or paste.

If a handoff file with the same slug already exists for today, read it first before writing so existing content is preserved or appended to, not clobbered.

What goes in

Lead with what the next agent actually needs in the first 30 seconds. Cut anything they can reconstruct themselves.

  1. One-paragraph summary of what this session was about and where it left off — written so a cold reader can orient in three sentences.
  2. State at handoff — the concrete thing the next session inherits. Branch name + last commit sha (git rev-parse --abbrev-ref HEAD / git rev-parse HEAD), unpushed work, open worktrees, halted RCAs, anything mid-flight. Reference, don't copy.
  3. Open questions / pending decisions — anything the user and this session debated without resolving. Each as a bullet with the option list, not just the question.
  4. Suggested skills for next session — which /zsl:<skill> calls the next agent should reach for first, in order. Be specific: /zsl:tdd <NN> not just /zsl:tdd.
  5. What NOT to redo — work that's already complete (commits landed, PRs opened, slices closed). Saves the next agent from re-reviewing finished ground.
  6. Pointers, not duplicates — for anything that already exists in a durable artifact (PRD, ADR, issue body, commit message, file in repo), reference it by <path>:<line> or URL. Never paste the full body.

What stays out

Skip aggressively. The point is compaction.

  • Conversation transcripts. The next agent doesn't need to read your back-and-forth.
  • Code listings already in the repo. Refer to file:line.
  • Issue bodies / PRD bodies that are on the tracker. Refer to #123 or the path.
  • Tool-call output that wasn't load-bearing for the conclusion.
  • Apologies, hedges, "I'm going to do X" announcements — the artifact is the record, not the running commentary.

Redaction

Before writing, scan for and redact:

  • API keys, tokens, passwords, OAuth credentials, signed URLs — any string that looks like sk-…, ghp_…, eyJ… (JWT), xox[abp]-… (Slack), AWS access-key patterns
  • Personally identifiable information beyond what's already in the repo (emails, phone numbers, names of customers/users mentioned in passing)
  • Internal hostnames, IPs, S3 bucket names, database connection strings
  • Anything under .env* that the conversation surfaced

When in doubt, redact. Replace with <redacted: kind> (e.g. <redacted: api-key>). If the redaction makes a step incomprehensible, the next session can ask the user for the value; that's safer than leaking it into a tmp file.

Argument handling

If the user passed an argument to /handoff, treat it as a description of what the next session will focus on. Tailor the Suggested skills and State at handoff sections to that focus. The other sections still cover the broader conversation, but the spotlight shifts.

If no argument was passed, write a general-purpose handoff covering everything substantive in the session.

Template

# Handoff — <YYYY-MM-DD HH:MM> — <one-line topic>

> Generated by `/zsl:handoff`. Read this once, then start work — don't re-derive what's already settled.

## Summary

<3 sentences: what this session was about, what got done, where it stopped>

## State at handoff

- Branch: `<branch-name>` (last sha: `<short-sha>`)
- Pushed: yes / no
- Open PRs: <#N or none>
- Halted operations: <RCA path or none>
- Worktrees: <paths or none>

## Done — don't redo

- <one-line per completed item, with the commit/PR/issue link>

## Open questions / pending decisions

- **<decision>** — options considered: A (…), B (…). Leaning <X> because <reason>. Needs user to confirm.
- **<question>** — context: <file:line or PRD ref>. Asked, not yet answered.

## Suggested skills for the next session

In order:

1. `/zsl:<skill> <args>` — <one line: why this first>
2. `/zsl:<skill> <args>` — <one line>
3. `/zsl:<skill> <args>` — <one line>

## Pointers

- PRD: <path or URL>
- Relevant ADRs: <path>
- Recent commits worth reading: `<sha>` (`<subject>`)
- Files most likely to need attention: `<file>:<line-range>`

Tone

The handoff is for a stranger. They have no conversational context, no memory of your earlier debates, no idea who's the user and who's the agent. Write so a cold read makes them productive in 30 seconds. If a section needs scaffolding to be understandable, the section is wrong — rewrite the section, don't pad it with explainer.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.