agentleFS
DojoGenesisDojoGenesis/openclaw-plugin/skills/handoff-protocol/SKILL.md

handoff-protocol

Skill0 starsChanged 9 months agoMITView on GitHub

Hand off work between agents cleanly, preserving all context and enabling autonomy. Use when one agent completes work and another must begin. Trigger phrases: 'prepare this for handoff', 'hand off to the implementation agent', 'is this handoff package complete', 'ensure nothing is lost in the transition'.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always: use this skill when one agent's work is complete and another agent must begin the next phase.

    line 30
  2. Distinctive:

    Manus → Implementation Agent: When a specification is complete and ready for implementation.

    line 31
  3. Distinctive:

    Manus → Cipher: When research is complete and a creative or divergent perspective is needed.

    line 32
  4. Distinctive:

    Before initiating the handoff, the sending agent must verify the package against the Handoff Checklist in Section V.

    line 45
  5. Distinctive:

    No Implicit Context: If it's not in the handoff package, it doesn't exist.

    line 154
  6. Very specific:

    Standardize Handoff Locations: Create a handoffs/ directory in each project to store these packages, creating a clear audit trail.

    line 157
  7. Distinctive:

    When running inside the Dojo Genesis plugin:

    line 162

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

OpenClaw Integration: This skill is invoked by the Dojo Genesis plugin via /dojo run handoff-protocol. The agent receives project context automatically via the before_agent_start hook. Use dojo_get_context for full state, dojo_save_artifact to persist outputs, and dojo_update_state to record phase transitions and decisions.

Agent Handoff Protocol Skill

Version: 1.0
Created: 2026-02-04
Author: Manus AI
Purpose: To provide a clear, repeatable protocol for handing off work between agents (e.g., Manus to implementation agents, Manus to Cipher), ensuring no loss of context and a high probability of success.


I. The Philosophy: The Sacred Relay

In a multi-agent ecosystem, a handoff is a sacred relay. It is the moment where one agent passes the baton of responsibility to another. A fumbled handoff leads to dropped context, wasted effort, and a broken workflow. A clean handoff is a moment of trust and shared understanding, where the receiving agent is not just given a task, but is fully equipped to carry it forward.

This protocol transforms the handoff from a hopeful transfer into a rigorous, verifiable exchange. It is an act of respect for the receiving agent, acknowledging that their ability to succeed is entirely dependent on the quality of the context they are given.


II. When to Use This Skill

  • Always use this skill when one agent's work is complete and another agent must begin the next phase.
  • Manus → Implementation Agent: When a specification is complete and ready for implementation.
  • Manus → Cipher: When research is complete and a creative or divergent perspective is needed.
  • Any Agent → Any Agent: Whenever responsibility for a task is transferred.

III. The Handoff Workflow

Step 1: Prepare the Handoff Package

The sending agent is responsible for preparing a complete and self-contained "handoff package." This is a markdown document that contains everything the receiving agent needs to know. Use the template from Section IV.

Step 2: Verify the Package with the Checklist

Before initiating the handoff, the sending agent must verify the package against the Handoff Checklist in Section V. This is a self-assessment to ensure quality.

Step 3: Initiate the Handoff

The sending agent initiates the handoff by creating a task for the receiving agent, with the handoff package as the primary input.

Example Handoff Task:

  • Agent: Implementation Agent (Zenflow, Claude Code, etc.)
  • Task: Implement the v0.0.26 Breadcrumb feature.
  • Input: handoffs/v0.0.26/01_breadcrumb_handoff.md

Step 4: The Receiving Agent's Acceptance

The receiving agent's first action is to read the handoff package and confirm that it has everything it needs to proceed. If the package is incomplete, the receiving agent must immediately return the task to the sender with a request for more information.

Example Acceptance: "Handoff package received and verified. I have all necessary context to proceed with the implementation. Work will now begin."

Example Rejection: "Handoff package is incomplete. The link to the specification is broken. Please correct and resubmit."


IV. Handoff Package Template

# Agent Handoff Package

**From:** [Sending Agent Name]
**To:** [Receiving Agent Name]
**Date:** [YYYY-MM-DD]
**Subject:** Handoff of [Task/Project Name]

---

## 1. Objective

> [A single, clear sentence describing the receiving agent's primary goal.]

---

## 2. Required Context

[A comprehensive list of all files, documents, and resources the receiving agent MUST read before starting work. Use full paths.]

**Core Documents:**
-   **Specification:** `[path/to/specification.md]`
-   **Status:** `[path/to/STATUS.md]`

**Key Conversation Summaries:**
-   `[path/to/conversation_summary_1.md]`
-   `[path/to/conversation_summary_2.md]`

**Relevant Seeds or Skills:**
-   `[path/to/seed.md]`
-   `[path/to/skill.md]`

**Pattern Files / Code Examples:**
-   `[path/to/pattern_file_1.tsx]`
-   `[path/to/pattern_file_2.go]`

---

## 3. Task Definition

[A clear and unambiguous definition of the task to be performed. If this is an implementation agent handoff, this section should contain the full implementation prompt.]

---

## 4. Definition of Done

[How will we know the receiving agent's work is complete? This must be a list of binary, testable success criteria.]

-   [ ] [Success Criterion 1]
-   [ ] [Success Criterion 2]
-   [ ] [Success Criterion 3]

---

## 5. Constraints & Boundaries

[What are the explicit constraints on the receiving agent's work?]

-   **DO NOT** modify files outside of the specified scope.
-   **DO NOT** make architectural decisions without consulting [Sending Agent Name].
-   **MUST** follow the patterns established in the provided pattern files.

---

## 6. Next Steps (After Completion)

[What happens after the receiving agent is done? Who takes the next handoff?]

-   Upon completion, notify [Next Agent Name] and hand off the results for the next phase (e.g., QA, documentation).

V. Handoff Checklist (for Sending Agent)

  • Is the Objective a single, clear sentence?
  • Are all links in the Required Context section valid and pointing to the correct files?
  • Is the Task Definition unambiguous and complete?
  • Is the Definition of Done a list of testable, binary criteria?
  • Are the Constraints clear and explicit?
  • Is the next step after completion clearly defined?

VI. Best Practices

  • No Implicit Context: If it's not in the handoff package, it doesn't exist. Never assume the receiving agent knows something.
  • Over-communicate: It is better to provide too much context than too little.
  • The Receiver is the Gatekeeper: Empower the receiving agent to reject incomplete handoffs. This maintains quality across the ecosystem.
  • Standardize Handoff Locations: Create a handoffs/ directory in each project to store these packages, creating a clear audit trail.

OpenClaw Tool Integration

When running inside the Dojo Genesis plugin:

  1. Start by calling dojo_get_context to retrieve full project state, history, and artifacts
  2. During the skill, follow the workflow steps documented above
  3. Save outputs using dojo_save_artifact with the artifacts output directory
  4. Update project state by calling dojo_update_state to record skill completion and any phase transitions

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.