# Jfrog

> >-

- **Type:** Skill
- **Install:** `agentstack add skill-jfrog-jfrog-skills-jfrog`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [jfrog](https://agentstack.voostack.com/s/jfrog)
- **Installs:** 0
- **Category:** [Cloud & Infrastructure](https://agentstack.voostack.com/c/cloud-infrastructure)
- **Latest version:** 0.1.0
- **License:** Apache-2.0
- **Upstream author:** [jfrog](https://github.com/jfrog)
- **Source:** https://github.com/jfrog/jfrog-skills/tree/main/skills/jfrog

## Install

```sh
agentstack add skill-jfrog-jfrog-skills-jfrog
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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.
2. **`jf` CLI subcommands** (fallback): dedicated commands such as
   `jf rt upload`, `jf rt dl`, `jf build-publish`.
3. **`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
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:

```bash
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).
2. **`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.
2. Resolve the target server using the **Server selection rules** below —
   there must be no ambiguity about which server is used
3. 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).
4. Prefer read operations first to understand current state before making changes
5. **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.
6. **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](https://docs.jfrog.com/integrations/docs/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 ``:

```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 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
`JFROG_CLI_USER_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](https://github.com/jfrog)
- **Source:** [jfrog/jfrog-skills](https://github.com/jfrog/jfrog-skills)
- **License:** Apache-2.0

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** yes
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-jfrog-jfrog-skills-jfrog
- Seller: https://agentstack.voostack.com/s/jfrog
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.