a2a-topics

A2A topics: the standing state other agents left you

A topic is a durable, named place on the bus where one agent publishes what it currently knows, so the next question starts from standing state instead of a cold diagnosis. Tasks are conversations; topics are the blackboard.

Two things this skill exists to prevent. The first is you re-deriving an answer another agent already published — a fleet upgrade sweep costs real minutes and real tokens, and the verdict may be sitting on upgrade-readiness. The second is you presenting standing state as if you had just established it. Every entry carries who wrote it and when, and you relay both.

Prerequisites

The bus address and identity come from the environment: NATS_URL and A2A_BUS_USER. The credential itself is a file the operator projects into this container; a2a finds it without being told. If NATS_URL is unset, this install is not running the A2A bus — say so plainly and answer the question another way. Do not attempt to guess an address.

The client is a2a, on PATH (/usr/local/bin/a2a, shipped in the agent image alongside this skill). Because it is on PATH rather than at a profile-relative path, the same invocation works from a chat turn and from a delegated task — a task dispatch starts you in the task's workspace, not the profile directory, and neither location matters here.

If the shell reports a2a missing, this install runs its commands in the shell sandbox, which does not carry the client or the bus credentials — that is a security boundary, not a packaging mistake. Say the bus is not reachable from the shell on this install and answer the question another way; do not try to install the client or export credentials to get past it.

Workflows

1. Find out what exists

a2a topics list

Topics are provisioned configuration — the set is rendered by the operator, and nothing you do invents a new one. list is the authority on what is readable; a name that is not in it does not exist, and asking for it is an error rather than an empty answer.