@trespies-source/dojo-genesis-plugin 1.0.0

package/skills/era-architecture/SKILL.md

@@ -0,0 +1,166 @@
+---
+name: era-architecture
+description: Architect multi-release eras with shared vocabulary, architectural constraints, and design language for conceptual coherence. Use when planning major product pivots across multiple releases, defining conceptual architecture before decomposing into releases, or transitioning between product eras. Trigger phrases: 'plan this era', 'define the architecture for multiple releases', 'transition to a new era', 'create a multi-release vision', 'establish conceptual coherence across releases'.
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run era-architecture`.
+> 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.
+
+# era-architecture
+
+## I. The Philosophy
+
+An era is not a list of releases. It's a conceptual architecture that coordinates multiple releases under shared constraints.
+
+When you go from "we need to rebuild the frontend" to "we need a complete multi-release era plan," you're making a qualitative shift. Instead of asking "what should v0.2.1 do?" you're asking "what vocabulary, architectural patterns, and design language will span all releases in this era?"
+
+This shift matters because:
+- **Coherence**: Without a shared architecture, releases drift apart. Release A uses one data model, Release B contradicts it.
+- **Dependency clarity**: You can't plan releases independently. A shared design language in Release 1 enables faster work in Release 2.
+- **Decision efficiency**: The era's conceptual architecture is the constitution that downstream decisions must obey. This prevents constant re-litigation of foundational choices.
+
+The key insight: scouts explore the facets (not releases). From those explorations, you extract the era's architecture (not the other way around).
+
+## II. When to Use This Skill
+
+**Use era-architecture when:**
+- Planning a major product pivot that spans 3+ releases
+- You need to define shared conceptual vocabulary before decomposing into releases
+- Transitioning between product eras (e.g., engine-building → fresh shell → social layer)
+- The scope is too large for one release but needs coherent vision across all releases
+- You need cross-cutting architectural decisions (data model, design language, navigation patterns)
+
+**Do NOT use era-architecture when:**
+- Planning a single release → use `strategic-scout` + `parallel-tracks`
+- Writing specs → use `specification-writer` or `frontend-from-backend`
+- Converting specs to prompts → use `spec-constellation-to-prompt-suite` or `zenflow-prompt-writer`
+- Exploring one strategic question → use `strategic-scout`
+
+## III. The Workflow (7 Steps)
+
+### Step 1: Name the Era and Its Predecessor
+
+Give the era a name that captures its purpose (e.g., "The Fresh Shell", "The Engine", "The Social Layer").
+
+Document what the previous era accomplished and what it leaves behind. Define the handoff: what assets/code/patterns carry forward, what gets archived.
+
+This framing prevents the new era from being aimless. It grounds the work in what came before and what you're building toward.
+
+### Step 2: Scout the Facets
+
+Run 3-5 strategic scouts, each exploring a different facet of the era. Facets are not releases—they're architectural questions:
+- Navigation/information architecture
+- Data model and persistence
+- Design language and UX philosophy
+- Backend integration strategy
+- Social/collaboration strategy (if applicable)
+
+Each scout produces insights and open questions. Gather human decisions on those open questions before proceeding to Step 3. This is where the team shapes the architecture.
+
+### Step 3: Define the Conceptual Architecture
+
+From the scout insights and decisions, extract the era's conceptual vocabulary:
+- **Core metaphors**: What's the guiding image? (e.g., "garden", "cognitive routes", "bonsai")
+- **Architectural patterns**: What repeating structures apply everywhere? (e.g., "entity-as-lens", "content-edge transitions")
+- **Design language**: Colors, typography, interaction patterns that all releases obey
+- **Data model**: The types and relationships that span all releases
+
+Write these as constraints: every release in the era must obey them. This is the era's constitution—it doesn't change per release.
+
+### Step 4: Decompose into Releases
+
+Define 3-7 releases that build on each other. Each release should have:
+- A clear theme/name (e.g., "The Foundation", "The Shallow End", "The Deep End")
+- Scope: what's built
+- Dependencies: what must exist first
+- Estimated effort
+
+The first release is the thickest (it builds foundations). Later releases are thinner because the patterns are established. Some releases can run in parallel if they don't share dependencies.
+
+### Step 5: Build the Dependency Graph
+
+Map release-level dependencies (which releases block which). Map spec-level dependencies within releases (which specs must exist before others). Identify the critical path and parallel opportunities.
+
+### Step 6: Write the Master Plan
+
+Use the Master Plan Template (Section IV). The master plan is the single commissioning document for the entire era. Include vision, conceptual architecture summary, release roadmap, dependency graph, constraints, and parallel track allocation.
+
+The master plan is a living document—decisions from later scouts update it. But the core architecture should remain stable.
+
+### Step 7: Drop into Single-Release Work
+
+For the first release, write detailed specs. Then convert specs to implementation prompts. Commission and execute the first release.
+
+Before starting the next release, check: do the conceptual architecture constraints still hold? Do decisions from the first release affect later releases? Update the master plan if needed.
+
+## IV. Master Plan Template
+
+```markdown
+# [Era Name] Master Plan
+**Author:** [names]
+**Status:** [Active/Complete]
+**Era:** v[X].0 through v[X].N
+
+## 1. Vision
+[1-2 sentences: what this era accomplishes]
+
+## 2. What Came Before
+[Brief summary of previous era, what carries forward]
+
+## 3. Conceptual Architecture
+### Core Metaphors
+### Architectural Patterns
+### Design Language
+### Data Model
+
+## 4. Release Roadmap
+| Version | Name | Focus | Dependencies | Est. Effort |
+
+## 5. Dependency Graph
+[ASCII or description showing release ordering]
+
+## 6. Constraints
+[Rules that all releases must obey]
+
+## 7. Parallel Track Allocation
+| Release | Tracks | Can Parallel With |
+
+## 8. Commissioned Specifications
+| Spec | Release | Status |
+
+## 9. Next Steps
+[Current focus and what follows]
+```
+
+## V. Best Practices
+
+- **Eras need names**: Names create shared vocabulary for the team. "The Fresh Shell" is better than "v0.2 refactor".
+- **Scout facets, not releases**: Architecture emerges from cross-cutting exploration, not from asking "what should v0.2.1 do?"
+- **Conceptual architecture is the output**: It constrains everything downstream and prevents releases from drifting apart.
+- **First release is heaviest**: Later releases feel lighter because the patterns are established.
+- **Master plans are living documents**: Use decision protocols when decisions arrive that change scope.
+- **Don't over-plan later releases**: Define theme and rough scope, but save detailed specs for when earlier releases are done and the architecture has been validated in practice.
+
+## VI. Quality Checklist
+
+- [ ] Era has a name and a clear relationship to its predecessor
+- [ ] 3+ facets scouted with insights and decisions recorded
+- [ ] Conceptual architecture defined (metaphors, patterns, design language, data model)
+- [ ] 3-7 releases defined with themes, scope, and dependencies
+- [ ] Dependency graph shows ordering and parallel opportunities
+- [ ] Master plan written as single commissioning document
+- [ ] First release has detailed specs ready for implementation
+- [ ] Constraints are clear enough that any release can check compliance
+---
+
+## 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
+

package/skills/era-architecture/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-era-architecture",
+  "version": "1.0.0",
+  "description": "Architect multi-release eras with shared vocabulary",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "research", "analysis"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}

package/skills/file-management/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: file-management
+description: Apply flexible principles and patterns for intuitive file organization adapted to project context. Use when starting new projects or refactoring disorganized structures. Trigger phrases: "organize this project structure", "plan a file layout", "design a directory hierarchy", "improve folder organization", "create a project structure".
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run file-management`.
+> 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.
+
+# File Management & Organization Skill
+
+**Version:** 1.0  
+**Created:** 2026-02-04  
+**Author:** Manus AI  
+**Purpose:** To provide a set of flexible principles and recommended patterns for file and directory organization, adaptable to diverse project environments.
+
+---
+
+## I. The Philosophy: A Place for Everything, and Everything in Its Place
+
+Good file organization is not about rigid, universal rules. It is about creating a system where the location of a file is intuitive and predictable within the context of its own project. A well-organized project is a pleasure to work in; a chaotic one is a source of constant friction.
+
+This skill provides a set of guiding principles, not a strict mandate. It is a flexible framework that can be adapted to the unique needs of any project, from a simple static website to a complex multi-service application. The goal is to create a sense of order and clarity that makes the project easier to understand, navigate, and maintain.
+
+---
+
+## II. When to Use This Skill
+
+-   **When starting a new project:** Use these principles to establish a clean and logical directory structure from the outset.
+-   **When a project feels disorganized:** Use this skill to guide a refactoring of the existing file structure.
+-   **When onboarding a new team member or agent:** Use this as a guide to explain the project's organizational philosophy.
+
+---
+
+## III. Core Principles
+
+1.  **Group by Feature or Domain:** Whenever possible, group files related to a single feature or domain together. This is often preferable to grouping by file type (e.g., all controllers in one directory, all models in another).
+
+2.  **Separate Public from Private:** Keep the public interface of a module or service separate from its internal implementation details.
+
+3.  **Keep the Root Directory Clean:** The root of your project should be as clean as possible, containing only essential configuration files, the main entry point, and a few key directories.
+
+4.  **Use a Consistent Naming Convention:** Choose a naming convention (e.g., `kebab-case`, `snake_case`, `PascalCase`) for your files and directories and stick to it.
+
+5.  **Document Your Structure:** A project's `README.md` or `ARCHITECTURE.md` should briefly explain the organizational philosophy of the project.
+
+---
+
+## IV. Recommended Patterns
+
+These are flexible patterns that can be adapted to different environments.
+
+### 1. The Generic Web Application
+
+This is a good starting point for many web applications.
+
+```
+/
+├── public/             # Static assets (images, fonts, etc.)
+├── src/                # Source code
+│   ├── api/            # Backend API handlers/controllers
+│   ├── components/     # Reusable UI components
+│   ├── lib/            # Shared libraries, utilities, and helpers
+│   ├── pages/          # Page-level components (if using a framework like Next.js)
+│   ├── services/       # Business logic and external API clients
+│   └── styles/         # Global styles
+├── tests/              # Tests
+├── .env                # Environment variables
+├── .gitignore
+├── package.json
+└── README.md
+```
+
+### 2. The AROMA-style Contemplative Repository
+
+This pattern is optimized for knowledge bases and contemplative practice repositories.
+
+```
+/
+├── seeds/              # Reusable patterns of thinking
+├── thinking/           # Philosophical reflections and insights
+├── conversations/      # Summaries of key discussions
+├── docs/               # Formal documentation (specifications, retrospectives)
+├── SKILLS/             # Reusable workflow skills
+├── prompts/            # Prompts for other agents (e.g., implementation agents)
+├── .gitignore
+└── README.md
+```
+
+### 3. The Go Backend Service
+
+A common structure for a Go backend service.
+
+```
+/
+├── cmd/                # Main application entry points
+│   └── api/            # The main API server
+├── internal/           # Private application and library code
+│   ├── handlers/       # HTTP request handlers
+│   ├── models/         # Database models
+│   └── store/          # Database access layer
+├── pkg/                # Public library code (if any)
+├── .gitignore
+├── go.mod
+└── README.md
+```
+
+---
+
+## V. Best Practices
+
+-   **Don't Over-Organize:** A flat structure is often better than a deeply nested one, especially in the early stages of a project.
+-   **Be Pragmatic:** The best structure is the one that works for your team and your project. Don't be afraid to deviate from these patterns if you have a good reason.
+-   **Refactor as You Go:** A project's file structure is not set in stone. As the project evolves, don't be afraid to refactor the file structure to better reflect the current state of the codebase.
+-   **Consistency is Key:** Whatever structure you choose, be consistent. An inconsistent structure is often worse than no structure at all.
+---
+
+## 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
+

package/skills/file-management/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-file-management",
+  "version": "1.0.0",
+  "description": "Organize files and directories flexibly",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "tools", "strategy"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}

package/skills/frontend-from-backend/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: frontend-from-backend
+description: Write production-ready frontend specifications deeply grounded in existing backend architecture to prevent integration issues. Use when building frontend features on a working backend or redesigning UI for an existing API. Trigger phrases: 'spec the frontend', 'write frontend spec from backend', 'ground the UI in this API', 'integrate this frontend', 'frontend implementation guide'.
+---
+
+> **OpenClaw Integration:** This skill is invoked by the Dojo Genesis plugin via `/dojo run frontend-from-backend`.
+> 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.
+
+# Write Frontend Spec From Backend Skill
+
+**Version:** 1.0
+**Created:** 2026-02-07
+**Author:** Manus AI
+**Purpose:** To provide a structured, repeatable process for writing high-quality frontend specifications that are deeply integrated with an existing backend, ensuring seamless development and reducing integration friction.
+
+---
+
+## I. The Philosophy: Grounding Before Building
+
+Frontend development in a full-stack application does not happen in a vacuum. The most common source of bugs, delays, and rework is a disconnect between the frontend implementation and the backend reality. This skill is built on a simple but powerful principle: **grounding before building**.
+
+By deeply understanding the existing backend architecture, APIs, and data models *before* writing a single line of frontend specification, we can prevent entire classes of integration problems. This process transforms specification writing from a creative exercise into a disciplined engineering practice, ensuring that what we design is not just beautiful, but buildable.
+
+---
+
+## II. When to Use This Skill
+
+-   **When planning a new frontend feature** that will interact with an existing backend.
+-   **When writing specifications for a UI redesign** of a feature that has a backend component.
+-   **When commissioning frontend work to an autonomous agent** like Claude Code, Zenflow, or other implementation agents.
+-   **When you feel a disconnect** between the frontend vision and the backend reality.
+-   **At the beginning of any major frontend development cycle**.
+
+---
+
+## III. The Workflow
+
+This workflow is a 5-step process that takes you from a high-level feature idea to a production-ready, backend-grounded specification.
+
+### Step 1: Deep Backend Analysis
+
+**Goal:** Achieve a comprehensive understanding of the existing backend architecture.
+
+1.  **Run `/repo-context-sync`:** Generate a comprehensive context map of the repository.
+2.  **Read Key Backend Files:**
+    -   `main.go` (or equivalent): Understand route registration and server setup.
+    -   `handlers/`: Read the handlers for the relevant feature areas.
+    -   `middleware/`: Understand the authentication and request lifecycle.
+3.  **Document APIs:** Map all relevant API endpoints, including methods, authentication requirements, request bodies, and success/error responses.
+4.  **Identify Integration Points:** For each part of the new frontend feature, identify the specific backend endpoint it will interact with.
+
+### Step 2: Comprehensive Feature Specification
+
+**Goal:** Write a production-ready specification for the new feature that leverages the existing backend.
+
+1.  **Write a Full Feature Spec:** Create a detailed document covering:
+    -   Executive summary and problem statement
+    -   Goals, non-goals, and user stories
+    -   Technical architecture (how frontend and backend will interact)
+    -   UI/UX wireframes and interaction flows
+    -   API contracts with request/response examples
+    -   Implementation plan (if multi-phased)
+    -   Security considerations
+2.  **Leverage Existing Backend:** Design the feature to use existing backend infrastructure wherever possible. Avoid proposing new backend features unless absolutely necessary.
+
+### Step 3: Integration Guide Creation
+
+**Goal:** Create a practical guide for developers on how to wire the new frontend to the backend.
+
+1.  **Create a Track-by-Track Guide:** If the feature is being built in parallel tracks, create a guide for each track.
+2.  **Document Authentication Flow:** Explain how the frontend should handle authentication (guest mode, API key mode, cloud sync).
+3.  **Explain Streaming Architecture:** If the feature uses streaming, document the SSE or WebSocket connection and event handling.
+4.  **Provide Code Examples:** Include frontend code snippets for making API calls.
+5.  **Document Error Handling:** Specify how the frontend should handle different backend error codes.
+
+### Step 4: Track Prompt Enhancement
+
+**Goal:** Update all development prompts (e.g., for implementation agents like Zenflow or Claude Code) with backend grounding.
+
+1.  **Add a "Backend Grounding" Section:** In each prompt, add a dedicated section that explains the backend context.
+2.  **Document Specific Endpoints:** For each part of the implementation, specify the exact API endpoint to use.
+3.  **Reference the Integration Guide:** Link to the full integration guide for more details.
+4.  **Ensure Prompts Use Existing Patterns:** Explicitly instruct the development agent to follow existing backend patterns.
+
+### Step 5: Audit and Deliver
+
+**Goal:** Ensure all documentation is complete, consistent, and ready for commissioning.
+
+1.  **Run a Final Audit:** Review all documents for gaps, inconsistencies, or missing information.
+2.  **Write Missing Documentation:** If any gaps are found (e.g., design system, API contracts), write the missing documents.
+3.  **Push to Repository:** Commit all documentation to a dedicated directory (e.g., `docs/vX.X.X/`).
+4.  **Confirm Readiness:** Announce that the specifications are complete and ready for commissioning.
+
+---
+
+## IV. Best Practices
+
+-   **No Backend Changes is the Goal:** The primary goal of this process is to build a frontend that works with the *existing* backend. Only propose backend changes as a last resort.
+-   **The Backend is the Source of Truth:** If there is a discrepancy between the frontend design and the backend API, the backend API is correct. The frontend design must adapt.
+-   **Over-Document the Integration:** It is better to provide too much detail on how the frontend and backend should connect than too little.
+-   **Use this Skill Before Writing Code:** This process should be completed *before* any significant frontend development begins.
+
+---
+
+## V. Quality Checklist
+
+Before commissioning the work, ensure you can answer "yes" to all of the following questions:
+
+-   [ ] Have you read the main entrypoint of the backend application?
+-   [ ] Have you read the handlers for all relevant API endpoints?
+-   [ ] Have you written a comprehensive feature specification that includes API contracts?
+-   [ ] Have you created a backend integration guide with code examples?
+-   [ ] Have all development prompts been updated with a "Backend Grounding" section?
+-   [ ] Have you audited all documentation for completeness and pushed it to the repository?
+---
+
+## 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
+

package/skills/frontend-from-backend/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-frontend-from-backend",
+  "version": "1.0.0",
+  "description": "Write frontend specs from backend architecture",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "workflow", "process"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}

package/skills/handoff-protocol/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: handoff-protocol
+description: 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'.
+---
+
+> **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
+
+```markdown
+# 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
+

package/skills/handoff-protocol/claw.json

@@ -0,0 +1,12 @@
+{
+  "name": "dojo-genesis-plugin-handoff-protocol",
+  "version": "1.0.0",
+  "description": "Hand off work between agents cleanly",
+  "author": "dojo-genesis",
+  "license": "MIT",
+  "permissions": [],
+  "entry": "SKILL.md",
+  "tags": ["dojo-genesis", "orchestration", "agents", "coordination"],
+  "models": ["claude-*", "gpt-*", "gemini-*"],
+  "minOpenClawVersion": "2026.1.0"
+}