Jfrog

JFrog Skill

The foundational skill for all JFrog agent interactions. Covers JFrog Platform concepts, jf CLI setup and authentication, and intent routing to workflow skills.

Interact with the JFrog Platform through three tool tiers — see [Tool selection strategy](#tool-selection-strategy). In code examples below, `` refers to this skill's directory and is resolved automatically by the agent. If the agent does not resolve it, determine the path by locating this SKILL.md file and using its parent directory.

Tool selection strategy

Try the tiers in order; move to the next only when the current does not cover the operation or fails:

1. JFrog MCP tools (preferred): CallMcpTool against the JFrog MCP

server. Discover available tools from the server's tool list; never guess tool names.

1. jf CLI subcommands (fallback): dedicated commands such as

jf rt upload, jf rt dl, jf build-publish.

1. jf api (last resort): REST/GraphQL endpoints with no dedicated

subcommand. Validate the path first — see rule 6 in [Cautious execution](#cautious-execution).

MCP and the CLI may use different token scopes. If one tier returns 403, try the alternate tier before reporting the operation blocked.

Prerequisites

The following tools must be available on PATH:

| Tool | Purpose | |------|---------| | jq | JSON parsing of CLI and API output |

All JFrog HTTP traffic from Tiers 2 and 3 goes through the jf CLI itself (jf api, see [Invoking platform APIs with jf api](#invoking-platform-apis-with-jf-api) below) — no standalone curl is required for any JFrog interaction.

Runtime permission for JFrog calls. All jf calls that touch the network need an outbound-HTTPS escalation from the agent runtime. The ~/.jfrog/ credential save (jf config add during login) additionally needs a filesystem-write escalation.

| Runtime | Network | Network + ~/.jfrog/ write | | ----------- | --------------------------------------------- | ------------------------------- | | Cursor | required_permissions: ["full_network"] | required_permissions: ["all"] | | Claude Code | allowed-tools: Bash(jf:*) + host allowlist | same + filesystem allowlist | | Other | Configure at the runtime/sandbox layer | same |

If jf exits 1 with empty output, the runtime's network gate is the first thing to check — re-run with the appropriate escalation above.

Environment check

MCP (Tier 1) operations do not require this check and can proceed immediately. Before your first Tier 2 or Tier 3 (jf) operation in a session, run the environment check and remember its stdout as `` for the rest of the session:

bash /scripts/check-environment.sh 
# stdout (one line): jfrog-skills/ [(tool=; model=)] jfrog-cli-go/
# stderr: JSON state (cached 24h at ${JFROG_CLI_HOME_DIR:-$HOME/.jfrog}/skills-cache/jfrog-skill-state.json)

Pass the precise underlying-model slug with version: opus-4.7, sonnet-4.5, gpt-5-codex, gemini-2.5-pro, composer-2-fast. Cursor's Composer product slug is the canonical id — use it as-is. Do not pass harness/role names (subagent, agent, assistant) or bare family names (claude, gpt); subagents inherit the parent's slug. If genuinely unknown, pass unknown.

Export JFROG_CLI_USER_AGENT once per bash invocation

At the top of every bash invocation that runs jf, export ` once; all jf` calls in that invocation pick it up:

export JFROG_CLI_USER_AGENT=''
jf config show
jf api /artifactory/api/system/version

Do not repeat the assignment per jf call (JFROG_CLI_USER_AGENT='' jf … on every line). Examples elsewhere in this skill and in references/*.md omit the export for readability — the rule is global. When launching a subagent, pass `` in its prompt; subagents do not re-run the script.

| Exit | Meaning | |------|---------| | 0 | Cache fresh — CLI ready (Tiers 2 and 3 available), proceed | | 1 | Cache refreshed — CLI ready (Tiers 2 and 3 available), proceed | | 2 | jf not installed — Tiers 2 and 3 unavailable; only MCP (Tier 1) remains | | 3 | jf below minimum version — Tiers 2 and 3 unavailable; only MCP (Tier 1) remains |

Exit 2 or 3 is not a fatal error. Attempt to install or upgrade the CLI (see references/jfrog-cli-install-upgrade.md). If installation succeeds, re-run the environment check. If installation is not possible (no permissions, restricted environment), proceed with MCP (Tier 1) only. Both jf CLI commands (Tier 2) and jf api (Tier 3) require a working jf installation.

JSON parsing (jq)

Use jq for all JSON parsing of CLI and API output (pipes, -r, filters).

~/.jfrog/skills-cache/ — allowed files only

${JFROG_CLI_HOME_DIR:-$HOME/.jfrog}/skills-cache/ is not a general scratch or temp directory. Use it only for these two artifacts:

1. jfrog-skill-state.json — written by scripts/check-environment.sh

(24-hour CLI check cache).

1. onemodel-schema-${JFROG_SERVER_ID}.graphql — cached OneModel supergraph

schema (see references/onemodel-graphql.md).

Do not save HTTP response bodies, GraphQL query results, ad-hoc JSON, reports, or any other temporary files under skills-cache/. Write those to a host temp path instead (for example /tmp/-$$.json or mktemp -d), echo the path when a follow-up Shell step must read the file — same pattern as Preserving command output below.

Cautious execution

Do not run commands speculatively. Before executing any JFrog CLI command, MCP tool call, or API call:

1. Confirm the operation is needed to fulfill the user's request.

If the request is ambiguous or could refer to multiple systems (e.g. "builds" could mean Artifactory build-info or CI/CD pipeline runs), ask the user for clarification instead of guessing. Never fetch data from the wrong system — a wrong answer is worse than asking a question.

1. Resolve the target server using the Server selection rules below —

there must be no ambiguity about which server is used

1. For mutating operations (create, update, delete, upload), confirm with the

user unless the intent is clearly implied. This applies to all tiers (MCP tools, CLI commands, and jf api with POST/PUT/DELETE).

1. Prefer read operations first to understand current state before making changes
2. Never invent preparatory mutations. If the requested operation fails

because a precondition is not met (artifact missing from the specified repo, repository does not exist, package not at the expected location, build not found), stop and report the gap to the user. Do not perform copy, move, upload, create-repo, or any other mutating operation to satisfy the precondition unless the user explicitly asks for it. These "helper" mutations can have cascading effects the user has not considered — virtual repository resolution changes, storage quota consumption, replication triggers, Xray re-indexing, or permission propagation.

1. Never guess tool names or API paths. For MCP tools, confirm the tool

exists in the server's tool list. For jf api paths, validate against /references/ (or JFrog OpenAPI specifications if you have web access). On a 404, stop and report — never retry with a guessed alternative path.

Server selection rules (mandatory)

Single-server invariant. Every jf call MUST pass --server-id (default resolved below); for one user request, all jf calls use exactly one server-id. A wrong answer from the wrong server is worse than a stop-and-ask.

JFrog MCP and CLI use independent auth. MCP tools authenticate through the MCP server session (not jf config); CLI commands authenticate through jf config. If you switch the CLI target server via jf config use, the MCP connection still points to its original server. Do not mix MCP and CLI calls targeting different servers in the same session. If the user asks to switch servers, warn that MCP tools will continue to target the original server until the MCP connection is re-established.

MUST NOT retry on a second configured server after 401/403/404, empty, or partial results; MUST NOT infer multi-server intent from "my"/"our" or from seeing extra entries in jf config show. Override: only when the user explicitly names another id ("on `, …", "use ", "compare and `") — inferred intent is not an override.

Resolve the default once per session

Before your first jf call, resolve the default server-id and remember it as ` for the rest of the session, same pattern as `:

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 to use

Pass --server-id to every subsequent jf call. The flag goes after the subcommand name, not after jf itself:

• ✅ jf api --server-id /artifactory/api/system/version
• ✅ jf rt ping --server-id
• ❌ jf --server-id api /… — fails with flag provided but not defined

When launching a subagent, pass ` in its prompt — subagents do not re-resolve. Examples elsewhere in this skill and in references/*.md omit --server-id for readability; the rule is global, same as JFROGCLIUSER_AGENT. To add a new server, read references/jfrog-login-flow.md`.

On any error, stop — never switch

If a jf call returns 401/403, 404, network error, timeout, or any other failure, stop with no further jf calls and respond:

> ` returned for : . Other > configured server(s): ` — I won't query them without your explicit > instruction. How would you like to proceed?

When to read reference files

Load the most specific file for the task at hand. Avoid loading more than 2-3 reference files for a single operation — start with the most relevant one and only load additional files if the first doesn't cover the need. File sizes vary (~25–640 lines); larger files are noted with approximate line counts below.

Cross-domain

• Disambiguating a JFrog entity, understanding entity types, or planning operations that span multiple products: read references/jfrog-entity-index.md, then follow pointers to the relevant domain file
• Looking up documentation URLs: read references/jfrog-url-references.md

Artifactory

• Repository types, artifacts, builds, properties, or permission targets (concepts): read references/artifactory-entities.md (~220 lines)
• Stored packages, package versions, version locations, or the metadata layer over Artifactory (concepts): read references/stored-packages-entities.md (~165 lines)
• Repo, file, build, permission, user/group, or replication operations: if the JFrog MCP server exposes a tool for the operation, prefer it. For CLI/API fallback, read references/artifactory-operations.md (for listing builds use AQL with limit/offset — see § Listing build names; for full build detail use GET /api/build//?project= — see § Retrieving full build info)
• AQL queries: read references/artifactory-aql-syntax.md (~585 lines)
• Artifactory REST beyond the CLI, structured JSON templates (replacing interactive wizards), or any Artifactory API gap: read references/artifactory-api-gaps.md (~220 lines)

Xray & security

• Watches, policies, violations, components, or vulnerability scanning (concepts): read references/xray-entities.md (~290 lines)
• Exposures scanning results (secrets, IaC, service misconfigurations, application security risks): read references/xray-entities.md § Exposures (Advanced Security)
• Curation audit events (approved/blocked packages, dry-run policy evaluations, curation export): read references/xray-entities.md § Curation audit events

Release lifecycle & distribution

• Release bundles, lifecycle stages, distribution, or evidence (concepts): read references/release-lifecycle-entities.md (~180 lines)
• Applications, application versions, releasables, promotions, or AppTrust (concepts): read references/apptrust-entities.md (~155 lines)

Catalog

• Public or custom catalog, package metadata, vulnerability advisories, licenses, OpenSSF, or MCP services (concepts): if the JFrog MCP server exposes a catalog tool, prefer it for single-package lookups. For deeper queries, read references/catalog-entities.md (~190 lines)
• CVE details, vulnerability lookup by CVE ID, or severity/affected-packages/fix-versions for a specific CVE: prefer an MCP vulnerability-lookup tool if the JFrog MCP server exposes one. Otherwise read references/onemodel-query-examples.md § Public security domain for the searchVulnerabilities query shape — this is self-contained; do not load the jfrog-package-safety-and-download skill for pure CVE lookups

OneModel (GraphQL)

• GraphQL queries (applications, packages, evidence, release bundles, catalog, cross-domain, or "list/search my" platform entities): read references/onemodel-graphql.md (~325 lines)
• Query templates and domain-specific examples: read references/onemodel-query-examples.md (~555 lines)
• Pagination, filtering, GraphQL variables, or date formatting: read references/onemodel-common-patterns.md (~280 lines)

Platform administration

• Platform structure, project/repo membership, or project roles vs environments (concepts): read references/platform-access-entities.md
• Access tokens, stats, projects, or system health: read references/platform-admin-operations.md
• Managing JFrog Projects, members, or environments: read references/projects-api.md (~260 lines)
• Platform REST beyond the CLI, or any platform-level API gap: read references/platform-admin-api-gaps.md (~180 lines)

CLI setup & authentication

• Adding a server or logging in: read references/jfrog-login-flow.md (~130 lines)
• CLI not installed, upgrade needed, or jq unavailable: read references/jfrog-cli-install-upgrade.md

General patterns

• Batching, parallel Shell calls, or launching subagents: read references/general-parallel-execution.md (~135 lines)
• Large or parallel data gathering, list-vs-detail APIs, cache hygiene: read references/general-bulk-operations-and-agent-patterns.md
• Standalone HTML report with JFrog-aligned styling: read references/jfrog-brand-html-report.md
• Reusable gotchas from past tasks: read or extend references/general-use-case-hints.md

Command discovery

Use the commands listed below as your primary reference. Run --help to verify options you are unsure about or to discover commands not listed here — do not rely on memorized commands outside this skill, as they may be outdated.

1. jf --help — list all namespaces and top-level commands
2. jf --help — list subcommands in a namespace
3. jf --help — show usage, arguments, and options

CLI namespaces

| Namespace | Alias | Product | |-----------|-------|---------| | rt | | Artifactory | | xr | | Xray | | ds | | Distribution V1 | | at | apptrust | AppTrust | | evd | | Evidence | | mc | | Mission Control | | worker | | Workers | | config | c | CLI server configuration | | plugin | | CLI plugin management | | ide | | IDE integration |

> Sunset notice: JFrog Pipelines has been sunset and is no longer supported. > Do not use the pl CLI namespace or the Pipelines REST API > (/pipelines/api/...). If a user asks about Pipelines, inform them the > product has been sunset.

Top-level lifecycle commands (no namespace): rbc, rbp, rbd, rba, rbf, rbe, rbi, rbs, rbu, rbdell, rbdelr.

Top-level security commands: audit, scan, build-scan, curation-audit, sbom-enrich.

Top-level other: `access-token-cr

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jfrog
• Source: jfrog/jfrog-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.