Should Collie discover your agent's commands automatically?

[AltanS]

The Agent-commands palette is a curated catalog per harness, plus whatever you put in
commands.toml (0.31.0). Neither knows about the skills, prompts and plugin commands you actually
have installed. #116 asked for that missing half.

I looked into generating the rows automatically. Here is what I found, per harness, before deciding
whether to build it. Short version: it works well for pi, and there is no good route for Claude
Code today.

pi

pi has an RPC mode that lists its own commands. One call, no session written:

echo '{"id":"1","type":"get_commands"}' | pi --mode rpc --no-session

That returns JSON in about a second: extensions, prompts and skills, each with a description.
Skills are named skill:<name>, which is exactly what pi's autocomplete accepts (I checked in a
live pane). Because it is pi's own resolution, it cannot drift from what pi will take.

Two things any implementation would have to respect:

• pi gates project skills behind its own per-directory trust decision. In an untrusted directory
  the project's skills are just absent: no prompt, no hang, a shorter list. pi has an --approve
  flag that forces trust on, and Collie must never pass it. That would grant project trust from a
  phone for a directory you may never have opened, and the gate is what stops a hostile repo from
  loading project extensions. Inheriting your own stored decision is the only sane option.
• Descriptions are the whole SKILL.md description field, sometimes a kilobyte. A phone palette
  needs one line, so they would be trimmed server side.

Claude Code

Claude knows its own inventory but only reports it in the init event of a headless run:

claude -p "..." --output-format stream-json --verbose

That carries slash_commands, skills, agents and plugins. Accurate, but it costs three
things:

• It needs a real prompt, so it spends an API turn. I held stdin open both plainly and in SDK mode;
  init never arrives until a message is sent, and this build has no --max-turns.
• It runs your hooks. Hook events fire first, so opening a palette would trigger project hooks.
• Names only, no descriptions.

The obvious workaround is to read the inventory out of the session log, since that turn is already
paid for. That does not work either. I searched every session log on my machine and found zero
occurrences of slash_commands and zero of "subtype":"init". The log records the conversation,
not the session's capabilities.

So I tried rebuilding the list from disk: user skills, user commands, and each enabled plugin's
commands/ and skills/ directories, with enablement read from settings.json. Against the real
101-entry list that gave 66 right, 48 missing, 13 wrong. Most of the missing ones are built-ins
the shipped catalog already covers, plus skills bundled inside the Claude package that live in no
user directory (/dataviz, /deep-research, /run). The 13 wrong ones are plugin commands that
exist on disk but are not live.

Wrong in both directions rules it out, because tapping a row types it into a live terminal. A
source with false positives is not worth having.

Claude would need something upstream: an inventory you can request without spending a turn or
firing hooks, ideally with descriptions.

codex, opencode, omp

Four harnesses, four transports. pi speaks a one-shot JSON line over stdin, codex has an
app-server (JSON-RPC or a socket), opencode runs a local HTTP server, and omp has nothing
enumerable at all. So this cannot be one mechanism. It would be a per-harness adapter, the same
shape as Collie's journal adapters.

What it would cost

Roughly a bridge/commands/ registry mirroring bridge/journal/, a per-pane endpoint fetched when
you open the palette (not on the poll tick), and a merge rule. A MINOR release for pi alone.

The part worth agreeing on first: the bridge would gain its first subprocess. Today it only reads
files. My inclination is to keep it opt-in and make the config key the absolute path, something like
COLLIE_PI_BIN=/abs/path/to/pi, so Collie only ever runs the one file you wrote down and never
something it found on PATH. There is a practical reason too: the service runs under
systemd --user with a minimal environment, so a pi installed via nvm is not on that PATH
anyway.

commands.toml would stay either way. Discovery can only echo commands the harness already has. It
cannot author a /model sonnet preset, a canned prompt, or any row at all for a harness with
nothing to enumerate.

Questions

1. Would you use this, and for which harness?
2. Is an opt-in key you have to set acceptable, or does anything short of automatic defeat the point?
3. For pi users: is commands.toml plus asking your agent to fill it in already enough? That works
   today and needs no maintenance until you install a new skill.

If pi is the only real demand, this is small and I will build it. If most of the interest is in
Claude, then it needs an upstream change first.

[martin-tahli]

I'm interested in the automatic-discovery version as well. My use case is Pi with several extensions/packages, so it's not only installed skills that are missing from Collie's Agent palette — extension-registered commands and other live Pi commands are missing too.

Ideally Collie's Pi palette could use Pi's get_commands output and show the current session's real command registry, while keeping Collie's curated built-ins/fallback.

On mobile this would be especially useful because navigating Pi's native / autocomplete through the terminal mirror is much less convenient than Collie's Agent palette.

So +1 for automatic Pi discovery if you decide it's worth supporting.