agentleFS
chadjardinechadjardine/claude-working-skills/skills/session-handoff/SKILL.md

session-handoff

Skill0 starsChanged 3 months agoMITView on GitHub

Use when the user says \"session handoff\", \"wrap up session\", \"hand off\", \"handoff summary\", \"let's wrap up\", or wants a structured summary before switching tools or starting a fresh session. Produces a chat-only handoff of a marketing, research, or automation session (across Chat, Cowork, or Code) covering decisions, key files/links, automations set up, and open questions, so a fresh session can continue without re-explaining everything. Manual trigger only — never runs proactively.

139 other projects use a version of this, 6 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use ascii-diagram, research-fleet and 10 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.
  • SethGammonSkill

    ascii-diagram

    Generate perfectly aligned ASCII diagrams — architecture, flow, sequence, box-and-arrow. Uses a programmatic character-grid approach so alignment is guaranteed by math, not token prediction. Includes post-render verification.

    Also in 4 projects that use this

  • SethGammonSkill

    research-fleet

    Parallel research using Fleet wave mechanics. Spawns multiple scout agents, each investigating a different angle of the same question. Findings are compressed between waves. Produces a unified research brief from multiple independent perspectives.

    Also in 3 projects that use this

  • vicoa-aiSkill

    live-preview

    Start a local app in the current user project, expose it through a tunnel, and return preview details in structured Markdown. Use when the user asks for a preview URL, public URL, shareable localhost, mobile/web preview, or tunnel setup.

    Also in 4 projects that use this

  • botlearn-aiSkill

    doc-gen

    Also in 4 projects that use this

  • flyingobsidianSkill

    terminology

    Read a codebase, find terminology, create/update definitions into a markdown document.

    Also in 3 projects that use this

  • Dizzy-TenSkill

    bug-diagnosis

    Diagnose bugs and product issues without modifying code. Use when the user explicitly invokes $bug-diagnosis or asks for diagnosis, root-cause analysis, issue classification, or fix strategy for code bugs, failing tests, configuration/dependency problems, deployment issues, performance regressions, data anomalies, or frontend/user-experience problems described through screenshots, annotations, logs, errors, or natural-language reports. Prioritize analysis and recommendations only; do not edit files.

    Also in 3 projects that use this

  • +1 more from SethGammon

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 117 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Produce the output in chat only: Do not write a file. Do not create an artifact.

    line 30
  2. Distinctive:

    Chat output only: Never write the handoff to a file, artifact, or memory.

    line 63
  3. Distinctive:

    Never invent state: If a section has nothing to report, write "none" — do not omit the section.

    line 64
  4. Distinctive:

    No recommendations: Do not suggest what the next session should do, and do not recommend which skill to use next.

    line 66

“Common” is measured: kept by at least 6 in 10 of the 117 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

Session Handoff

Produce a repeatable end-of-session summary so the user can start a fresh session (in Chat, Cowork, or Code) without losing continuity. The next session should be able to pick up by reading this summary alone — plus whatever files/links it points to.

This is a context-handoff artifact, not a status report and not a retrospective. The audience is a future instance of you (or a colleague), not a client or stakeholder.

The user's work is typically marketing, research, or automation — buyer personas, positioning, campaigns, SEO audits, briefs, decks, spreadsheets, scheduled tasks, connector-driven lookups. It is usually NOT software engineering. Do not assume git, code, or a dev environment. If a session genuinely did involve code (e.g. in Claude Code), fold that in using the "Key files & links" and "Automations & running state" sections below — don't force it into engineering-specific structure.

When to invoke

Only when the user asks. Trigger phrases: "session handoff", "wrap up session", "hand off", "handoff summary", "let's wrap up", "summarize before I switch", "summarize before I clear/reset". Do not invoke proactively — do not offer it unprompted, even if the conversation is long or the user mentions starting fresh. Wait to be asked.

How to produce the summary

  1. Review the full conversation, not just the last few turns. Handoffs miss things when they only summarize recent exchanges — pull from the whole session.
  2. Pull state from what actually happened this session:
    • Decisions made and why (persona chosen, positioning locked, channel prioritized, budget set, etc.)
    • Content or documents produced — decks, docs, spreadsheets, briefs, posts, audits — with their actual titles and locations (file path, artifact name, or URL)
    • Any connector or tool actions taken that changed something outside the chat: emails drafted, CRM records touched, calendar events created, scheduled tasks set up, artifacts created, files saved to a connected folder
    • Skills used this session (e.g. problem-usp-builder, seo-audit, watering-hole-analysis) and what they produced
    • Questions the user was asked that never got a clear answer, or things the user asked that got deflected or left unresolved
    • What surface this happened in (Chat, Cowork, or Code) if it affects what continuity means — e.g. a scheduled task or connector action only persists in Cowork; a Chat conversation has no files or connectors at all
  3. Do not audit outside the conversation. This is synthesis of what happened in THIS session. Don't re-research, don't re-run tools to "double check," don't go digging through unrelated files.
  4. Produce the output in chat only. Do not write a file. Do not create an artifact. Do not save to memory or as a skill. Chat-only, every time.

Output template — use exactly this structure, every time

# Session Handoff — <one-line title of what this session was about>

## Where it started
<2-3 sentences: what the user asked for, key framing, constraints, or audience that emerged>

## Decisions made + what was produced
- <decision or output> — <why, and where it lives (file name/path, artifact name, or URL)>
- ...

## Key files & links for next session
- `<file path, artifact name, or URL>` — <what it is / why the next session should look at it first>
- ...  (or "none" if nothing was produced)

## Automations & running state
- Scheduled tasks created: <name/cadence> — or "none"
- Connector actions taken (emails drafted, CRM/records touched, calendar events, etc.): <what + where> — or "none"
- Live artifacts created: <name> — or "none"

## Open questions
- <question needing the user's input> — <why it's still open>
- ... (or "none")

## Where things stand
<1-3 sentences, purely factual: what's done, what's mid-flight, what was left untouched. No recommendation on what to do next — that's for the next session to decide.>

Hard rules

  1. Chat output only. Never write the handoff to a file, artifact, or memory.
  2. Never invent state. If a section has nothing to report, write "none" — do not omit the section. A stable structure is the whole point.
  3. Use real names and locations, not vague references. "The positioning doc" is not good enough — name the actual file, artifact, or URL.
  4. No recommendations. Do not suggest what the next session should do, and do not recommend which skill to use next. State facts and open questions only; let the next session (or the user) decide.
  5. No retrospective. No "what went well," no praise, no self-assessment. Terse and concrete.
  6. Note the surface (Chat / Cowork / Code) when it matters — e.g. flag that a scheduled task or connector action only exists because this was a Cowork session, so the next session knows it doesn't need to recreate it.

Anti-patterns — do not do these

  • Summarizing only the last few turns and calling it a handoff.
  • Vague file/doc references instead of actual names, paths, or links.
  • Recommending next steps or naming a skill the next session "should" use.
  • Skipping a section because it's empty — write "none" instead of omitting it.
  • Writing the summary to a file, artifact, or memory. This is chat-only by design.
  • Adding a "what went well / what went poorly" retrospective. This isn't a retro.

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.