Summary
Feature request, two parts: (1) add Meta Muse as a supported coding agent in ACFS, and (2) expand the setup documentation so the full roster of compatible agents is spelled out in one place. Today the manifest ships seven agent modules but the setup docs enumerate only some of them, so users can't easily see what's available, what's default vs optional, or how to turn each one on.
Part 1 — Add Meta Muse agent capability
Please add Meta Muse alongside the existing agents so it can be installed and selected like the others. Structurally that means a new agent module mirroring the current ones:
- a manifest entry
agents.museinacfs.manifest.yaml(next toagents.claude…agents.grok), markedoptional: true; - an
install_muse(or equivalent) routine inscripts/lib/agents.shfollowing the same verified-installer pattern as the other agents; - a wizard checkbox + a
--only agents.muse/--skip agents.musepath; - a doctor check and a shell entrypoint/alias consistent with
cc/cod/agy.
I wasn't able to find any existing muse reference in the repo, so I'll defer the exact CLI name, install command, and auth flow to whoever picks this up (happy to add details if you tell me the canonical installer). The ask here is the capability + a slot in the agent model.
Part 2 — Document the compatible agents in the setup section (the main ask)
The agent roster is currently under-documented and slightly out of sync between the manifest and the prose. The manifest defines seven agent modules:
| module | status | notes |
|---|---|---|
agents.claude | default (optional: false, recommended) | Claude Code (cc) |
agents.codex | default (optional: false, recommended) | Codex CLI (cod) |
agents.antigravity | default (optional: false, recommended) | Antigravity CLI (agy) |
agents.gemini | optional (optional: true) | not mentioned in the setup docs at all |
agents.opencode | optional (optional: true) | OpenCode |
agents.omp | optional (optional: true) | oh-my-pi |
agents.grok | optional (optional: true) | Grok CLI |
But the setup/quick-install prose only says: "Three AI coding agents by default (Claude Code, Codex CLI, Antigravity CLI), plus optional OpenCode, oh-my-pi (omp), and Grok CLI" (README.md:73, echoed at README.md:66). That enumerates six and omits agents.gemini entirely, even though it's a real installable module. A new user reading the setup section has no way to learn Gemini is supported, or how to enable any of the optional agents.
Request: add a single "Compatible Agents" table to the setup section (and mirror it on the wizard accounts step / apps/web/app/learn/commands), with a row per agent covering:
- display name + shell entrypoint (
cc,cod,agy, …) - default vs optional
- manifest id (
agents.<x>) and how to enable/disable it (wizard checkbox,--only agents.<x>,--skip agents.<x>) - account/auth required to actually use it
- one-line "what it's good for"
Meta Muse (Part 1) becomes one more row in that table once it lands.
Why
The "set up three agents" framing undersells the framework — it already supports Gemini/OpenCode/omp/Grok — and there's no single place that lists the options and how to turn them on. A compatible-agents table makes the roster discoverable and gives new agents (like Meta Muse) an obvious home in the docs.
Suggested acceptance
-
agents.musemodule + installer + wizard/flag/doctor wiring - "Compatible Agents" table in the README setup section listing all supported agents (incl.
gemini), their status, and how to enable each - Same roster surfaced on the wizard accounts step and the /learn commands page
Activity
2
Dicklesworthstone1mo agoPart 2 is in on main as bd480b6d (schema groundwork landed just before it in 9cce14f0). Part 1 (Meta Muse) is still open — see the bottom.
What I verified first. Your count is right: acfs.manifest.yaml defines seven agents.* modules, and the README prose enumerated six of them. agents.gemini is real and installable, but it is tagged legacy (optional: true, enabled_by_default: false) because the upstream CLI retired on 2026-06-18 and gmi now routes to the locked Antigravity launcher — so the roster shows it as Legacy rather than as a plain optional agent.
What I changed. Rather than write the table by hand — which is how the prose got out of sync in the first place — the roster is generated from the manifest by the same bun run generate pipeline that produces the installer scripts and the website data:
- Every
agents.*module now carries anagent:block inacfs.manifest.yaml: display name, vendor, CLI, ACFS shell aliases, sign-in command, docs URL and a one-line "what it's good for". Install status is deliberately not declared there —Default/Optional/Legacyis derived fromenabled_by_default,optionaland thelegacytag, so the table can never claim something the installer does not do. The schema (packages/manifest/src/schema.ts) rejects the block on any non-agentsmodule, requires anhttpsdocs URL, and rejects raw|or newlines in the free-text fields since they render inside a Markdown table. packages/manifest/src/generate.tsrenders it into three places:README.md, inside<!-- BEGIN GENERATED: compatible-agents -->markers (the "Compatible AI Coding Agents" section), plus a second small region for the TL;DR line. Region patching is idempotent — regenerating a current README is a no-op — and it re-reads the file before writing so a concurrent edit outside the markers cannot be clobbered.apps/web/lib/generated/manifest-agents.ts, a new generated data module.- A shared
<AgentRoster>component (apps/web/components/agent-roster.tsx) rendered on/learn/commandsand on the wizard Set up accounts step. The "your three coding agents" caption on the commands page now counts the manifest instead of hardcoding a number.
- The columns are the ones you asked for: agent (+ vendor), CLI with its ACFS aliases, default vs optional, the module id, the sign-in command, and a docs link — with the one-line summary under the name, and a note explaining
--only <module>/--skip <module>. - The TL;DR bullet that said "Three AI coding agents by default … plus optional OpenCode, oh-my-pi (omp), and Grok CLI" is gone; that sentence is now generated too and reads "7 modules — 3 installed by default (…); 3 optional (…); 1 legacy, off by default (…)".
So it cannot go stale. The manifest drift contract (packages/manifest/src/drift-contract.ts, run by scripts/check-manifest-drift.sh) gained four checks: an agents.* module with no agent: block, missing README region markers, a README region that does not match the manifest, and a generated web row that went missing. Adding an agent module without roster metadata now fails the release gate instead of quietly vanishing from the docs. Tests: packages/manifest 505 pass, apps/web unit suite 366 pass, bun run generate is a no-op afterwards, scripts/check-manifest-drift.sh --json reports drift_detected: false.
One intentional limitation: check-manifest-drift.sh --fix will not auto-commit README.md, because everything outside those markers is hand-written and the fixer's publication set is deliberately closed. It reports the stale region and leaves the regenerated README for review.
Part 1 (Meta Muse) stays open. I still need to settle the canonical installer, the CLI name and the auth flow before it gets a manifest slot — a verified-installer module needs a pinned URL and a SHA in checksums.yaml, and I'm not going to guess at those. Once that's decided it is a small change: an agents.muse module with an agent: block, and it appears in the README table, the /learn page, the wizard step and the doctor checks automatically. If you have the upstream install command and login flow, drop them here and I'll wire it up.
Thanks for the careful write-up; the point about
agents.geminibeing a real manifest module that the setup prose never mentions is well taken. Considering both parts (the roster table is straightforward; Meta Muse needs a decision on the canonical installer and auth flow before it gets a manifest slot). Leaving this open until that's settled.