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](../jfrog/SKILL.md)

owns the shared guards this skill depends on, so this skill does not repeat them — follow them there: - The [environment check](../jfrog/SKILL.md#environment-check) — confirm jf is installed before the first jf call, and install it if missing. - The [server selection rules](../jfrog/SKILL.md#server-selection-rules-mandatory) — 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 \ | awk '/^Server ID:/{id=$NF} /^Default:[[:space:]]*true/{print id; exit}' # 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. <REGISTRYURL> is the npm registry that provides the @jfrog/agent-guard package itself: use JFROGAGENTGUARDREPO 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 JFROGURL / JFURL 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, and --provision-agent-plugins-repository. 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]
    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](../jfrog/SKILL.md); 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.

• 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.