Preserve session state with ak:handoff

Use ak:handoff when you are ending a session, switching context, or moving work to a fresh agent. The Skill preserves the goal, current state, decisions, evidence, blockers, and dependencies from the working conversation, then saves the same concise handoff inside the project.

Choose ak:handoff for conversation continuity

Use ak:handoff when

• A fresh session needs the current goal and the reasoning behind decisions.
• Work is incomplete and the next session should avoid repeating discovery.
• You need to preserve rejected approaches, traps, blockers, or missing verification alongside current state.
• The handoff should point to plans, issues, commits, diffs, tests, and files rather than copy them.

Choose another workflow when

• You need a repository-derived status report across branches, worktrees, plans, roadmaps, and history. Use ak:watzup.
• You need chronological reflection after meaningful work. Use ak:journal.
• You need a durable product decision or current policy. Update its ADR or documentation owner; a handoff is not durable authority.
• You need to implement, commit, publish, or deploy. Use the matching workflow and authorize those effects separately.

Run a cross-Kit product-launch handoff

Prepare one bounded engineering request from the approved launch contract. The handoff should let Engineer Kit plan safely without reconstructing marketing decisions or receiving publication authority.

Engineer returns the implemented behavior, preview or artifact, test evidence, known limitations, and rollout/rollback requirements. Marketing then checks the result against ak:launch-strategy, updates the campaign and measurement plan, and obtains separate approval for publication, spend, or production changes.

Reissue the handoff when the approved message, audience, acceptance criteria, or delivery boundary changes. Do not append unrelated work to an already active handoff.

Prepare safe handoff context

Before starting:

• Complete Onboarding and install Marketing Kit for the current runtime and scope.
• Open the project and read its instructions, relevant plan, and any previous handoff for the same focus.
• Identify the source artifacts that prove current state and verification.
• Decide the next-session focus; this is optional but helps keep the report bounded.
• Remove secrets, tokens, passwords, private URLs, customer data, and personal data from the conversation material to be retained.

The project must have a plans directory for the canonical output. If it does not, the Skill asks for a safe project-local output location before writing.

Invoke the Skill

/ak:handoff "Continue review of the launch brief. Preserve approved audience decisions, source pointers, unresolved legal review, and validation status. Redact customer details"

/ak:handoff "Continue review of the launch brief. Preserve approved audience decisions, source pointers, unresolved legal review, and validation status. Redact customer details"

$ak:handoff "Continue review of the launch brief. Preserve approved audience decisions, source pointers, unresolved legal review, and validation status. Redact customer details"

Read Runtime adapters before assuming each runtime exposes the same amount of prior conversation or project context.

Understand the stages

1. Load governing context. The Skill reads project instructions, relevant plans, and a previous handoff for the same focus when one exists.
2. Extract session state. It identifies the goal, why it matters, current state, key decisions and rationale, rejected approaches, blockers, verification, and open dependencies.
3. Replace copies with pointers. It references source files, plans, issues, ADRs, commits, diffs, and tests rather than embedding large artifacts.
4. Redact sensitive content. It removes secrets, credentials, private URLs, customer data, and personal data. When credentials matter, it names only a safe approved location.
5. Render the required shape. The handoff includes the exact sections shown below and ends with a short prompt telling the next agent to read and verify the listed sources before acting.
6. Persist one report. The Skill outputs one fenced Markdown block and saves the same content to plans/reports/handoff-YYYYMMDD-HHmm-<slug>.md.

Keep the handoff private and non-authoritative

• Write only inside the agreed project or reports location.
• Do not copy root instructions, large diffs, full plans, customer records, or credential values into the report.
• Record decisions that were actually made; do not introduce a new decision in the handoff.
• Describe open work as state and dependencies. The fresh-agent prompt must require repository verification before action.
• The file write does not authorize Git staging, commit, push, publication, deployment, outreach, account mutation, spend, or external network access.
• A handoff is not proof that branch, provider, campaign, or repository state remained unchanged after it was generated.

Verify the output

A complete run should provide:

• One concise fenced Markdown block in the response.
• The same content at plans/reports/handoff-YYYYMMDD-HHmm-<slug>.md, or at a separately approved safe location when the project has no plans directory.
• All required sections, concrete verification status, and source pointers.
• Explicit blockers and unresolved dependencies.
• Redaction of secrets, private URLs, customer data, and personal data.
• A final fresh-agent prompt that requires the listed files to be read and the handoff to be checked against current repository state.

Open the saved file and compare it with the response block. Then review the repository diff before deciding whether the report should enter version control.

Troubleshoot safely

Continue with the Marketing Kit overview or Projects, artifacts, and checkpoints for broader persistence and ownership concepts.

Know the current limits

• The Skill can preserve only conversation and project context visible in the current session.
• It does not independently scan every branch, worktree, remote ref, roadmap, or repository-history surface; ak:watzup owns that report.
• Redaction is a workflow requirement, not a guarantee that sensitive data was never exposed earlier in the session. Human review remains necessary.