agentleFS
loonylabsloonylabs/claude-setup/skills/handover/SKILL.md

handover

Skill0 starsChanged 3 months agoMITView on GitHub

Rewrites docs/HANDOVER.md — the baton for the next session: where things stand, what is open, what to read first.

51 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use harness-init, incident and 5 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • steptianSkill

    harness-init

    初始化 .harness 开发框架,集成代码修改影响范围评估和测试覆盖建议功能。触发词:'初始化新项目'、'harness init'、'更新 harness'、'分析影响范围'、'评估修改影响'

    Also in 3 projects that use this

  • JkudjoSkill

    incident

    Production incident response — structured triage, hypothesis tree, safe remediation, incident record

    Also in 3 projects that use this

  • nicolasestremSkill

    brainstorm

    Structured idea generation and solution exploration with systematic analysis.

    Also in 3 projects that use this

  • BlockSkill

    plan

    Draft a TDD, PRD, or lightweight plan in the conversation without committing it.

    Also in 3 projects that use this

  • MicrosoftSkill

    caveman

    Ultra-compressed response style that reduces output token count while preserving technical accuracy, with intensity levels and auto-clarity safety rules

    Also in 3 projects that use this

  • Hugging FaceSkill

    implement

    Make tests pass. Invoke after /write-tests produces failing tests.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 0 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 37 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Write this project's session baton to docs/HANDOVER.md — one fixed path, one file, replaced every time.

    line 8
  2. Very specific:

    Read the existing docs/HANDOVER.md: if there is one. You are updating a baton, not writing on a blank page.

    line 45
  3. Very specific:

    Check the file is tracked: If docs/ is gitignored, overwriting destroys the previous baton with no history to fall back on — say so rather …

    line 59

“Common” is measured: kept by at least 6 in 10 of the 37 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Handover

Write this project's session baton to docs/HANDOVER.md — one fixed path, one file, replaced every time. Git carries the history. A second dated file is never the answer: HANDOVER-2026-07-29-abend.md sitting beside HANDOVER-2026-07-29.md is the failure mode this command exists to end.

The global CLAUDE.md has the next session read this file and check it against git, so it needs no cover note and no copy-paste.

LANGUAGE RULE

Talk to the user in the language they write in. The file itself follows the project's documentation language (English unless that project says otherwise).

When to write it

When a step lands — not when the session ends. A session that runs out of context cannot write a baton, and autocompact is off on this machine, so "at the end" in practice means "often never". If the baton's HEAD is already behind the tree, that is the signal to refresh it, not a normal state.

What this file is — and is not

A baton, not a diary: where are we, what is open, what should the next session read first. It is read in every session of this project, so its length is a recurring cost — target ~80 lines, hard ceiling 120.

Does NOT belong hereBelongs in
Standing rules, conventionsCLAUDE.md
Command/tooling tables, environment setupCLAUDE.md
Agreed working styleCLAUDE.md
Architecture, specs, referencedocs/
The narrative of what got builtgit log and the commit messages
Inventory numbers a command reproducesname the command instead

Steps

  1. Read the existing docs/HANDOVER.md if there is one. You are updating a baton, not writing on a blank page.
  2. Promote before you overwrite. Anything durable in the old baton — a trap, a corrected assumption, a rule that turned out to hold — goes into its target document FIRST (CLAUDE.md, the project's trap ledger, the relevant doc). Overwriting is exactly where knowledge gets lost; this step is the guard. Then carry every still-valid dead end forward into the new file.
  3. Measure the current state, never recall it:
    • branch, git status --short, short HEAD sha
    • what is uncommitted — and whether it is this session's work or somebody else's
    • whether HEAD is pushed, and what any deployed environment actually runs
    • the test/gate result. Not run ⇒ that is what you write.
  4. Write the file from the template below, replacing it completely. Create docs/ if the project has none.
  5. Check the file is tracked. If docs/ is gitignored, overwriting destroys the previous baton with no history to fall back on — say so rather than losing it silently.
  6. Report in one or two sentences what the baton now says.

Template

# Handover

**Written:** <YYYY-MM-DD HH:MM> · **Branch:** `<branch>` · **HEAD:** `<short-sha>`
**Gate:** <"412 tests green, tsc clean" | "not run"> · **Tree:** <clean | N files, mine/foreign>
**Pushed:** <yes | N commits local only | deployed env runs `<sha>`>

> Run `git log <short-sha>..HEAD --oneline` before using anything below. Any output
> means this is a lead, not the state — check each open item against the tree
> before starting it. Items may already be done.

## Where we are

<2-4 sentences: what was being built, and how far it actually got. Blocking
numbers only — not an inventory.>

## In flight

- [ ] <Open item — what it is, and what "done" looks like>

## Needs your decision

<Only what is blocked on the USER rather than on work. Per item: the question, the
variants, a recommendation, and what each option would mean. Omit if empty.>

## Read first

- `<path>` — <why this one matters for the next step>
- `<path>` — **read yes, believe no**: <which part of it is out of date>

## Do not try again

<Carried forward across sessions. Each entry: what was tried, and the MEASUREMENT
that killed it. An entry stays until it is promoted into a document or made
impossible by the code. This section is the most valuable thing in the file —
never trim it for space; trim the narrative instead.>

## Running right now

<Only if something actually is: a background run, a deploy, a migration.
Otherwise leave the section out.>

Rules

  • Overwrite. Never create a dated sibling file.
  • Carry gaps verbatim. Gate not run ⇒ write "not run". Never record a tidier state than you actually verified — a baton that overstates is worse than none.
  • Do not restate the project. The next session already loads CLAUDE.md; this file adds only what CLAUDE.md cannot know — the state of the work right now.
  • Name foreign work as foreign, so the next session does not sweep somebody else's files into a commit.
  • Over the ceiling? Cut before writing. The oldest entries get promoted into docs/ and linked from here — never silently dropped.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.