`harness` compatibility layer — a BUILT-IN foundation module (ships in the
main jar, always present, gated by toggles) that exposes the AGENTS and
SKILLS vis' own project
dir and other AI coding HARNESSES (Claude Code, pi, opencode, the agents
standard, …) leave on disk to the vis model. The sibling of the shell
layer's POSIX compat. Vis reads its OWN project-local skills from
`.vis/skills` (highest precedence).

Two bare verbs (bound like cat/rg via `:ext.engine/builtin? true`):

- SKILLS are PROGRESSIVE: the prompt lists every skill `name — description`
  (cheap — always present), and
  `skill(name)` loads the FULL `SKILL.md` + its bundled resource PATHS on
  demand so the model spends tokens only on the one it uses.

- AGENTS are an ALIAS to `sub_loop`: `agent(name, prompt)` runs the named
  agent as a CHILD loop whose system prompt IS that agent's markdown body,
  on its declared model.

Both bare verbs are unconditionally available — skills/agents/commands have
no user toggle; the layer is always active.

Cross-HARNESS discovery of agents + skills — the sibling of the shell
layer's POSIX compat, for the agent/skill definitions vis' OWN project dir
and OTHER AI coding harnesses (Claude Code, pi, opencode, the agents
standard, …) leave on disk.

An AGENT is a markdown file with YAML-ish `---` frontmatter
(`name`, `description`, `model`, `tools`) + a body that IS a system
prompt. A SKILL is a `SKILL.md` (same frontmatter, name+description) in
its own directory, alongside bundled resource files.

Discovery is PURE except for the directory scan: `parse-frontmatter`,
`parse-agent`, `parse-skill-meta`, and `dedup-by-name` take strings and
are unit-tested without the filesystem; the `discover-*` fns walk the
known source roots. Precedence is source ORDER, first-name-wins
(vis project-local > other harnesses' project > user > plugin; Vis and
Claude before pi/agents/opencode).