pastilhasandClaude Opus 5
57eaf603a0
Two gaps found by testing the actual goal — "I say watch master for a new tag, and it works without me listing the caveats" — rather than by rereading what was written. THE BASELINE. The commander skill had "what must never happen twice", which is a CLAIM: do not act twice on the same item. The owner's constraint is different and was missing entirely: do not act on items that already existed when you were armed. "Watch for a new tag" is not a condition — a watcher armed today sees every historical tag and, unless something says otherwise, treats all of them as news and acts on each in turn. Nobody says "ignore the ones already there" because to a person it is obviously implied. It is not implied to a shell loop. So the skill now names the two honest kinds of baseline — a record of what has been handled, which survives a restart, or a snapshot taken at arming, which does not — and requires the loop to say which it is using. On this machine the lock files made the omission harmless. On a fresh one, a new commander would have deployed every tag in the history, one at a time. FINDABILITY. The deploy procedure was reachable only through a sentence at the end of the commander skill, so an agent asked to deploy would have to open one skill and read to its last line to learn the other existed. It has a description of its own now, which is the entire interface: the agent sees only that before deciding to open anything. The new skill does NOT copy the procedure. It names `scripts/deploy-claim.sh`, `docs/servers.md` and the plan format, which live with the code and change with it — a second copy would be right the day it was written and wrong the day somebody edits the first, and the copy an agent happened to read would be the stale one. One hop costs a Read; a wrong procedure costs a fleet. What it does carry is the fleet-specific part that would not belong in a procedure: poll a local remote and why (a tag pushed at 21:47 noticed at 23:07 through the public one, twenty seconds through the local), pm_cwd rather than a hard-coded path, the per-host login, plugins:update restarting sidecars on its own, and that a skipped host is either behind or current — different things, and only one of them asks the owner for anything. 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.