What makes Agent Collaboration Protocol notable?

1.1K downloads. Trust evidence available

How should Agent Collaboration Protocol be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

Agent Collaboration Protocol

Structured multi-agent collaboration for backend + frontend builds. Use when an orchestrator needs to coordinate a backend engineer and frontend engineer on... Skill: Agent Collaboration Protocol Owner: nightknight64 Summary: Structured multi-agent collaboration for backend + frontend builds. Use when an orchestrator needs to coordinate a backend engineer and frontend engineer on... Tags: latest:1.5.3 Version history: v1.5.3 | 2026-05-09T16:25:35.138Z | user Security hardening: replaced all sudo systemctl commands with platform-agnostic service restart guidance. Fixed flawe

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.1k

Updated

Oct 11, 2026

Version

1.5.3

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.1K downloadsadoption · observed Oct 11, 2026
Latest release: 1.5.3release · observed May 9, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s1734cre4m4d0p2p7txrgyn9298636t0:agent-collaboration-protocol

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-nightknight64-agent-collaboration-protocol/snapshot"

Documentation

CLAWHUB

147,492 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: agent-collaboration-protocol
description: Structured multi-agent collaboration for backend + frontend builds. Use when an orchestrator needs to coordinate a backend engineer and frontend engineer on the same feature. Triggered by multi-role build requests like "build a dashboard with an API and UI" or "create a full-stack feature" or any task requiring both backend (API, data, infra) and frontend (UI, templates, design) work.
---

# Agent Collaboration Protocol

## How It Works

Three roles collaborate through a shared workspace:

| Role | Responsibility |
|------|---------------|
| **Orchestrator** | Defines the contract, spawns both builders, verifies integration, merges |
| **Backend Engineer** | Writes API code, data models, infrastructure |
| **Frontend Engineer** | Writes UI components, templates, styles |

The contract lives in a `shared/build-{YYYYMMDD}/` directory on the filesystem. **The orchestrator MUST provide the full absolute path** (e.g. `/home/user/project/shared/build-{YYYYMMDD}/`) in all handoff messages — isolated subagent sessions do not resolve relative paths reliably. Both builders write to the same directory. The orchestrator inspects and merges when both are done.

## Workflow

### Step 1: Orchestrator Creates the Build Directory and Contract

```
shared/build-{YYYYMMDD}/
  SPEC.md           ← Integration contract (orchestrator writes)
  backend/          ← Backend Engineer writes here
  frontend/         ← Frontend Engineer writes here
  backend-log.md    ← Backend Engineer updates (own file, no conflicts)
  frontend-log.md   ← Frontend Engineer updates (own file, no conflicts)
  integration.md    ← Orchestrator merges findings here
```

Write `SPEC.md` with these sections:

```markdown
# SPEC: {Feature Name}

## Contract
- API base path, auth scheme, content type
- Data models (all entities, fields, types, relationships)
- Endpoints (method, path, request/response shapes)
- Shared constants (status enums, error codes, feature flags)
- Error format

## Routes
Backend Engineer implements these. Frontend Engineer consumes them.

## UI Components
Frontend Engineer builds these. Backend Engineer doesn't touch them.

## Shared Constants
Both agents use these. Status enums, error codes, UI state labels.

## Success Criteria
Observable behavior. Not "tests pass" — "user can log in and see calendar."
```

For the full spec template with examples, see `references/spec-template.md`.

### Step 2: Orchestrator Spawns Agents

Spawn two subagents with `sessions_spawn`:

**Backend Engineer:**
```
task: >
  Implement the API spec at {ABSOLUTE_BUILD_DIR}/SPEC.md.
  Write all backend code to {ABSOLUTE_BUILD_DIR}/backend/.
  Log your progress to {ABSOLUTE_BUILD_DIR}/backend-log.md.
  FIRST: Reply "ACK — confirmed build directory: {ABSOLUTE_BUILD_DIR}" before starting any work.
  IMPORTANT: Use the full absolute path for ALL file writes. Verify files exist after writing.
  Use {backend framework} (FastAPI, Express, etc.).
```

**F

_meta.json

{
  "ownerId": "kn7b9ca8tx0e2ktzzdd8c94cfh863xmn",
  "slug": "agent-collaboration-protocol",
  "version": "1.5.3",
  "publishedAt": 1778343935138
}

references/handoff-format.md

# Handoff Message Format

Use this template when spawning or messaging agents. Include ALL fields.

```
## Handoff: {Title}

**What:** {Specific task or deliverable — one sentence}

**Why:** {Context and priority — why this is needed now}

**Files:**
- `shared/build-{YYYYMMDD}/backend/router.py` — route handler
- `shared/build-{YYYYMMDD}/SPEC.md` — API contract

**Success criteria:** {Observable behavior — how we know it's done}

**ETA:** {YYYY-MM-DD HH:MM UTC}
```

## Monitoring

Adapt monitoring to your setup. Suggested pattern:

1. Check shortly after handoff: Did the agent start? Files modified?
2. Check near ETA: Progress? Blockers?
3. If no progress by ETA: re-spawn or escalate

Adjust frequency and method based on your agent architecture and tooling.

references/integration-log.md

# Integration Log — `shared/build-{YYYYMMDD}/integration.md`

## Format

```markdown
# Build: {Feature Name} — {Date}

## Status
Orchestrator: ⏳ Waiting / 🔍 Reviewing / ✅ Complete
Backend: 🔨 Building / ✅ Done / ❌ Blocked
Frontend: 🔨 Building / ✅ Done / ❌ Blocked

## Backend Progress
- [ ] Router implemented at `backend/router.py`
- [ ] Models defined at `backend/models.py`
- [ ] Endpoints responding correctly
- [ ] Shared constants match spec

### Blockers
- ...

## Frontend Progress
- [ ] Components built in `frontend/components/`
- [ ] API client wired to endpoints
- [ ] All states handled (loading, empty, error, populated)
- [ ] Shared constants match spec

### Blockers
- ...

## Integration Notes
- Data format mismatch found: endpoint returns `items`, UI expects `data`
- Auth tokens not flowing through — need session cookie handling
```

## Per-Agent Log Format (avoids conflicts)

When both agents write to `integration.md` simultaneously, use separate log sections:

```markdown
# Build: {Feature Name} — {Date}

## Status
Orchestrator: ⏳ Waiting
Backend: 🔨 Building
Frontend: 🔨 Building

## Backend Log
<!-- Only the backend agent edits this section -->
- 2024-01-15 10:00: Started router implementation
- 2024-01-15 10:30: GET /api/v1/items endpoint complete
- 2024-01-15 11:00: BLOCKER: Need auth middleware from infra team

## Frontend Log
<!-- Only the frontend agent edits this section -->
- 2024-01-15 10:15: Started ItemList component
- 2024-01-15 10:45: Mock data wired, awaiting backend endpoint
- 2024-01-15 11:10: Switched to using spec contract for API client

## Integration Issues
<!-- Orchestrator edits this section -->
- (none yet)
```

references/spec-template.md

# SPEC: {Feature Name}

> Generated by Agent Collaboration Protocol

## Overview

One sentence. What this feature does and why it matters.

## Contract

| Field | Value |
|-------|-------|
| API Base Path | `http://localhost:8000/api/v1` |
| Auth Scheme | Bearer JWT / Session cookie / None |
| Content Type | `application/json` |
| Error Format | `{ "error": "...", "detail": { ... } }` |

## Data Models

### {Entity Name}
| Field | Type | Required | Notes |
|-------|------|----------|-------|
| id | string | yes | UUID |
| name | string | yes | Display name |
| status | string | yes | See Shared Constants |

### {Entity Name 2}
...

## Shared Constants

Both backend and frontend must use the same values for these:

### Status Enums
| Constant | Values | Used By |
|----------|--------|---------|
| `{Entity}Status` | `active`, `inactive`, `pending` | Backend enum + frontend labels |
| `ErrorCode` | `NOT_FOUND`, `UNAUTHORIZED`, `VALIDATION_ERROR` | Backend error responses + frontend error messages |

### Feature Flags
| Flag | Default | Description |
|------|---------|-------------|
| `ENABLE_{FEATURE}` | `false` | Controls {feature} visibility |

## Endpoints

### `GET /api/v1/{resource}`
**Response:**
```json
{
  "data": [ ... ],
  "total": 42,
  "page": 1
}
```

### `POST /api/v1/{resource}`
**Request:**
```json
{
  "field": "value"
}
```
**Response:** `201 Created` with body containing the created entity

### Error Response (all endpoints)
```json
{
  "error": "VALIDATION_ERROR",
  "detail": {
    "field": "email",
    "message": "Invalid email format"
  }
}
```

## UI Components

### {Component Name}
- Purpose: One sentence
- Data source: `GET /api/v1/{resource}`
- States: loading, empty, error, populated
- Interactions: click to select, pull to refresh

## File Structure

### Backend
```
backend/
  router.py        ← Route handlers
  models.py        ← Data models/schemas
  service.py       ← Business logic
```

### Frontend
```
frontend/
  components/      ← UI components
  templates/       ← Page templates
  styles/          ← Styles
  api.js           ← API client
```

## Edge Cases

- Empty state: What shows when no data exists?
- Error state: What shows on API failure?
- Loading state: What shows while data fetches?
- Offline: Does it degrade gracefully?

## Verification Checklist

### Backend
- [ ] Each endpoint returns correct status codes (200, 201, 400, 404, 500)
- [ ] Error responses match the shared error format
- [ ] Status enums match the Shared Constants section
- [ ] Auth scheme matches the Contract section

### Frontend
- [ ] Loading state renders (spinner/skeleton)
- [ ] Empty state renders (no data message)
- [ ] Error state renders (actionable error message)
- [ ] Populated state renders with real data
- [ ] All user interactions work (click, submit, navigate)

### Integration
- [ ] Frontend fetch calls match backend endpoint paths
- [ ] Request/response shapes match the spec
- [ ] Shared constants are consistent between fron

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.