From pm-tokens
Write a handoff summary so another agent or person (or a fresh session) can pick up the work with full context. Use when ending a work session, hitting a context limit, switching agents, or pausing a task mid-flight. Produces a structured handoff: what the goal is, what's done, the current state, what's next, and the gotchas — so no context is lost across the boundary.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pm-tokens:session-handoffThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Work gets dropped at boundaries — a context window fills, a session ends, a task passes to someone else — and
Work gets dropped at boundaries — a context window fills, a session ends, a task passes to someone else — and the next person (or agent) re-derives everything from scratch. This skill writes a tight handoff that carries the state across that boundary: the goal, what's done, where things stand, the exact next step, and the landmines. Optimised to be the first thing a fresh session reads.
Ask for these only if they aren't already provided (or infer from the session so far):
🎯 Objective — the goal in 1–2 lines, and the definition of done.
✅ Done so far — key work completed and decisions made (with the why for non-obvious calls), as tight bullets.
📍 Current state — exactly where things stand: branch/PR, what runs, what's failing, files touched, any half-finished change.
⏭️ Next step — the very next action, concrete enough to start immediately. Then the following 2–3 steps.
⚠️ Gotchas & dead ends — what was tried and didn't work (so it isn't repeated), constraints, sharp edges, anything surprising.
🔗 Pointers — key files (path:line), commands to run, links (PR, issue, docs) the next person needs.
Keep it skimmable — the next reader should grasp the state in under a minute.
Engineering handoff / pairing-rotation practice and incident-handoff (SBAR-style) structure adapted for agent and human work.
Guides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Synthesizes the current conversation into a structured spec (PRD) and publishes it to the project issue tracker with a ready-for-agent label, without interviewing the user.
npx claudepluginhub mohitagw15856/pm-claude-skills --plugin pm-tokens