Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

create-handoff

Étoiles4

Forks0

Mis à jour15 juillet 2026 à 13:49

Write a session-to-session transfer packet to docs/handoff/ so another Claude session can pick up in-flight work without re-deriving it. Use when wrapping up before /clear, running low on context, or when the user says to "hand this off", "write a handoff", or pause work for later. To pick a handoff back up, use resume-handoff instead.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

KyleMit

KyleMit/Splotch

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	create-handoff
description	Write a session-to-session transfer packet to docs/handoff/ so another Claude session can pick up in-flight work without re-deriving it. Use when wrapping up before /clear, running low on context, or when the user says to "hand this off", "write a handoff", or pause work for later. To pick a handoff back up, use resume-handoff instead.

Handoff

Write a transfer packet for the work in flight, so the next session can resume it cold. Read docs/handoff/CLAUDE.md first — it defines the folder conventions this skill produces.

A handoff is transient. If what you're about to record is really a durable decision, a backlog item, or behavioural feedback, route it to /create-adr, a GitHub issue (the live backlog — see docs/ISSUE-WORKFLOW.md), or memory/ instead — see the table in the root CLAUDE.md.

Steps

Pick the topic name. docs/handoff/<brief-kebab-topic>.md, two to four words for what is being handed off (magic-brush-drift.md, not a date). If a handoff for this exact work already exists, update it in place rather than making a second file.
Write the packet with the status line and the required sections from docs/handoff/CLAUDE.md:
- Status line: > <today> · branch \` · PR #NN · (get the date from the environment context, the branch fromgit branch --show-current`; drop the PR segment if there's no PR).
- Objective & non-goals · State (branch, PR, commit table, files touched) · Decisions made and why (including reverted approaches) · Unverified assumptions · Done & verified (the checks you ran and their result) · Risks & next 3 steps · Reread first (links to files/ADRs/skills).
- Keep it a packet, not a recap. Prefer a file:line pointer over a paragraph re-explaining the code. The docs/handoff/coloring-fill-drift.md handoff is a worked example of the right density.
Be honest about what's verified. Anything you believe but did not run a check on goes under Unverified assumptions, not Done & verified — resume-handoff tests that section first, so mislabelling it there wastes the next session's trust.
Commit and push. The doc is only useful if it survives the container:
```
git add docs/handoff/<topic>.md
git commit -m "Add handoff for <topic>"
git push -u origin <branch>
```
Push the working branch too if it has unpushed commits — a handoff that points at commits only on this container's disk is a dead link.
Tell the user the file path and that /resume-handoff will pick it up.

Plus depuis ce dépôt

même dépôt

api

KyleMit/Splotch

HTTP API reference for the /api/* endpoints — generate-image, verify-access-code, verify-key, report, and the admin bearer-session endpoints, plus the CORS, rate-limiting, and auth model. Use before adding, changing, or calling any /api endpoint.

2026-07-184

dependency-health-audit

KyleMit/Splotch

Inventory and evaluate every third-party dependency — who publishes it, its license, stars, release cadence, maintenance health, abandonment risk, and whether to keep or replace it — written to docs/DEPENDENCIES.md. Use when asked to inventory or catalog dependencies, assess dependency health or provenance, review maintenance/abandonment risk, find dependencies worth replacing, or produce an SBOM-style dependency review. It analyzes dependencies but never upgrades them — to apply version updates use dependency-update-audit instead.

2026-07-174

dependency-update-audit

KyleMit/Splotch

Audit package.json dependencies for updates (incl. majors), then upgrade them one at a time — read the migration guide, fix all usage, verify, and commit each on its own

2026-07-174

architecture

KyleMit/Splotch

Splotch tech stack, file-by-file source map of web/src/, route table, and the canonical UI element glossary. Use when navigating unfamiliar parts of the codebase, deciding where new code belongs, or needing the proper name of a UI element.

2026-07-174

mobile

KyleMit/Splotch

Capacitor native app guide — Android/iOS toolchain setup (macOS + Linux), build/sign/run commands, on-device testing, Chrome remote profiling, and the store release & kids-compliance checklists. Use before touching anything Android, iOS, or Capacitor related.

2026-07-174

profiling

KyleMit/Splotch

Capture and read an automated performance profile of the drawing app (web, Android, iOS). Use when measuring drawing/canvas performance, investigating jank or a slow interaction, verifying a perf change, or checking for regressions over time. Covers the `npm run perf:*` harness, how to read report.md/summary.json, and the bottleneck decision guide.

2026-07-174

name	create-handoff
description	Write a session-to-session transfer packet to docs/handoff/ so another Claude session can pick up in-flight work without re-deriving it. Use when wrapping up before /clear, running low on context, or when the user says to "hand this off", "write a handoff", or pause work for later. To pick a handoff back up, use resume-handoff instead.

Handoff

Write a transfer packet for the work in flight, so the next session can resume it cold. Read docs/handoff/CLAUDE.md first — it defines the folder conventions this skill produces.

Steps

Pick the topic name. docs/handoff/<brief-kebab-topic>.md, two to four words for what is being handed off (magic-brush-drift.md, not a date). If a handoff for this exact work already exists, update it in place rather than making a second file.
Write the packet with the status line and the required sections from docs/handoff/CLAUDE.md:
- Status line: > <today> · branch \` · PR #NN · (get the date from the environment context, the branch fromgit branch --show-current`; drop the PR segment if there's no PR).
- Objective & non-goals · State (branch, PR, commit table, files touched) · Decisions made and why (including reverted approaches) · Unverified assumptions · Done & verified (the checks you ran and their result) · Risks & next 3 steps · Reread first (links to files/ADRs/skills).
- Keep it a packet, not a recap. Prefer a file:line pointer over a paragraph re-explaining the code. The docs/handoff/coloring-fill-drift.md handoff is a worked example of the right density.
Be honest about what's verified. Anything you believe but did not run a check on goes under Unverified assumptions, not Done & verified — resume-handoff tests that section first, so mislabelling it there wastes the next session's trust.
Commit and push. The doc is only useful if it survives the container:
```
git add docs/handoff/<topic>.md
git commit -m "Add handoff for <topic>"
git push -u origin <branch>
```
Push the working branch too if it has unpushed commits — a handoff that points at commits only on this container's disk is a dead link.
Tell the user the file path and that /resume-handoff will pick it up.