ワンクリックでManusで任意のスキルを実行

aeon-fleet

スター13

フォーク3

更新日2026年6月17日 15:27

See every AEON Magick Orb on the network at once and pick which one to operate. Each Orb is a peer in a decentralized roster; one roster call returns every Orb's identity, what it controls, its capture sources, battery and health — so you choose the right Orb, then drive it directly with the core aeon-magick skill against that Orb's own endpoint. Load this only when there may be more than one Orb; for single-device work just set AEON_HOST and use the core skill.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

AEON-7

AEON-7/aeon-magick-ai-computer-control

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

関連職種SOC

SOC 職業分類に基づく

ソフトウェア開発者コンピュータ・数学職·SOC 15-1252

ファイルエクスプローラー

2 ファイル

SKILL.md

readonly

このリポジトリの他の Skills

同じリポジトリ

aeon-magick

AEON-7/aeon-magick-ai-computer-control

Drive a target host's keyboard, mouse, trackpad, AND screen capture through an AEON Magick AI Computer Control Orb on the LAN — and pick among several Orbs in a fleet. Each Orb's USB-C OTG port emulates a real USB keyboard + mouse (+ optional Apple multi-touch trackpad) on its target; the Orb does its OWN HID — it both sees AND acts, no external dongle. Vision comes from a switchable capture source (Cam Link USB, Pi-5 HDMI→CSI bridge, or a CSI camera), so an agent can flip between watching the controlled screen and looking at a physical thing. All ops are atomic HTTPS calls — there is no `key_down` / `key_up` split that can leave the target with a stuck key after a packet drop. Use to operate the USER'S OWN computers, accounts, and services.

2026-07-1913

aeon-bench

AEON-7/aeon-magick-ai-computer-control

Benchmark an open LLM on real hardware and submit an attested run to the AEON Bench leaderboard. Deploy the Aeon Bench Pod (pull → verify → serve → benchmark → sign → submit) onto a connected GPU server, watch it through its phases, and open its dashboard. Load this when the task is to EVALUATE / benchmark / leaderboard a model. The pod needs an NVIDIA GPU, so it deploys to a connected system, not the Orb itself.

2026-07-0713

aeon-update

AEON-7/aeon-magick-ai-computer-control

Keep an Aeon Orb current and secure — apply OS security patches, toggle automatic patching, and check whether a newer Orb IMAGE has been published. Load this when the task is to update / patch the Orb, check its version, or ask "is my Orb up to date?". Two distinct layers: OS packages (apt, live) and the whole image (re-flash from Patreon — the Orb never self-flashes).

2026-07-0513

aeon-model-share

AEON-7/aeon-magick-ai-computer-control

Find, import, and move AI models across the Intergalactic Model Share — a decentralized IPFS network every Orb joins at boot. List models shared by Orbs across the network, import one straight from HuggingFace / Ollama / Civitai (verified), pull it down to this Orb's library, and push it onto a connected GPU server to serve. Load this when the task is about GETTING A MODEL onto a machine; for benchmarking a model use aeon-bench, for driving a screen use the core aeon-magick skill.

2026-07-0513

aeon-cameras

AEON-7/aeon-magick-ai-computer-control

Choose what an AEON Magick Orb's eye is pointed at. An Orb can have several video inputs wired to it — a USB HDMI-capture stick, a Pi-5 HDMI→CSI bridge (watch the controlled machine's screen), and a Pi-5 CSI camera (look at a physical scene through a lens). This skill reads the available capture sources and switches the live source so the console snapshot/stream shows what you need. Pi-5-only sources (camera-csi, hdmi-csi) are gated by the Orb's model. Load this when you need to switch between "see the screen I control" and "see a physical thing"; for plain screen viewing use the core aeon-magick skill's vision reference.

2026-06-1713

aeon-power

AEON-7/aeon-magick-ai-computer-control

Check whether an AEON Magick Orb is on wall power or running on its battery backup (a Waveshare UPS HAT), and how much charge is left. Read-only. Load this before any long, unattended operation on an Orb so you know it won't power off mid-task and leave you blind. Returns {present:false} (not an error) on an Orb with no UPS. Per-Orb battery state is also summarized in the aeon-fleet roster, so for many Orbs read the roster instead of polling each.

2026-06-1713

name

aeon-fleet

description

aeon-fleet

Each Orb is a self-contained see+act device on its own HTTPS endpoint. The fleet layer makes an Orb a peer in a decentralized roster so one agent can discover every Orb, read its state, and decide which to drive — then talk directly to that Orb's https://<addr>/api/* for input and vision (the core aeon-magick skill). There's no central controller: the roster is each Orb's view of the swarm, polled directly over the tailnet/LAN.

Credentials. Auth = Authorization: Bearer $AEON_TOKEN against https://$AEON_HOST (self-signed → curl -k). The token is never in this skill — export AEON_TOKEN=<your token> (e.g. from your password manager) or load ~/.openclaw/aeon-magick.env (set -a; . ~/.openclaw/aeon-magick.env; set +a). A 401 means the token is unset/wrong — fix that, don't switch tools.

The roster GET is Read-tier.

roster — the whole fleet in one call

curl -sk -H "Authorization: Bearer $AEON_TOKEN" \
    "https://$AEON_HOST/api/fleet/roster"

{
  "configured": true,
  "self": {
    "id": "orb-a1b2c3", "hostname": "aeon-orb-1", "label": "Pi5 CSI rig",
    "model": "pi5", "lan_ip": "192.168.1.25",
    "addrs": ["192.168.1.25", "100.92.x.y"], "is_self": true, "online": true,
    "sources": ["camera-csi", "hdmi-csi"], "view_source": "hdmi-csi",
    "webcam": {"enabled": false, "source": "off"},
    "ups": {"present": true, "charge": 96, "on_battery": false},
    "health": {"cpu_temp_c": 47, "uptime_seconds": 8123}, "version": "0.1.0",
    "seeds": ["192.168.1.56"]
  },
  "peers": [
    {
      "id": "orb-d4e5f6", "hostname": "aeon-orb-2", "label": "Pi4 Cam Link",
      "model": "pi4", "addr": "192.168.1.56", "online": true,
      "sources": ["cam-link-usb"], "view_source": "cam-link-usb",
      "webcam": {"enabled": false, "source": "off"},
      "ups": {"present": false}, "health": {"cpu_temp_c": 51}, "version": "0.1.0"
    }
  ]
}

configured: false means fleet peering was never set up — you have a lone Orb; just operate $AEON_HOST directly and ignore the rest.

The peers set is static seeds ∪ tailnet-discovered IPs (when tailscale is on), minus this Orb's own addresses. Each peer is fetched concurrently with a 3 s timeout, so a down or slow peer comes back as an online: false stub rather than blocking the roster — one unreachable Orb never stalls the call.

picking an Orb

Each entry is everything you need to choose without touching the device:

Field	What it tells you
`label`	what this Orb controls — the thing you're really selecting on. Match the user's intent against this first.
`model`	`pi5` / `pi4` — gates which capture `sources` exist (Pi 5 adds CSI camera + HDMI-CSI; see `aeon-cameras`)
`addr` / `lan_ip` / `addrs`	the Orb's address(es) — target this directly for input/vision. `addrs` lists every address it answers on (LAN + tailnet); `lan_ip`/`addr` is just the first. Use whichever is reachable from where you're dispatching.
`online`	reachable on the last heartbeat. Don't dispatch to an offline Orb. (`self` is implicitly online.)
`sources` / `view_source`	available sources, and what the console is watching right now
`webcam`	what it's exposing to its target as a UVC webcam (see `aeon-webcam`)
`ups`	battery state — warn/skip on `on_battery: true` / low `charge` (see `aeon-power`)
`seeds` (on `self`)	this Orb's configured peer list — the swarm it expects, without a separate `/config` call
`health` / `version`	quick triage + capability sanity

Flow: roster → filter online (+ healthy) → match label (and model if you need Pi-5-only sources) → take that peer's addr → from there it's an ordinary single-Orb session against https://<addr>/api/* with the core skill. Each Orb authenticates independently — use that Orb's own token (the config can hold per-Orb tokens; see the master env), not necessarily $AEON_HOST's.

the two current Orbs

addr	model	label	capture
`192.168.1.25`	`pi5`	Pi5 CSI rig	`camera-csi` (Sony IMX477 HQ) + `hdmi-csi` (Geekworm X1301)
`192.168.1.56`	`pi4`	Pi4 Cam Link	`cam-link-usb` (Elgato Cam Link 4K)

Each is configured on its own — the .25 Pi 5 flips between the screen it controls (hdmi-csi) and a physical camera (camera-csi); the .56 Pi 4 has the single USB capture path. The fleet doesn't unify them; it lets you see and reach both from one roster call.

what's operator-only

GET /api/fleet/status is the internal peer-to-peer heartbeat (gated by an X-Fleet-Token, bypasses user auth on purpose). You use /roster — that's the heartbeat data already assembled. Only reach for status when debugging why a peer shows online: false.
GET/PUT /api/fleet/config manages peering — the seed list, the tailscale tailnet auto-discovery toggle, and the shared token. With tailscale: true the roster also pulls in peers discovered over the tailnet, so an Orb can show up with no seed entry at all. PUT accepts label, seeds, and tailscale; it never reads or writes the token. That's human setup, not an agent surface.
No MCP tool for the fleet — roster/status/config are REST-only.