Add GEAP Skill Registry integration for local harnesses by zbl94 · Pull Request #300 · google/ax

zbl94 · 2026-07-13T20:20:50Z

Materialize agentskills.io skills from the GEAP Skill Registry (Vertex AI v1beta1) into an on-disk skills directory before a harness starts, so the Antigravity and Antigravity Interactions harnesses can use registry-hosted skills on the local ax exec / ax serve path.

internal/skills/materialize: harness-agnostic package that reads config.SkillsConfig, drives the registry client (ListSkills / GetSkill / GetSkillRevision / skills:retrieve), safe-unzips payloads to <target_dir>//, and reports what it wrote. First-wins on duplicate ids with a warning; fail-safe (a registry error never blocks harness startup).
config: harnesses..skills.registries[] with per-registry selection (skills / query / all), required target_dir, and a validated "exactly one selection mode" rule. Also wires the interactions harness's system_instruction from ax.yaml.
cliutil: materializes skills at controller construction; for the interactions harness (no SKILLS_DIR concept) it appends a discovery pointer to the system instruction.

Scope: local path only; the substrate/pod path does not yet read ax.yaml. Verified end-to-end against a live registry (by-id and by-query).

wjjclaud

For the package name, is it better to use something like skills/geap or skills/geminienterprise to call out it is specific to skills from GEAP?

zbl94 · 2026-07-14T19:06:39Z

For the package name, is it better to use something like skills/geap or skills/geminienterprise to call out it is specific to skills from GEAP?

I moved these to internal/skills/gemini/client.go, and called the package gemini since go prefers short package names

joycel-github

LGTM with a few comments here and there. Thanks vm for getting this in!

joycel-github · 2026-07-14T23:54:16Z

+	for _, ref := range refs {
+ // First-wins: skip (with a warning) any id already materialized into this
+ // dir, rather than overwriting it.
+ if won, byRegistry := claimed.claim(targetDir, ref.SkillID, regIdx); !won {


should claim happen at the end

Why it should happen at the end? We are trying to claim a skill before fetching and writing to file to avoid conflicts (and save API calls if there are)

Materialize agentskills.io skills from the Gemini Enterprise Skill Registry (Vertex AI v1beta1) into on-disk folders before the harness starts, so the built-in harnesses can use registry-hosted skills on the local `ax exec` / `ax serve` path. - internal/skills/geminienterprise: harness-agnostic package that reads config.SkillsConfig, drives the registry client (ListSkills / GetSkill / GetSkillRevision / skills:retrieve), safe-unzips payloads to <target_dir>/<skill-id>/, and reports what it wrote. First-wins on duplicate ids with a warning; fail-safe (a registry error never blocks harness startup). - config: top-level `skills.registries[]` (harness-agnostic -- each actor runs a single harness that consumes the materialized folder). Per-registry selection (skills / query / all), required target_dir, and a validated "exactly one selection mode" rule. Also wires the interactions harness's system_instruction from ax.yaml. - cliutil: materializes skills once, up front, at controller construction; for the interactions harness (no SKILLS_DIR concept) it appends a discovery pointer to the system instruction. Scope: local path only; the substrate/pod path does not yet read ax.yaml. Verified end-to-end against a live registry (by-id and by-query).

Previously, ax serve called cfg.Validate() before constructing the controller, but ax exec did not. A misconfigured ax.yaml could pass through runExec and only surface as an obscure error later. Mirror the validation call so both entry points have parity in startup checks. Addresses A8 in TODO.md.

…300) Materialize agentskills.io skills from the Gemini Enterprise Skill Registry (Vertex AI v1beta1) into on-disk folders before the harness starts, so the built-in harnesses can use registry-hosted skills on the local `ax exec` / `ax serve` path. - internal/skills/geminienterprise: harness-agnostic package that reads config.SkillsConfig, drives the registry client (ListSkills / GetSkill / GetSkillRevision / skills:retrieve), safe-unzips payloads to <target_dir>/<skill-id>/, and reports what it wrote. First-wins on duplicate ids with a warning; fail-safe (a registry error never blocks harness startup). - config: top-level `skills.registries[]` (harness-agnostic -- each actor runs a single harness that consumes the materialized folder). Per-registry selection (skills / query / all), required target_dir, and a validated "exactly one selection mode" rule. Also wires the interactions harness's system_instruction from ax.yaml. - cliutil: materializes skills once, up front, at controller construction; for the interactions harness (no SKILLS_DIR concept) it appends a discovery pointer to the system instruction. Scope: local path only; the substrate/pod path does not yet read ax.yaml. Verified end-to-end against a live registry (by-id and by-query).

zbl94 force-pushed the skills-registry-integration branch 2 times, most recently from 48f7b5c to 50451c2Compare July 14, 2026 00:00

zbl94 requested review from joycel-github, rakyll and wjjclaud July 14, 2026 00:06

wjjclaud mentioned this pull request Jul 14, 2026
[substrate] Interactions actor reads harness config from ax.yaml #302
Merged

wjjclaud reviewed Jul 14, 2026
View reviewed changes

zbl94 force-pushed the skills-registry-integration branch from 50451c2 to c5bbba4Compare July 14, 2026 19:05

zbl94 requested a review from wjjclaud July 14, 2026 19:06

joycel-github approved these changes Jul 14, 2026
View reviewed changes

zbl94 force-pushed the skills-registry-integration branch 3 times, most recently from 5c818b0 to 4f8e7f9Compare July 14, 2026 21:59