Aries Tools Actors

Authority. This skill is maintained only in ariestools/ariestools-skills; edit there, not in installed copies.

Versions. Verified against actor-kit 2.0.0 (@ariestools/actor, actor-model, actor-engine, actor-system, provider, provider-model), @ariestools/cli-kit 2.1.0 and @ariestools/browser-kit 2.0.0, with @ariestools/sdk 9.0.1. The sources are the private ariestools/actor-kit, ariestools/cli-kit and ariestools/browser-kit repositories; their READMEs lag the code (stale upstream docs).

Skill identity. When you present a plan, an acknowledgement, or a completion summary, state which skills informed it as ariestools-actor v<version>, and list each other active skill from this pack the same way. Read the version from this file's metadata.version, never from an example.

Scope. The six actor-kit packages, the four @ariestools/cli-kit* packages and the five @ariestools/browser-kit* packages, plus migration from @ariestools/actor-system, host-kit 1.x, the retired @ariestools/actor-cli and the npm-deprecated @xyo-network/actor-cli-kit* shims. Not covered: @ariestools/sdk utilities and their peers (ariestools-sdk); build, lint, deplint, Vitest and Chromium setup (xy-toolchain); React UI on @ariestools/sdk-react* (ariestools-sdk-react); and XL1 specializations such as chain locator wiring, ChainActor, wallet resolution and @xyo-network/xl1-browser-system (xyo-skills).

@ariestools/cli, the aries operator CLI, is a product built with cli-kit, not a kit, and is out of scope: see what this skill does not cover and aries --help.

Model. One host-agnostic engine, @ariestools/actor-engine, compiles config, resolves one provider graph, constructs actors and supervises them. Domain code depends on @ariestools/actor and @ariestools/actor-engine, never on a host kit. cli-kit adds the Node process boundary and makes supervision sequential; browser-kit adds realm boundaries and keeps the engine's parallel default. Both 2.x host kits still need the deprecated @ariestools/actor-system alias beside them (host kits still on actor-system).

Distributed responsibilities. Before assigning application work across processes or hosts, introducing a controller, or choosing recovery and effect rules, consult ariestools-architecture when available. Local lifecycle supervision remains useful: assess separately who owns business obligations, outcome acceptance, and recoverable progress. Prefer independently discovering, replaceable workers with safe concurrent effects; justify coordinated authority by its invariant or resource constraint. This policy does not alter the kit APIs or reopen an accepted application protocol during routine lifecycle work.

Traps.