agentleFS
cf-xcf-x/project-handoff-skill/project-handoff/SKILL.md

project-handoff

Skill0 starsChanged 3 months agoMITView on GitHub

Create or update a concise, evidence-backed HANDOFF.md in the correct user-confirmed project directory before context is cleared or work is handed to another agent. Use only when explicitly invoked as $project-handoff; never invoke implicitly.

8 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. 0 are common, 11 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Create a current snapshot that lets a new agent continue the work without the conversation.

    line 8
  2. Distinctive:

    Prefer an explicit directory supplied with the invocation.

    line 14
  3. Very specific:

    Treat the current working directory, Codex workspace root, version-control root, and project markers such as README.md, AGENTS.md, …

    line 16
  4. Very specific:

    If the destination is missing or ambiguous, show the likely candidates and ask one concise question: HANDOFF.md 要写到哪个目录? Do not guess.

    line 18
  5. Very specific:

    If multiple independent projects were changed, prefer a separate HANDOFF.md for each and confirm their destinations before writing.

    line 20
  6. Distinctive:

    After resolving each target directory:

    line 24
  7. Distinctive:

    If version control exists, inspect its status and relevant changes.

    line 27
  8. Distinctive:

    Use existing test or validation evidence.

    line 28
  9. Very specific:

    Read an existing HANDOFF.md before updating it.

    line 29
  10. Distinctive:

    Do not rely only on conversation memory when filesystem evidence is available.

    line 31
  11. Very specific:

    Create or update <confirmed-target>/HANDOFF.md as a concise current-state document with these sections:

    line 35
  12. Distinctive:

    Use absolute dates, concise prose, and paths instead of transcript-style narration.

    line 64
  13. Distinctive:

    Never include credentials, tokens, private personal information, environment-file contents, or large raw logs.

    line 65
  14. Distinctive:

    Keep the file as the latest handoff snapshot rather than an append-only history.

    line 66
  15. Distinctive:

    every required section is present.

    line 75
  16. Distinctive:

    no sensitive information was copied into the document.

    line 78

“Common” is measured: kept by at least 6 in 10 of the 4 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

Project Handoff

Create a current snapshot that lets a new agent continue the work without the conversation. Do not clear the conversation yourself.

1. Resolve the destination

Determine the handoff target before writing:

  1. Prefer an explicit directory supplied with the invocation. Normalize it and verify that it exists.
  2. Otherwise, infer candidates from directories and files actually discussed, read, created, or edited in this session.
  3. Treat the current working directory, Codex workspace root, version-control root, and project markers such as README.md, AGENTS.md, package.json, or pyproject.toml only as signals. None is authoritative by itself, and a project need not use Git.
  4. Proceed without asking only when one candidate is clearly supported by the session evidence.
  5. If the destination is missing or ambiguous, show the likely candidates and ask one concise question: HANDOFF.md 要写到哪个目录? Do not guess.

If multiple independent projects were changed, prefer a separate HANDOFF.md for each and confirm their destinations before writing.

2. Inspect the actual state

After resolving each target directory:

  • Review the relevant session work and inspect the target's structure, instructions, key documentation, implementation files, and outputs.
  • If version control exists, inspect its status and relevant changes. If it does not, continue without treating that as an error.
  • Use existing test or validation evidence. Run only lightweight, safe checks when useful; do not install dependencies or make unrelated project changes.
  • Read an existing HANDOFF.md before updating it. Keep still-valid information, replace stale status, and move newly completed work out of the remaining-work section.

Do not rely only on conversation memory when filesystem evidence is available.

3. Write HANDOFF.md

Create or update <confirmed-target>/HANDOFF.md as a concise current-state document with these sections:

# Project Handoff

> Updated: YYYY-MM-DD
> Target: /absolute/confirmed/path

## Current state and structure

## Completed cases

## Decisions and conventions

## Remaining work and exact next step

## Pitfalls and dead ends

## Validation, risks, and open questions

Apply these rules:

  • Give completed cases concrete outcomes and project-relative file or directory paths.
  • Record decisions, technical choices, style or naming conventions, and their reasons. Include evidence locations when useful.
  • Make remaining work actionable: priority, exact starting file or command, blockers, and the condition for completion.
  • Record failed approaches and why they failed so the next agent does not repeat them.
  • State tests or checks run and their results. Explicitly say what was not verified.
  • Distinguish observed facts from session claims and inferences. Mark uncertainty as 待确认; never fabricate completion, decisions, or test results.
  • Use absolute dates, concise prose, and paths instead of transcript-style narration.
  • Never include credentials, tokens, private personal information, environment-file contents, or large raw logs.
  • Keep the file as the latest handoff snapshot rather than an append-only history.

Modify only the intended HANDOFF.md unless the user explicitly requests other changes.

4. Verify and report

Re-read the finished file and confirm that:

  • it is in the confirmed directory;
  • every required section is present;
  • the next action is specific enough for a new agent to begin immediately;
  • claims, paths, dates, and validation status agree with the available evidence;
  • no sensitive information was copied into the document.

Report the written path, a brief summary, and any unresolved uncertainty. Stop there so the user can review the handoff before manually running /clear.

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.