agentsclimarketplace

Session handoff

Skill QBall-Inc/the-bulwark/skills/session-handoff

Create consistent session handoff documents for context transfer between sessions. Use when closing a session, reaching 75% token consumption, or when user requests handoff. Ensures proper YAML headers for metrics collection, LF line endings, and complete documentation of progress, decisions, and next steps.From its SKILL.md

Install
npx -y skills add QBall-Inc/the-bulwark --skill session-handoff

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.8 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Session Handoff

Create handoff documents that enable seamless context transfer between sessions.

Critical Requirements

Line Endings

Use LF (Unix) line endings only. Never CRLF.

  • Use the Write tool directly (handles line endings correctly)
  • Never copy-paste from Windows clipboard
  • If you see ^M characters, rewrite the file

File Naming

Pattern: sessions/session_{N}_{YYYYMMDD}.md

  • {N}: Session number (integer, no leading zeros)
  • {YYYYMMDD}: Date without separators

Examples: session_5_20260104.md (correct), session_05_20260104.md (wrong)

Handoff Template

# Session {N} Handoff

```yaml
session: {N}
date: {YYYY-MM-DD}
phase: "P{X} - {Phase Name}"
task: "P{X}.{Y} - {Task Name}"
status: {completed | in_progress | blocked}
tokens_end: "~{X}K ({Y}%)"
```

---

## Session Summary

{2-3 sentences on outcomes, not process. What was achieved?}

## What Was Accomplished

- [x] {Completed item with file path}
- [x] {Completed item with file path}
- [ ] {Incomplete item - carried forward}

## Files Created/Modified

| File | Action | Lines | Purpose |
|------|--------|-------|---------|
| {path} | Created | ~{N} | {Brief description} |
| {path} | Modified | +{N}/-{M} | {What changed} |

## Verification Status

| Check | Status | Notes |
|-------|--------|-------|
| Typecheck | {Pass/Fail/Skipped} | |
| Lint | {Pass/Fail/Skipped} | |
| Tests | {Pass/Fail/Skipped} | {X/Y if applicable} |

## Technical Decisions

### {Decision Title}
- **Decision**: {What was decided}
- **Rationale**: {Why}
- **Impact**: {What it affects}

## What's Next

1. {Specific actionable step}
2. {Next step}

## Blockers / Issues

{List blockers or "None"}

## Learnings

{Patterns discovered or "None"}

Section Guidelines

YAML Header (Required)

The YAML header enables metrics collection. All fields required:

FieldFormatExample
sessionIntegersession: 5
dateYYYY-MM-DDdate: 2026-01-04
phaseQuoted stringphase: "P1 - Foundation"
taskQuoted stringtask: "P1.2 - Test Auditor"
statusEnumstatus: completed
tokens_endQuoted stringtokens_end: "~95K (48%)"

Session Summary

Focus on outcomes not process. What was delivered?

Good: "Completed session-handoff skill with CRLF handling. Ready for use." Bad: "I started by reading files, then thought about structure, then wrote..."

What Was Accomplished

  • Use [x] for complete, [ ] for incomplete
  • Include file paths
  • Be specific

Technical Decisions

Document decisions that affect future work. Include rationale so future sessions understand WHY. Skip if no significant decisions.

Blockers / Learnings

Always include these sections. Write "None" if empty - don't omit.

Memory Reflection (Mandatory)

Before finalizing the handoff, perform a two-part memory reflection:

Part 1: Session Learnings → Memory Candidates

Review the session for durable insights worth persisting to memory:

  • Feedback from the user (corrections, confirmations, preferences)
  • Technical decisions that affect future sessions (not just this task)
  • Project context that would be lost without memory (deadlines, stakeholder constraints)

Filter: Only flag items that (a) will persist beyond this session, (b) haven't already been saved to memory during the session, and (c) aren't derivable from code/git.

Present candidates to the user for approval before writing. Do not silently update memory.

Part 2: Supersession Check

Review existing memory entries against current project state:

  • Has any memory been invalidated by work done this session?
  • Are there memories that reference completed phases, old file paths, or reversed decisions?
  • Can any two memories be merged into one?

Present proposed removals/updates to the user for approval before modifying.

Quick Checklist

Before finalizing:

  • File named session_{N}_{YYYYMMDD}.md
  • YAML header complete and valid
  • All sections present (even if "None")
  • Next steps are specific and actionable
  • No CRLF line endings
  • Memory reflection Part 1: session learnings reviewed with user, saved if approved
  • Memory reflection Part 2: existing memory checked for superseded entries

Examples

For detailed examples of completed and in-progress handoffs, see references/examples.md.

What ships with it: 1 file

5.1 KB alongside SKILL.md

references/

Keep looking

Skills are one crate of 625,857. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.