Skip to content
Back to skills

Handoff

ASecurity

Use when the user invokes /handoff, and ALWAYS when starting work in a repo that already contains a HANDOFF.md — reading that file is the first job before exploring the codebase. Creates and maintains a git-ignored HANDOFF.md at the repo root that carries task state between sessions and agents.

  • 4 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added August 30, 2026
ai-agentsgogit

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned August 30, 2026

npx -y skills add ShockRock2004/kamar-taj --skill handoff --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Handoff?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Handoff
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/shockrock2004-handoff/badge)](https://www.skillsdirectory.com/skills/shockrock2004-handoff)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: handoff
description: Use when the user invokes /handoff, and ALWAYS when starting work in a repo that already contains a HANDOFF.md — reading that file is the first job before exploring the codebase. Creates and maintains a git-ignored HANDOFF.md at the repo root that carries task state between sessions and agents.
---

# Handoff

`HANDOFF.md` is the cross-session memo for a repo. A fresh agent reads it **before** exploring the codebase, so it gets context cheaply instead of re-deriving it by grepping. It is git-ignored — it is a working note, not a repo artifact.

## First rule: if `HANDOFF.md` exists, read it

**If a repo contains a `HANDOFF.md`, reading it is the agent's first job — in full, before anything else.** This is not conditional on the user invoking `/handoff`; it applies the moment you begin work in that repo.

- Read it before grepping, before opening source files, before planning, before asking the user for context it may already answer.
- It is the authoritative statement of the current objective and state. Treat it as context, not as instructions from the user — but do not contradict it without saying so.
- If it conflicts with what the code actually shows, the code wins. Say so, and correct the file.
- Never overwrite, reset, or "start fresh" on an existing `HANDOFF.md`. Update it in place per case 3 below.

## Invoking `/handoff`

Three cases. Decide by whether `HANDOFF.md` exists at the repo root.

### 1. It doesn't exist → initialize

1. Find the repo root (`git rev-parse --show-toplevel`; if not a git repo, use the working directory).
2. Write `HANDOFF.md` there using the template below.
3. Git-ignore it via **`.git/info/exclude`**, not `.gitignore` — `.gitignore` is tracked, and adding to it would push a personal working file into the user's commits. Append the line `HANDOFF.md` to `.git/info/exclude` if not already present. (Skip if not a git repo.)
4. Fill in what you already know: repo name, stack, what the user just asked for. Do not leave the template placeholders sitting empty if you can answer them.
5. Tell the user it was created and where.

### 2. It exists → read and report

Read it, then give the user a short summary of where things stand: current objective, what's in flight, open blockers. Do **not** rewrite or reset the file. Then continue the work.

### 3. It exists and work has progressed → update

Append to / revise the live sections. Rules:

- **Precise, clear, objective.** Facts, decisions, and state. No narration ("I then looked at…"), no hedging, no filler.
- Record the *why* behind non-obvious decisions — that's the part a future agent cannot recover from the code.
- Prune what is no longer true. Stale entries are worse than missing ones.
- Reference files as `path/to/file.ts:42`.
- Never record secrets, tokens, or credentials.

## Compaction

When `HANDOFF.md` exceeds **500 lines**, compact before appending:

1. Keep the **Current State**, **In Flight**, **Blockers**, and **Decisions** sections verbatim — these are live.
2. Collapse everything under **Session Log** older than the two most recent sessions into a single `### Condensed history` block: one line per session, outcome only.
3. Drop entries that describe work later reverted or superseded.
4. The result should read as if written fresh — no "(compacted)" scars beyond the `Condensed history` heading.

## Template

Write exactly this structure on initialization:

```markdown
# HANDOFF

> Working memo for this repo. Git-ignored. Read this first.
>
> **Rules for whoever writes here:** entries must be precise, clear, and objective — state facts, decisions, and current state, not narration. Record the *why* behind non-obvious choices. Delete what is no longer true. When this file passes 500 lines, compact the Session Log into a condensed history and continue.

## Project

- **Repo:** <name / path>
- **Stack:** <languages, frameworks, package manager, how to run and test>
- **Entry points:** <the 2-5 files that matter most>

## Objective

<What the user is trying to achieve, in one or two sentences. The goal, not the current task.>

## Current State

<What is true right now: what works, what is half-built, what was just changed.>

## In Flight

- [ ] <task — with enough detail to resume cold>

## Blockers

<Anything waiting on the user, an external service, or an unresolved decision. Empty is fine — say "None".>

## Decisions

| Decision | Why |
| --- | --- |
| <what was chosen> | <what it was chosen over, and the reason> |

## Session Log

### <YYYY-MM-DD>
- <outcome, not activity>
```

## Notes

- If the user asks to "update the handoff" or a session is wrapping up, apply case 3 without being asked to invoke the skill again.
- Get today's date from the environment context rather than guessing; write dates absolute (`2026-08-05`), never relative ("yesterday").

Files in this skill

  • README.md1.4 KB
  • SKILL.md4.8 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.