Skip to content

10. Capabilities, hosts, and delegation

.familiar/capabilities.json defines thirteen capability names and five states. Both lists are fixed:

project-instructions explicit-skills implicit-skills user-invocation-control
named-subagents mechanical-enforcement file-read
file-write document-tools background-work authenticated-knowledge
external-retrieval hosted-publication
State Meaning
active The released version exists and its health check passed.
available Possible, but it still needs separate setup or a live check.
unsupported The agent cannot do this.
unavailable Possible in principle, but not present here.
unknown Not determined.

No state implies a fallback. This vocabulary exists to prevent two failures: reporting available as if it were active, and describing a fallback that does not exist. The release checks confirm that the table uses only these names and states, and that document-tools is never active.

Core ships two subagents:

  • lookup finds material in 3-Knowledge/. It returns exact quotes with citation anchors and a coverage report, never conclusions.
  • web-lookup does the same on the open web, from primary sources. It returns the URL and the date read, and one of three results for each item.

An optional extension can ship more subagents under its own namespace. This manual covers core only.

The split is the point. Retrieval subagents return quotes and gaps, and the calling skill does the reasoning. A subagent cannot slip an inference into the answer, because it does not produce answers.

Before it hands work to a subagent, bootstrap.md checks the agent’s named-subagents state. If the state is not active, the agent loads retrieval-fallback.md and does the subagent’s work itself. An agent with no row in installed.json always falls into this case (see “Agents not listed” below). Retrieval then uses the main context. A review from several perspectives becomes a series of personas in one context, so the perspectives are not independent, and the delivery must say so.

Capability claude codex gemini
project-instructions active active active
file-read / file-write active active active
explicit-skills active active active
implicit-skills active active active
user-invocation-control active active unsupported
named-subagents active active active
mechanical-enforcement available available available
document-tools available available available
background-work available available unknown
authenticated-knowledge unknown unknown unknown
external-retrieval available unknown unknown
hosted-publication available unsupported unsupported

Entry files. CLAUDE.md is for Claude Code, GEMINI.md for Gemini CLI, and AGENTS.md for Codex. AGENTS.md is also written for Claude Code and Gemini CLI. CLAUDE.md and GEMINI.md only reference AGENTS.md and add no rules of their own, so the bootstrap text has one home.

Skills and subagents. Skills go in .claude/skills/<name>/ for Claude Code and in .agents/skills/<name>/ for Codex and Gemini CLI. Subagents ship as .claude/agents/*.md, .codex/agents/*.toml and .gemini/agents/*.md, each in that agent’s own format. On Codex and Gemini CLI, subagents use the current model and name no Claude model. Skills call a subagent by its project-level name. For an extension, that name is <namespace>-<agent> (§11.3).

INSTALL.md → Host support compares the three agents for users. docs/using-familiar.md covers how to start skills on each one.

Agents not listed. Other coding agents read AGENTS.md, for example Cursor, GitHub Copilot in VS Code and OpenCode. The bootstrap loads there, but installed.json has no row for them. The rule in extension-contract.md is that an agent with no row treats every capability as unknown. It does subagent work itself, through retrieval-fallback.md. Before it runs an extension route, it says that the route is not tested on this agent and asks the user. Some of these agents read both .claude/skills/ and .agents/skills/, so each skill can appear twice in their pickers. The two copies are the same.