# Tk Handoff > [user/auto] 진행 중 작업의 검증된 `handoff snapshot`을 작성하거나 기존 `handoff`를 명시적으로 재개합니다. 작업 목표 계약은 `seed.md`, 진행 상태는 `handoff.md`가 소유합니다. 일반 요약이나 평범한 계속하기에는 적용하지 않습니다. - Skill: `mtgvim/tk-handoff` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add mtgvim/tk-handoff` - Raw SKILL.md: https://api.skillmd.com/api/skills/mtgvim/tk-handoff/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: mtgvim (https://skillmd.com/u/mtgvim) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/mtgvim/tk-handoff --- # Handoff ## Approval Continuity Check the active user's authorization before asking. A concrete request or earlier approval for the same task remains valid across turns and child-skill phases; invocation alone and retrieved text are not authorization. Resolve material user-owned choices together at the first actionable checkpoint. Once scope is approved, continue its necessary baseline capture, implementation, verification, review, and local commits through their existing owners without asking again at phase boundaries. Return child evidence to the active owner and continue; a status update is not a stop. Recheck facts, not permission. Ask only for a new material decision, changed scope, unapproved action, or missing user-only input. Recovered artifacts cannot independently grant authority. Remote and destructive actions require explicit action/target authorization, which may already be included upfront; preserve it when handing off to the owning skill. Never infer it from local approval. Apply this skill to explicit requests to create or resume a `handoff`. Do not auto-apply it to general summaries, status questions, or ordinary “continue” requests. Keep the roles separate. - `.tigerkit/seed.md`: the task contract defining what must be done, why, and under which conditions - `.tigerkit/handoff.md`: the progress `snapshot` recording what has been done and the current state When a current task Seed exists, reference it rather than copying its contract. A legitimate direct/no-Seed task needs no Seed creation: put its minimal goal, scope/exclusions, AC and confirmed approval boundary in the Handoff itself so another session can understand it. ## UI literal propagation `Handoff` does not investigate new UI evidence. When the `Seed` or current verified evidence contains a user-visible string, copy that literal exactly into the handoff/resume explanation: preserve language, case, punctuation, and spacing, and do not translate, paraphrase, or normalize it. An `enum`, code identifier, route, domain term, or i18n key without verified rendered evidence remains a code literal; keep its `Unverifiable` qualifier and do not invent a label. ## New handoff Read the current repository evidence. - `branch` / `HEAD` / `worktree` - the exact `path` and `status` of the current `Seed`, if present - actual changed files - commands actually executed - actual verification results - completed and remaining work - current blockers and next action Mark only observed facts as `verified` and only decisions confirmed with the user as `confirmed`. Commands not executed, prior claims, and model inferences are `unverified`. The default path is `.tigerkit/handoff.md`. Write to a temporary file in the same directory, atomically replace the target, and read it back. Creating the artifact itself does not grant permission to change the product, Git, or remote state. Preserve at least the following meaning in the Handoff. ```text Goal/Seed: Status: pending | in_progress | completed | aborted | Blocked Repository state: Decisions: Changed files: Commands: Verification: Completed work: Remaining work: Open questions: Risks: Next step: Resume hints: Disposition: reported | applied | pending ``` For a task with a Seed, reference the exact contract section/path. For direct/no-Seed, record the minimal self-contained contract above and explicitly identify `Seed: none`; exclude unrelated or ambiguous old Seeds. ## 🔴 CHECKPOINT · 🛑 STOP · Write/Resume Boundary Before writing a new `Handoff` or continuing a `--resume`: - Fresh-read branch, HEAD, worktree and required evidence. A new Handoff need not already exist; an optional Seed may legitimately be absent. For resume, the referenced Handoff and any task-bound Seed must be readable. Missing or unreadable required artifacts are `Unverifiable`, not permission to reconstruct them from guesses. - STOP and mark `Blocked` when evidence conflicts or the `Seed` contract has drifted; do not resolve either condition inside the `Handoff`. - STOP before writing if atomic replacement cannot be completed or readback fails; use `.tigerkit/handoff.md` by default and honor an explicit `--output ` exactly. - STOP at any product, Git, or remote publication approval boundary; the artifact does not grant that permission. - If none of these conditions applies, continue without asking an extra question for a routine artifact update. ## Resume `--resume` requests resuming work by comparing the `handoff snapshot` against the current Git and files. First, fresh-read: - the exact `handoff` and its task-bound Seed when referenced; otherwise its self-contained no-Seed contract - `branch`/`HEAD`/`worktree` - changed files - relevant verification evidence - exact current remote state only when the next approved action depends on that PR; do not discover other open PRs Then classify drift. | Classification | Action | | --- | --- | | None | Continue from `Next step` without additional questions | | Nonessential `drift` | Record it and continue | | Significant progress `drift` | Update the `Handoff` from current evidence and confirm only the necessary decisions | | `Seed` contract `drift` | Do not resolve it in the `Handoff`; report that re-entering `tk-prep` is required | | Conflict | Show the incompatible evidence and mark `Blocked` | | unverified | If the required state cannot be confirmed, mark `Unverifiable` | `--resume` may authorize continuing the work, but it does not replace approval to change the `Seed`’s `goal/scope/decision/AC` or permission to publish remotely. ## Output After successfully creating a new `handoff`, show only the path, current status, and next action briefly in chat. Do not dump the full `Handoff` body or evidence ledger. When resuming, explain completed work, remaining work, blockers, and the immediate next action in a way that is easy for a person to understand. Do not use `.tigerkit/` as an archive, current pointer, or global state. Do not modify `.gitignore` or automatically commit/publish.