Pilot Swarm Config

Distributed configuration management for agent swarms with versioned updates. Use this skill when: 1. Multiple agents need to share configuration settings 2....

Security Scan

The skill's runtime instructions match a distributed config manager, but the SKILL.md references environment variables, tools, and a dependent skill that are not declared in the registry metadata — this mismatch is suspicious and should be clarified before trusting it with production agents.

Purpose & Capability

The name and description align with the instructions: publish/subscribe via pilotctl to manage versioned configuration and rollbacks. However the SKILL.md also requires the 'pilot-protocol' skill and 'jq' (for JSON parsing) in addition to pilotctl; the registry metadata only declared pilotctl. That undocumented dependency and the use of named registry host and swarm variables are unexplained.

Instruction Scope

Instructions are narrowly focused on publishing, subscribing, applying, validating, and rolling back configs using pilotctl and jq; they read/write /tmp/swarm-config.json and a version file, and publish compliance messages back to the registry. These actions are within the stated purpose, but the document assumes environment variables (SWARM_NAME, AGENT_ID, REGISTRY_HOST) and a running daemon without declaring them, which grants the skill implicit access to network endpoints and agent identity.

Install Mechanism

There is no install spec and no code files — the skill is instruction-only, which minimizes on-disk execution risk. It does assume external binaries (pilotctl, jq) are present on PATH and a daemon is running.

Credentials

Registry metadata declares no required environment variables or credentials, but the SKILL.md expects SWARM_NAME, AGENT_ID, REGISTRY_HOST and implies pilotctl authentication/state (the daemon and registry host). The skill can publish messages to a networked registry and report agent IDs and applied versions; lacking declared credential requirements or details about how pilotctl authenticates is a proportionality and transparency concern.

Persistence & Privilege

The skill does not request 'always: true' or modify other skills. It's agent-invocable and can run autonomously (the platform default), which is expected for an operational skill. No installation steps or self-elevating privileges are present.

Scan Findings in Context

[no-findings] expected: The scanner found no code to analyze; this is an instruction-only skill (SKILL.md). Lack of code files explains the absence of regex findings but does not guarantee safety.

What to consider before installing

This skill appears to do what it says (distributed, versioned config via pilotctl) but the SKILL.md assumes variables and dependencies that are not declared in the registry metadata. Before installing: (1) Verify pilotctl and jq are trusted binaries on the host and confirm how pilotctl authenticates to the registry (credentials may be stored outside the skill). (2) Confirm what values will be used for SWARM_NAME, AGENT_ID, and REGISTRY_HOST and whether those identifiers expose sensitive mapping between agents and identities. (3) Test in an isolated environment to observe what the skill publishes to the registry and whether the registry endpoint is trusted. (4) Ask the publisher to update metadata to declare required env vars (SWARM_NAME, AGENT_ID, REGISTRY_HOST), the pilot-protocol dependency, and any authentication needs. If you cannot confirm those details, avoid granting this skill autonomous invocation on production agents.

Manage shared configuration across agent swarms with versioning, atomic updates, and rollback support.

Essential Commands

Publish configuration update

CONFIG_VERSION=$(date +%s)
CONFIG_DATA='{"max_workers":10,"timeout_ms":5000,"log_level":"info"}'

pilotctl --json publish "registry-hostname" "config:$SWARM_NAME" \
  --data "{\"type\":\"config_update\",\"version\":$CONFIG_VERSION,\"config\":$CONFIG_DATA}"

Subscribe to configuration updates

pilotctl --json subscribe "registry-hostname" "config:$SWARM_NAME"

Apply configuration locally

LATEST_CONFIG=$(pilotctl --json inbox \
  | jq '[.messages[] | select(.topic == "config:'$SWARM_NAME'" and .payload.type == "config_update")] | sort_by(.payload.version) | last')

CONFIG_VERSION=$(echo "$LATEST_CONFIG" | jq -r '.payload.version')
CONFIG_DATA=$(echo "$LATEST_CONFIG" | jq -r '.payload.config')

echo "$CONFIG_DATA" > /tmp/swarm-config.json
echo "$CONFIG_VERSION" > /tmp/swarm-config-version.txt

Validate configuration

# Basic validation
VALID=$(echo "$CONFIG_DATA" | jq 'has("max_workers") and has("timeout_ms")')

if [ "$VALID" = "true" ]; then
  echo "Config validation passed"
else
  echo "Config validation FAILED"
  exit 1
fi

Rollback to previous version

CURRENT_VERSION=$(cat /tmp/swarm-config-version.txt)
PREVIOUS_CONFIG=$(pilotctl --json inbox \
  | jq '[.messages[] | select(.topic == "config:'$SWARM_NAME'" and .payload.type == "config_update" and .payload.version < '$CURRENT_VERSION')] | sort_by(.payload.version) | last')

PREV_VERSION=$(echo "$PREVIOUS_CONFIG" | jq -r '.payload.version')
PREV_DATA=$(echo "$PREVIOUS_CONFIG" | jq -r '.payload.config')

echo "$PREV_DATA" > /tmp/swarm-config.json
echo "$PREV_VERSION" > /tmp/swarm-config-version.txt

Track compliance

# Agents report applied version
pilotctl --json publish "registry-hostname" "config:status:$SWARM_NAME" \
  --data "{\"agent\":\"$AGENT_ID\",\"applied_version\":$CONFIG_VERSION}"

# Coordinator checks compliance
COMPLIANCE=$(pilotctl --json inbox \
  | jq '[.messages[] | select(.topic == "config:status:'$SWARM_NAME'")] | group_by(.payload.applied_version) | map({version: .[0].payload.applied_version, count: length})')

Workflow Example

Agent config subscriber:

#!/bin/bash
set -e

SWARM_NAME="worker-pool"
CONFIG_CHANNEL="config:$SWARM_NAME"
STATUS_CHANNEL="config:status:$SWARM_NAME"
REGISTRY_HOST="registry.example.com"

pilotctl --json subscribe "$REGISTRY_HOST" "$CONFIG_CHANNEL"

CURRENT_VERSION=0
[ -f /tmp/swarm-config-version.txt ] && CURRENT_VERSION=$(cat /tmp/swarm-config-version.txt)

while true; do
  LATEST=$(pilotctl --json inbox \
    | jq '[.messages[] | select(.topic == "'$CONFIG_CHANNEL'" and .payload.type == "config_update")] | sort_by(.payload.version) | last')

  if [ -n "$LATEST" ] && [ "$LATEST" != "null" ]; then
    LATEST_VERSION=$(echo "$LATEST" | jq -r '.payload.version')

    if [ "$LATEST_VERSION" -gt "$CURRENT_VERSION" ]; then
      echo "Applying config version $LATEST_VERSION"
      CONFIG_DATA=$(echo "$LATEST" | jq -r '.payload.config')

      echo "$CONFIG_DATA" > /tmp/swarm-config.json
      echo "$LATEST_VERSION" > /tmp/swarm-config-version.txt

      # Report compliance
      pilotctl --json publish "$REGISTRY_HOST" "$STATUS_CHANNEL" \
        --data "{\"agent\":\"$AGENT_ID\",\"applied_version\":$LATEST_VERSION}"

      CURRENT_VERSION=$LATEST_VERSION
    fi
  fi
  sleep 5
done

Dependencies

Requires pilot-protocol skill, pilotctl binary, running daemon, and jq for JSON parsing.