From JFrog
Interact with the JFrog Platform via the JFrog CLI, JFrog MCP server and REST/GraphQL APIs. Use this skill when the user wants to manage Artifactory repositories, upload or download artifacts, manage builds, configure permissions, manage users and groups, work with access tokens, configure JFrog CLI servers, search artifacts, manage properties, set up replication, manage JFrog Projects, run security audits or scans, look up CVE details, query exposures scan results from JFrog Advanced Security, manage release bundles and lifecycle operations, aggregate or export platform data, or perform any JFrog Platform administration task. Also use when the user mentions jf, jfrog, artifactory, xray, distribution, evidence, apptrust, onemodel, graphql, workers, mission control, curation, advanced security, exposures, or any JFrog product name.
How this skill is triggered — by the user, by Claude, or both
Slash command
/jfrog:jfrogThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The foundational skill for all JFrog agent interactions. Covers JFrog Platform concepts, `jf` CLI setup and authentication, and intent routing to workflow skills.
references/apptrust-entities.mdreferences/artifactory-api-gaps.mdreferences/artifactory-aql-syntax.mdreferences/artifactory-entities.mdreferences/artifactory-operations.mdreferences/catalog-entities.mdreferences/general-bulk-operations-and-agent-patterns.mdreferences/general-parallel-execution.mdreferences/general-use-case-hints.mdreferences/jfrog-brand-html-report.mdreferences/jfrog-cli-install-upgrade.mdreferences/jfrog-entity-index.mdreferences/jfrog-login-flow.mdreferences/jfrog-url-references.mdreferences/onemodel-common-patterns.mdreferences/onemodel-graphql.mdreferences/onemodel-query-examples.mdreferences/platform-access-entities.mdreferences/platform-admin-api-gaps.mdreferences/platform-admin-operations.mdThe 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. In code examples below,
<skill_path> 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.
Try the tiers in order; move to the next only when the current does not cover the operation or fails:
CallMcpTool against the JFrog MCP
server. Discover available tools from the server's tool list; never
guess tool names.jf CLI subcommands (fallback): dedicated commands such as
jf rt upload, jf rt dl, jf build-publish.jf api (last resort): REST/GraphQL endpoints with no dedicated
subcommand. Validate the path first — see rule 6 in
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.
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 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.
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 <UA> for the rest of the
session:
bash <skill_path>/scripts/check-environment.sh <model-slug>
# stdout (one line): jfrog-skills/<version> [(tool=<harness>; model=<model-slug>)] jfrog-cli-go/<cli-version>
# 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.
JFROG_CLI_USER_AGENT once per bash invocationAt the top of every bash invocation that runs jf, export <UA> once;
all jf calls in that invocation pick it up:
export JFROG_CLI_USER_AGENT='<UA>'
jf config show
jf api /artifactory/api/system/version
Do not repeat the assignment per jf call (JFROG_CLI_USER_AGENT='<UA>' 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 <UA> 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.
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:
jfrog-skill-state.json — written by scripts/check-environment.sh
(24-hour CLI check cache).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/<name>-$$.json or mktemp -d), echo the path
when a follow-up Shell step must read the file — same pattern as Preserving
command output below.
Do not run commands speculatively. Before executing any JFrog CLI command, MCP tool call, or API call:
jf api with POST/PUT/DELETE).jf api paths, validate against
<skill_path>/references/ (or
JFrog OpenAPI specifications
if you have web access). On a 404, stop and report — never retry with a guessed
alternative path.Single-server invariant. Every jf call MUST pass --server-id <SID>
(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 <id>, …", "use <id>", "compare <a>
and <b>") — inferred intent is not an override.
Before your first jf call, resolve the default server-id and remember it
as <SID> for the rest of the session, same pattern as <UA>:
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 <SID> to every subsequent jf call. The flag goes
after the subcommand name, not after jf itself:
jf api --server-id <SID> /artifactory/api/system/versionjf rt ping --server-id <SID>jf --server-id <SID> api /… — fails with flag provided but not definedWhen launching a subagent, pass <SID> 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
JFROG_CLI_USER_AGENT. To add a new server, read
references/jfrog-login-flow.md.
If a jf call returns 401/403, 404, network error, timeout, or any other
failure, stop with no further jf calls and respond:
<server-id>returned<code>for<endpoint>:<short reason>. Other configured server(s):<list>— I won't query them without your explicit instruction. How would you like to proceed?
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.
references/jfrog-entity-index.md, then follow pointers to the relevant domain filereferences/jfrog-url-references.mdreferences/artifactory-entities.md (~220 lines)references/stored-packages-entities.md (~165 lines)references/artifactory-operations.md (for listing builds use AQL with limit/offset — see § Listing build names; for full build detail use GET /api/build/<name>/<number>?project= — see § Retrieving full build info)references/artifactory-aql-syntax.md (~585 lines)references/artifactory-api-gaps.md (~220 lines)references/xray-entities.md (~290 lines)references/xray-entities.md § Exposures (Advanced Security)references/xray-entities.md § Curation audit eventsreferences/release-lifecycle-entities.md (~180 lines)references/apptrust-entities.md (~155 lines)references/catalog-entities.md (~190 lines)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 lookupsreferences/onemodel-graphql.md (~325 lines)references/onemodel-query-examples.md (~555 lines)references/onemodel-common-patterns.md (~280 lines)references/platform-access-entities.mdreferences/platform-admin-operations.mdreferences/projects-api.md (~260 lines)references/platform-admin-api-gaps.md (~180 lines)references/jfrog-login-flow.md (~130 lines)jq unavailable: read references/jfrog-cli-install-upgrade.mdreferences/general-parallel-execution.md (~135 lines)references/general-bulk-operations-and-agent-patterns.mdreferences/jfrog-brand-html-report.mdreferences/general-use-case-hints.mdUse 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.
jf --help — list all namespaces and top-level commandsjf <namespace> --help — list subcommands in a namespacejf <command> --help — show usage, arguments, and options| 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
plCLI 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-create (atc), login, how, stats,
generate-summary-markdown, exchange-oidc-token, completion.
jf apijf api is the Tier 3 entry point for JFrog Platform REST and GraphQL
endpoints, auto-authenticated against the resolved server. Do not use
jf rt curl or jf xr curl; they are superseded by jf api.
jf api requires the full path including the product prefix; omitting it
returns 404.
| Product | Path prefix |
|---|---|
| Artifactory | /artifactory/api/... |
| Xray | /xray/api/... |
| Access (users, groups, tokens, permissions, projects) | /access/api/... |
| Evidence | /evidence/api/... |
| Release Lifecycle | /lifecycle/api/... |
| AppTrust | /apptrust/api/... |
| Distribution | /distribution/api/... |
| OneModel (GraphQL) | /onemodel/api/v1/graphql, /onemodel/api/v1/supergraph/schema |
| Mission Control | /mc/api/... |
| Curation | /xray/api/v1/curation/... (lives under Xray) |
jf api /artifactory/api/repositories
jf api --server-id <SID> /artifactory/api/system/version
# AQL (POST with text/plain body)
jf api /artifactory/api/search/aql \
-X POST -H "Content-Type: text/plain" -d '<aql-query>'
Common flags: -X/--method, -H/--header, -d/--data, --input <file>,
--server-id, --timeout. Body on stdout, status on stderr — see
Gotchas.
OneModel is the unified GraphQL API. Do not embed the query inside a JSON
literal (-d '{"query":"..."}') — escaping breaks requests. Build the payload
with jq -n --arg, pass it via --input, and save the response to a file
before running jq on it.
QUERY='{ evidence { searchEvidence(first: 5, where: { hasSubjectWith: { repositoryKey: "my-repo-local" } }) { totalCount } } }'
PAYLOAD=/tmp/onemodel-payload-$$.json RESPONSE=/tmp/onemodel-$$.json
jq -n --arg q "$QUERY" '{query:$q}' > "$PAYLOAD"
jf api /onemodel/api/v1/graphql -X POST \
-H "Content-Type: application/json" --input "$PAYLOAD" > "$RESPONSE"
jq . "$RESPONSE"
Schema discovery: jf api /onemodel/api/v1/supergraph/schema > "$SCHEMA_FILE"
(store only under ~/.jfrog/skills-cache/, never query responses). Read
references/onemodel-graphql.md for the full workflow (schema fetch,
validation, pagination, errors), plus references/onemodel-query-examples.md
and references/onemodel-common-patterns.md for query shapes, pagination,
variables, and dates.
Several CLI commands require JSON template files. The templates are normally
created by interactive wizard commands (jf rt rpt, jf rt ptt, jf rt rplt)
which agents cannot use. Instead, retrieve an existing config via REST API as a
starting point and modify it:
jf api /artifactory/api/repositories/<repo-key>
For other Artifactory or platform REST patterns, or when you need more than this repo GET, see Any API gap under When to read reference files.
jq.jf apijf api requires the product prefix in the path. Omitting it returns
404. See the product-prefix table for the full list.jf api writes the body (success or error JSON) to stdout and
[Info] Http Status: NNN to stderr on every call; non-2xx also exits
1 and adds [Warn] jf api: <method> <url> returned NNN. Pipe stdout to
jq directly; never 2>&1 | jq — stderr corrupts the JSON. To keep
diagnostics: jf api <path> 2>/tmp/err-$$.log | jq ..jf api has no -L (follow redirects) and no -o (output file).
Save bodies with shell redirection
(jf api ... > /tmp/out-$$.json); for
binary downloads through the Artifactory remote proxy prefer jf rt dl,
which handles the cache and redirect semantics natively.-cache suffixed repo. Properties
and AQL queries for remote repo artifacts must target the cache repo.
Conversely, /api/repositories/<key> only accepts the parent remote key
(without -cache) — strip the suffix for configuration lookups.jf rt search — always use a direct AQL query via
jf api /artifactory/api/search/aql -X POST -H "Content-Type: text/plain" -d '<aql>'.
See references/artifactory-aql-syntax.md.--quiet flag for non-interactive execution (suppresses confirmation
prompts). Caution: --quiet is not a global flag — commands that do not
support it (e.g. jf rt s, jf rt ping) will fail with misleading errors
like "Wrong number of arguments" or "flag provided but not defined". Check
--help for a command before adding --quiet.--server-id when targeting a non-default server. If a command fails
with --server-id, do not retry without it — that silently targets the
default server instead. See Server selection rules.jf config add,
jf login, jf rt repo-template, jf rt permission-target-template, and
jf rt replication-template. For server setup, follow references/jfrog-login-flow.md.
For templates, use JSON schemas or REST API. If a command prompts for input
unexpectedly, find the non-interactive alternative via --help or REST API.jf config export output is base64-encoded JSON. Decode with
base64 -d | jq to extract fields.?buildRepo= or ?project=) —
resolve it before calling the API. See references/artifactory-operations.md
§Retrieving build info for the full workflow.jf api call returns 401, the configured token may have expired or
been rotated — ask the user to re-run the login flow (see
references/jfrog-login-flow.md) for the same server. If 403, the
token lacks required permissions. If 404, verify the endpoint path
(especially the product prefix) and target server version. On any of
these errors, do not try a different configured server as a workaround —
that targets a different environment. Report the error and ask the user.applicability (top-level, often null) and
applicability_details (always present with a result string). Use
applicability_details[].result for counts and summaries. Using the
top-level applicability field for aggregation produces wrong counts because
it is null when no scanner exists. See references/xray-entities.md
§Contextual analysis for the eight possible result values and jq snippets.references/onemodel-graphql.md.jq parsing — save the
response to a temp file first (see Preserving command output).jq -e . before appending to a results file. One non-JSON
or empty response corrupts a downstream jq -s slurp. Write validated
lines to an NDJSON file, then jq -s '.' file.ndjson to produce the final
array. See references/general-bulk-operations-and-agent-patterns.md.references/general-use-case-hints.md
— read when debugging odd failures; append a short entry when you confirm
a new, reusable gotcha.When a task requires multiple independent operations, use the lightest
parallelism mechanism that fits. Three tiers: (1) batch commands in a single
Shell call using loops or &, (2) issue parallel Shell tool calls, (3) launch
parallel subagents for large fan-out. Read references/general-parallel-execution.md
(~135 lines) for tier selection, examples, and subagent prompt structuring.
When a CLI command or API call returns data, redirect the output to a temporary file so you can re-read it without re-executing the call:
OUT=/tmp/jf-repos-$$.json
jf api /artifactory/api/repositories > "$OUT"
echo "$OUT"
Use $$ (the shell PID) in the filename to prevent collisions across
concurrent sessions or processes.
Cross-call gotcha: each Shell tool invocation runs in a new process with a
different PID, so $$ expands to a different value in each call. Always
echo the expanded filename so the agent can read it from the output and
reuse the literal path in subsequent calls. Three patterns, in priority order:
$$ + echo (preferred): use $$ for collision safety, echo the path
as shown above. The agent reads /tmp/jf-repos-12345.json from the output
and passes that literal value to the next Shell call.SID=$(date +%s)-$$), echo it, and reuse in later calls.This protects against wasted round-trips when you need to retry parsing — for
example, if a jq filter fails or you extract the wrong field on the first
attempt. Re-read the file instead of hitting the server again.
Do not duplicate the same network request in a shell pipeline (e.g. with
||) only to re-run jq or to reveal jq diagnostics—the duplicate call
adds load on JFrog without fetching new data. Run
jq '<filter>' /tmp/jf-*-$$.json (or redirect stdin from the file) instead
of re-running the same jf api or other identical network-backed command.
Do not reuse saved output across unrelated steps or changed contexts (different server, user, or intent). The file is only valid for the immediate sequence of operations that motivated the original call.
Provides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub anthropics/claude-plugins-official --plugin jfrog