# Handoff Summary

> Writes a concise handoff summary of a file's current state -- what's finished, what's in progress, key decisions made and why, and open questions -- for a teammate picking up the work, a new team member, or a stakeholder update. Use whenever context needs to transfer cleanly to someone else.

- Skill: `qredence/handoff-summary` (Agent Skill)
- Install (CLI): `npx skillmds@latest add qredence/handoff-summary`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qredence/handoff-summary/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: Qredence (https://skillmd.com/u/qredence)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/qredence/handoff-summary

---


# Handoff Summary

## Purpose
Give someone picking up a file everything they need to get oriented quickly, without having to reconstruct history themselves.

## Operating Role
Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes.

## Supported Context
- Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits.
- Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations.
- Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption.
- Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions.

## Activation Boundary
- Handing work off to another designer, a new team member, engineering, or a stakeholder
- Before going out of office on an active project

## Required Inputs
- The file/project and the audience for the summary (a teammate continuing the work needs different detail than a stakeholder getting a status update)
- If an input is missing but can be inferred safely from the selection, proceed and label the assumption.

## Fast Defaults
- Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file.
- Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low.
- Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible.
- Write for the receiving developer or reviewer. Summarize what matters to build, verify, or decide.

## Workflow
1. State current status plainly: what's finished and considered final, what's in progress, and what hasn't been started yet.
2. Summarize key decisions made so far and briefly why, especially any non-obvious ones a newcomer might otherwise second-guess or accidentally re-litigate.
3. List explicit open questions and known unresolved issues, distinguishing "blocked on someone else" from "not yet decided by this team".
4. Point to exactly where in the file to find current/final work versus exploration (pairs with file-cleanup if the file itself is not yet organized enough to point to clearly).
5. For a teammate-continuation audience, include practical next steps: what the most logical next task is and any context needed to start it immediately.
6. For a stakeholder audience, keep decision rationale and next steps but drop file-navigation detail that is not relevant to them.

## Figma Execution Limits
- Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently.
- For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes.
- For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing.
- Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available.
- Preserve intentional exceptions that are labeled, annotated, or explained by the user.

## Guardrails
- Keep the summary honest about what's actually unresolved -- do not smooth over open risks to make status look more complete than it is.

## Finding Quality Rules
- Lead with the highest-impact issues, not the order discovered.
- Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source.
- Include severity only when it changes priority: Blocker, High, Medium, or Low.
- Pair every finding with an exact fix, replacement, or next decision.
- Separate confirmed findings from assumptions, recommendations, and unverified areas.

## Output Contract
Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas.
- Skill-specific format: Status (Finished / In progress / Not started) -> Key decisions + why -> Open questions -> Where to look in the file -> Next steps, tailored to the stated audience.