An agent answering "what is a commander, how do I start one" had nothing to answer from. skills/load.ts already compiles an index of name + when-to-reach-for-it + path into every session, with the body read on demand — so this needed skills written, not a mechanism built. There was one skill before these; now three. skills/platform/SKILL.md is GENERATED by the platform repository's `bun run skills:platform`, and its `docs:check` fails if it drifts. Do not edit it here — an edit is lost on the next run, and the generator carries the prose for exactly that reason. skills/commander/SKILL.md is written by hand, because none of it is derivable. What is in it is what three days of running one taught, including the parts that surprised us: - A commander is an ordinary chat session in a particular directory. Not a special agent — a conversation plus a loop somebody started from inside it. - Three pieces, and people get the third wrong: the conversation, the shell loop that waits, and the HEADLESS AGENT the loop spawns when it fires. They expect the commander itself to wake up. It does not. - Its cost line understates, structurally: only turns crossing the platform's chat socket are recorded, and a spawned agent's never do. A commander that spent dollars through children can display cents. - A spawned agent cannot be linked to its parent after the fact. The entry types that look like they mark one are the harness's own and appear in both. If the link matters, the loop must record the id itself. - Poll a local address, never a public hostname behind a reverse proxy — rate limiting there reads as an access-rights error and is not one. - The platform may not know a watcher exists: its bookkeeping engages only for the hand-back-and-re-arm fire behaviour, so a working loop can sit beside a row that says unarmed. The largest section is about helping somebody SHAPE one, since that is the part that is a conversation rather than a form. Four questions, and the third is the one nobody volunteers: what must never happen twice. A trigger that stays true after a failed action fires again, and again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer capabilities
The file-based store Officer reads agent items from. This repository holds the ones the platform ships; everything else in this directory is yours.
affordances/officer/core/ ← shipped here
skills/ tools/ tasks/ processes/ extensions/ agents/
Those six directories are created by the platform at boot and are where you and your agents author
items. They are deliberately not tracked here — your work is not ours to version. extensions/tool-loader
is written by the platform from its own source and will reappear if you delete it.
Affordances
An affordance is what the surface on the other end of the conversation offers the agent: what the client will render, accept or ignore. Not what the agent can do — what it will get away with.
The platform compiles every affordance into one block and appends it to each agent session, so an agent
knows things it could not otherwise discover from the filesystem. plugins/CLAUDE.md in the platform is
the authority on the format and on what belongs in one.
Layout is <publisher>/<plugin>/, with core in the plugin slot for the platform's own. A plugin ships
its own affordances/ directory and installing it copies them in.
Updating
git pull, or press Update all on the platform's marketplace screen, which updates this alongside
every installed plugin.
Your own untracked items are unaffected by either.