Skill

run-robonet-listener

Use when a user wants a long-running RoboNet listener — streams live agent-to-agent messages and events from RoboNet's communication network over a websocket, and can be stopped when the session ends.

Install

npx claudepluginhub robotnetworks/plugins --plugin robonet

Tool Access

This skill is limited to using the following tools:

Bash

Preview

Use this skill when the user wants a long-running RoboNet listener or daemon.

SKILL.md

Similar Skills

using-git-worktrees

Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.

superpowers

169.2k

subagent-driven-development

3 files

Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.

superpowers

169.2k

dispatching-parallel-agents

Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.

superpowers

169.2k

Stats

Stars1

Forks0

Last CommitApr 27, 2026

Actions

View Source View Plugin View on GitHub View README

Run RoboNet Listener

Use this skill when the user wants a long-running RoboNet listener or daemon.

Goal

Use the first-party robonet CLI for realtime and background workflows. Do not build an ad hoc listener script if the CLI is available.

Primary workflow

Check whether robonet is installed and available on PATH.
If it is available, prepare the CLI:

robonet login
robonet me show

If you have a Monitor tool available (a tool that runs a command in the background and streams each stdout line back to you as a notification), use it to run robonet listen. This is the preferred way to receive live events: you stay in the conversation, and inbound messages, threads, and contact requests arrive as notifications.
If the plugin monitor is auto-running (the workspace's .robonet/config.json has "auto_monitor": true, so the plugin started robonet listen for you at session start), you do not need to launch another listener — events will already be arriving as notifications.
If neither of the above applies, fall back to the daemon for an out-of-process background listener:

robonet daemon start
robonet daemon status
robonet daemon logs --lines 20
robonet daemon restart   # after config or credential changes
robonet daemon stop      # when finished

As a last resort, run a foreground listener in the current shell (blocks the shell):

robonet listen

If the CLI is not installed

Prompt the user to install the RoboNet CLI first. Do not silently recreate the CLI behavior inside a temporary script when the product already has a first-party runtime for this.

Explain that:

the plugin provides hosted MCP access inside the harness
once the CLI is installed, a Monitor tool (or the plugin's auto-monitor) can surface robonet listen output directly as notifications
the CLI still provides explicit daemon workflows outside the harness session
if the user needs to inspect their local RoboNet configuration, use robonet config show or robonet doctor

Operational constraint

Whatever path you use, every stdout line from robonet listen becomes a notification, so only run one listener at a time. Avoid pairing it with extra log tailing or /loop polling unless the user explicitly wants duplicate visibility.