jfrog/opencode-jfrog-plugin/jfrog-ai-catalog

JFrog AI Catalog

Discover, install, and manage agent skills and agent plugins from the JFrog AI Catalog (Artifactory skills/plugins repositories), and publish your own back to it, all through the JFrog CLI (jf skills, jf agent plugins) and the JFrog Agent Guard.

Choose a reference file

Pick the row matching the user's intent and read that reference file.

Prerequisites

• Read the base `jfrog` skill first. `../jfrog/SKILL.md`

owns the shared guards this skill depends on, so this skill does not repeat them — follow them there:

• The environment check — confirm jf

is installed before the first jf call, and install it if missing.

• The server selection rules

— resolve the default <SID> once and reuse it, pass --server-id <SID> after the subcommand on every jf call, and use one server per request. Resolve it now, before any `jf` call: ```bash jf config show 2>/dev/null \

# stdout: the default server-id; if empty, stop and ask which server to use ```

• The stop-on-error rule — on any jf failure, stop and never switch servers.

One addition specific to this skill: never cat or parse ~/.jfrog/jfrog-cli.conf.v6 (it can hold access tokens); list servers only with jf config show, which redacts secrets.

• Agent Guard registry. Catalog discovery and repo provisioning run through

npx --yes @jfrog/agent-guard. <REGISTRY_URL> is the npm registry that provides the @jfrog/agent-guard package itself: use JFROG_AGENT_GUARD_REPO if set, otherwise https://releases.jfrog.io/artifactory/api/npm/coding-agents-npm/. Pass the same <SID> to Agent Guard as --server "<SID>" so it targets the same server as your jf calls. Agent Guard also reads JFROG_URL / JF_URL directly when set, so make sure the <SID> you resolved points at that same host.

• Resolve the project (`<PROJECT>`) only when needed.

It is required for --list-skills, --list-skill-versions, --provision-skills-repository, --list-agent-plugins, --list-agent-plugin-versions, --provision-agent-plugins-repository, and listing AI Catalog policies (references/listing-policies.md). Resolve it with this priority:

1. Parse ~/.jfrog/setup.json (if present) and read .servers["<SID>"].currentActiveProject.
2. Fall back to $JF_PROJECT.
3. If still empty, ask the user for the project key - do not guess.

``bash PROJECT=$(jq -r --arg sid "<SID>" '.servers[$sid].currentActiveProject // empty' \ ~/.jfrog/setup.json 2>/dev/null) [ -z "$PROJECT" ] && PROJECT="${JF_PROJECT:-}" ` There is no non-admin way to look up or validate project keys (the /access/api/v1/projects list endpoint needs admin), so you cannot silently correct a display name to a key. If the value looks like a display name (spaces, mixed case) rather than a short slug, ask the user to confirm the project **key** specifically. Never assume default, never invent one. Install, update, remove, and publishing to an explicit --repo` are keyed by skill/plugin name and/or repo, not a project.

• Bundle manifests differ by type. Skill bundles require SKILL.md

in the bundle root; plugin bundles require plugin.json. Validate the correct file before installing or publishing.

Workflow overview

flowchart TD
    A[User request] --> B{jf CLI installed?}
    B -->|No| C[Ask user to install jf CLI, then continue]
    B -->|Yes| D{Intent}
    C --> D
    D -->|List all skills / versions| E[npx @jfrog/agent-guard --list-skills --allowed-only]
    D -->|List policies for skills| M[Resolve project, run list-skill-policies.mjs]
    D -->|Install / update skill| F[Resolve slug + version, then jf skills install/update]
    D -->|List installed skills / remove| G[jf skills list / rm -rf install dir]
    D -->|Publish skill| H[Resolve/provision repo, validate bundle, jf skills publish]
    D -->|List all plugins / versions| I[npx @jfrog/agent-guard --list-agent-plugins]
    D -->|Install / update plugin| J[Resolve slug + version, then jf agent plugins install/update]
    D -->|List installed plugins / remove| K[jf agent plugins list / rm -rf install dir]
    D -->|Publish plugin| L[Resolve/provision repo, validate bundle, jf agent plugins publish]

Gotchas

Catalog-specific rules only. The shared jf guards — single server per request, stop-on-error, and cautious mutation — live in the base `jfrog` skill; follow those too. Flow-specific rules live in the reference files above.

• Which operations mutate: install and list are read-mostly; remove, registry

delete, and publish mutate state — the base skill's cautious-mutation rule applies to those three.

• Session pickup: installs, updates, and removals usually take effect only at

the next agent session start, so tell the user to restart.

• Don't leak the plumbing: present skills/versions/repos to the user, never

the npx/Agent Guard commands, --registry, flags, or cursors. Run follow-ups yourself. Discuss catalog filtering only when the user asks about missing or blocked results; follow the refusal in discovering-skills.md.

• Skill discovery is always policy-scoped: every skill and skill-version

listing must follow discovering-skills.md. Never weaken that listing path, including for audit, blocked-content, or named-repository requests. Each locations[] entry from --list-skill-versions also carries its own allowStatus, since a repo's governance status is a per-repo fact, never a per-version one (MLAI-1309) — see discovering-skills.md and installing-skills.md.

• Use the response templates verbatim: where a reference file gives a "reply

using this exact template" block, fill the placeholders and send exactly that, with the same wording every time and no extra preamble or commentary.

• Plugins have no Xray support: skip all Xray-related handling (no 403

gating on download, no inline scan on publish, no --skip-scan flag) when performing any jf agent plugins operation.