AI Agent Hub
Back to skills
🤖

Multi-Agent Collaborative Inspection Legion

AI Agent Updated 2026.08.30

Paste the following prompt into your AI chat to install this skill:

Please install @user_f12a44b7/cnbll-clawhong-skill-openclaw-multi-agent following https://skillhub.cn/install/skillhub.md.

About this skill

Problem

Multiple OpenClaw instances can run independently, but coordinating task dispatch, status reporting, fault recovery, and permission governance quickly becomes scattered across messages, scripts, and cron jobs. Shell-based polling can fail when scripts are stored in /tmp, time out during sleep, or disappear without alerting. Admin inboxes can be buried under heartbeats, chat, and task replies, while stalled tasks lack a stable reassignment path.

How It Works

The skill splits multi-agent coordination into three layers:
- Communication layer: The memory-store CloudBase event function stores messages, sessions, and inbox tasks. Admins dispatch work through /inbox/send, and workers report processing, done, or other states via PATCH /inbox/:id.
- Data layer: The crud-api function holds structured data such as workflows, skill registries, and task records, which need queries, indexes, and state transitions rather than inbox-style storage.
- Governance layer: Native cron handles polling instead of fragile shell loops, while intelligent dispatch, workflow execution, fault self-healing, three-bucket message routing, and L0-L3 visitor authentication complete the control plane.
Typical setup starts with worker check-in, an onboarding pack, cron configuration, verification, employee ID and alias registration, and a test task. At runtime, the system can select workers using SKILL_REGISTRY and keyword mappings, reassign or escalate timed-out tasks, and let a vice-president role manage inbox cleanup, CNB issues/PRs, and dashboard monitoring.

Boundaries

The setup assumes CloudBase, Node.js 18+, and OpenClaw instances are already available, and that an admin can deploy event functions. Worker permissions should stay scoped to their own inbox; SSH, infrastructure changes, and plaintext secrets should not be delegated to workers. Long-term use requires messages cleanup, cron deduplication, CNB credential configuration, and consistent alias synchronization across frontend, backend, and monitoring.

Use Cases

  • Admins need to assign a batch of issues to different OpenClaw workers and track `pending`, `processing`, and `done` states.
  • Multiple OpenClaw instances need shared inbox, group chat, and visitor authentication to keep tasks and discussions organized.
  • Timed-out tasks need rule-based reassignment to the next-best worker, with a 30-minute deduplication window to avoid alert storms.
  • New OpenClaw workers need check-in, `cron` polling setup, a test task, and employee ID plus alias registration.

Best For

  • Agent platform engineers managing multiple OpenClaw instances who want to avoid maintaining separate polling scripts per worker.
  • Admins responsible for task scheduling who need unified dispatch, inbox review, and status auditing.
  • Ops developers deploying CloudBase event functions and a dashboard who need inbox, `crud-api`, and monitoring to work together.
  • Repository maintainers handling CNB issues, PRs, and heartbeat monitoring who want worker output in review and merge workflows.