Harness registry

The harness registry is the source-of-truth adapter inventory used by the CLI, documentation, fixture tests, and convention-pin validation. The runtime source is src/apothem/lib/harness_registry.py; every row below is traceable to that registry, the per-adapter capabilities.yml, and each adapter's STANDARD-CONVENTION-PIN.md.

Registry matrixCopy Anchor Link

Payload cohort supportCopy Anchor Link

Status values are native, converted, support-tree, profile-projected, unsupported, not-applicable, and discovery-pending.

A converted cohort is rewritten into the harness's own format, and some source fields have no place in it. For each converted commands, agents, or rules cohort, the adapter's capabilities.yml carries a conversion_losses map that says what happens to every source frontmatter field:

A test renders every converted file and checks the maps against the output.

The table leaves out the cells the registry marks not-applicable: tool restrictions on every harness except Kimi Code (discovery-pending) and GLM (Z.ai) (unsupported), and memory on Claude Code, CodeBuddy, Codex, Hermes, Kiro, Open-Claw, OpenCode, and Qwen Code.

Shared rootsCopy Anchor Link

Some install targets are loaded by harnesses other than the one that writes them. The registry records each such path in SHARED_ROOTS with one registered owner (the adapter the vendor documents the path for), the co-installers that write the same files to it, and the readers whose vendor docs load it by default, plus the vendor pages that show it and the date they were retrieved.

A path with co-installers is a user-level folder in the home directory that several installs write with the same bytes. A machine with only Cursor installed has no Codex to write ~/.agents/skills/, so each install that names the folder writes it, and the install ledger counts the installs that use it. The owner of record is the registered owner while it uses the folder, and otherwise the oldest install that does; nothing moves when the registered owner is uninstalled. An uninstall removes the folder only when no other install still uses it (see uninstall). Installing a reader puts no files in the folder; installing the owner or a co-installer puts Apothem content in front of every reader.

~/.config/apothem/rules/ and ~/.config/apothem/templates/ hold the files Apothem's own skills and instruction files cite. No other tool loads them, so they have no readers and no vendor pages. CodeBuddy, Kiro, and Trae also write a skills folder of their own (~/.codebuddy/skills/, ~/.kiro/skills/, and ~/.trae/skills/); only that tool loads it, so it is not a shared root.

A reader is listed only where its vendor docs show a default load of that exact path. One reader carries a condition, and the install note repeats it: Open-Claw indexes ~/.agents/skills/ only under its default state directory (it skips the folder when OPENCLAW_STATE_DIR points elsewhere). The Cursor docs list ~/.codex/agents/ as a Codex compatibility folder but do not say which file formats Cursor parses there, and a Codex install writes TOML files, so whether Cursor reads those helpers is not confirmed. The Cursor install also writes its own <project>/.cursor/agents/ copy of the helpers, which the vendor's precedence ranks above the folders it imports, so in an installed project the native copy supersedes the one from ~/.claude/agents/.

Some tools are deliberately not readers of ~/.agents/skills/: the Antigravity, CodeBuddy, Kiro, and Trae docs do not say they load it by default (Trae loads the project .agents/skills/ folder only after a setting is switched on), which is why CodeBuddy, Kiro, and Trae get a skills folder of their own. The Hermes docs name it only as an example value for skills.external_dirs. GitHub Copilot is not a reader of ~/.claude/agents/: the VS Code docs list that folder for the Anthropic Claude agent, not for the agent GitHub Copilot runs.

The Apothem block an owner writes into a shared instruction file names no single tool as its reader. tests/unit/test_shared_roots.py fails when the adapters that write a registry target are not exactly its owner and its co-installers, and when a registry target named like a cross-tool instruction file (AGENTS.md, CLAUDE.md, GEMINI.md, copilot-instructions.md) has no declared owner. The one exception is ~/.codex/AGENTS.md, which no other registered harness documents loading.

Validation hooksCopy Anchor Link

The registry stays synchronized through these checks:

Generated Harness Adapter ReferenceCopy Anchor Link