/handoff

name: handoff
description: |
  Explicitly invoke /kk:handoff to publish active-task context and a fresh-session
  starter prompt to a new secret GitHub gist. For restarting a conversation or
  switching providers or machines; requires the GitHub CLI. Not a local save.
disable-model-invocation: true

Hand off the active task

Publish `handoff.md` and `prompt.md` in a fresh **secret (unlisted) GitHub gist**. Anyone with the link can read it. Invoking `/kk:handoff` requests this publication; normal host permissions still apply, with no extra recurring confirmation step. Ordinary summary, continuation or review-context requests do not invoke this skill.

Workflow

**Mandatory order — instructions before action.** Follow this workflow strictly in sequence. Read this entire skill before inspecting task evidence, preparing files or publishing. This file contains all operative instructions; no other protocol is required. Only bounded routing inspection for a declared detection predicate could precede instruction loading; this skill has no such predicate.

1. Establish the continuation context

Use the conversation actually available to identify the active task and relevant earlier decisions. Follow ordinary explicit user instructions about scope; there is no custom argument syntax. Make focused read-only project checks only when needed to reconcile progress or establish identity. This is the investigation entry point: do not run tests, conduct reviews, finish implementation, scan other worktrees or collect the whole repository for a handoff.

Prepare a concise, self-contained Markdown record using the outline below. Omit empty sections, repetition and unrelated-topic details, including in exclusion notes. Preserve context needed for the next decision without imposing a word limit.

| Content | Include when relevant | | --- | --- | | Identity | Task/topic, creation time, repository identity, branch/worktree and relevant revision if known. Label local paths as source-machine paths. | | Objective and constraints | User intent, corrections, accepted scope and operating constraints. | | Decisions and rationale | Accepted choices and reasons; abandoned approaches worth avoiding. Distinguish user decisions from agent proposals. | | Progress and evidence | Completed/pending work, repository-relative file references, attributed verification results and uncertainties. Remembered tests are recorded evidence, not newly run verification. | | Continuation | Blockers, unanswered questions, dependencies and the next useful action. Do not execute it. | | Supporting references | Useful project documents, issues and eligible existing Capy references, with a reason to follow each. |

State material context gaps, including earlier conversation lost to compaction. Describe uncommitted work as local: a gist transfers neither worktree changes nor patches, credentials or a Capy database. Essential context must remain usable without optional references or source-machine paths.

**Existing Capy references only.** Include a reference only when the available conversation already evidences prior indexing/retrieval or confirmed archival of that specific relevant material. Tool availability, a familiar source label, a bare current session ID or unrelated indexing is insufficient. Otherwise omit Capy references; do not search merely to fill this section. For an eligible reference, retain the known source label or archived session identifier, project scope, a focused retrieval query/instruction and why it helps. Note destination availability limits without copying or recreating the source.

**Never initiate indexing or archival during handoff.** This includes indexing, fetch-and-index, vault import/reindex/archive, and indirect actions through tools, other skills, agents or the starter prompt. Never repair a missing reference by indexing it. Do not load a general Capy indexing protocol. This boundary governs handoff-initiated actions; it does not disable independent host storage or hooks.

2. Prepare safe outgoing files

Allocate a unique temporary directory outside the working repository (for example, `mktemp -d /tmp/kk-handoff.XXXXXXXX`). Retain its absolute path. Use native file tools to write `handoff.md` and draft the starter-prompt wording there; keep file bodies out of shell interpolation. Do not create a persistent local store, write artifacts into the repository, stage or commit anything.

Prepare a gist description containing the project/topic and creation time. Before sending **each** payload, read its local content and omit or redact credentials, authentication tokens, credential-bearing connection strings and unrelated private information. Check `handoff.md` and the description now; check the completed `prompt.md` again before adding it. A relevant hostname alone is not a credential. If a safe, useful payload cannot be prepared, stop before uploading it and explain the problem without echoing sensitive values.

3. Publish in two writes

Use the existing authenticated `gh` CLI. Do not install it, change credentials or permission configuration, or switch storage products. Normal host approval requests remain available when required; honor denials. Quote paths, the description and returned URL as shell arguments; never interpolate Markdown bodies into commands.

1. Create a **new secret gist** with the prepared file: `gh gist create <absolute-handoff.md-path> --desc <description>`. Omit `--public`/`-p`. Retain the returned URL immediately; a local filename or directory name cannot replace the remote identifier. 2. Finish `prompt.md` with that actual URL and the exact filename `handoff.md`. Address the receiving agent: ask it to read that handoff, reconcile relevant current project state with the recorded evidence, and continue the intended task. Keep the prompt short and usable without a separate resume skill. Do not silently choose another handoff or instruct the recipient