メニュー
Set up and verify the JFrog plugin. Run on first install, to complete initial configuration, or to diagnose a broken setup.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/jfrog/jetbrains-plugin --skill jfrog-initコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
Use to install, list, or remove MCP servers, and to discover which MCPs the user can install — including questions about available, approved, or allowed MCPs for a project. That governed catalog is the authoritative answer; do not answer those questions from local IDE/settings allowlists alone. Use whenever the user wants to add/enable/install/list/remove/uninstall/configure an MCP or write/update the agent's MCP config — even if they name a package like `@scope/pkg` and even without saying "MCP" or "JFrog". Never install an MCP any other way. All of this goes through the JFrog Agent Guard (npx @jfrog/agent-guard).
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. Do NOT use this skill to install, add, remove, list, or manage MCP servers.
| name | jfrog-init |
| description | Set up and verify the JFrog plugin. Run on first install, to complete initial configuration, or to diagnose a broken setup. |
| disable-model-invocation | true |
| compatibility | Requires Node.js 18 or newer, and network access to the JFrog platform. |
| allowed-tools | Bash(node --version) Bash(node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-catalog-runtime.mjs"*) Bash(node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-jf-cli.mjs"*) Bash(node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-jf-config.mjs"*) Bash(node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-jfrog-mcp.mjs"*) Bash(node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-project.mjs"*) Bash(node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-server-ping.mjs"*) Bash(node "${CLAUDE_SKILL_DIR}/scripts/jfrog-re*.mjs"*) Bash(node "${CLAUDE_SKILL_DIR}/scripts/jfrog-state-file.mjs" get*) Bash(node "${CLAUDE_SKILL_DIR}/scripts/jfrog-state-file.mjs" path*) Bash(node -e "import('${CLAUDE_SKILL_DIR}/scripts/jfrog-resolve-mcp-config.mjs').then(function(m){console.log(m.detectHarness())})") Bash(npx --version) Bash(uname:*) AskUserQuestion |
| metadata | {"role":"workflow"} |
First output must be a tool call, not text. No "I'll start..." preamble.
Walks a fixed, ordered checklist and stops at the first red result, guiding
the user through the matching fix before re-checking. Every detector in
scripts/ is idempotent, read-only, JSON-emitting, and implemented in
Node (.mjs), so the same detector runs unmodified on macOS, Linux, and
Windows. Step 3's web-login uses this skill's own local .mjs scripts,
same as every other step. The one interactive fix step that isn't a Node
script at all is Step 1's Node install itself — a missing Node can't run
a .mjs installer, so that one step branches on OS or shell directly.
Approval model — every user-approval point is detailed in its own Step
below (exact wording, AskUserQuestion payloads, forbidden phrases);
this is just the map:
node — AskUserQuestion Yes/No before auto-installing (Step 1).jf (JFrog CLI) — AskUserQuestion Yes/No before auto-installing
(Step 2).jf config — AskUserQuestion picker (web login, in-session, vs.
access token, which never enters this conversation) (Step 3/4).AskUserQuestion picker offers the first two enumerated projects
plus "Other" (Step 6).mcp.json, unattended by design —
no AskUserQuestion, see references/script-invocation.md), Step 8's
~/.netrc write (also unattended, no AskUserQuestion — see
references/marketplace-setup.md), and the Final summary's state
write below.Step 1's nvm install and jfrog-install-jf-cli.mjs, Step 3's
web-login scripts, Step 8's jfrog-add-claude-marketplace.mjs call,
and the Final summary's jfrog-state-file.mjs set call are
deliberately not in allowed-tools and will raise the harness's
own approval prompt — intended, not a misconfiguration; see
references/script-invocation.md.
${CLAUDE_SKILL_DIR} below is this file's own directory. Claude Code
substitutes it automatically, identically, in both this text and the
Bash rules above — write it literally rather than
resolving it yourself, so the two stay byte-for-byte consistent
regardless of install depth (see ). On
a harness that doesn't perform this substitution (e.g. Cursor or Codex,
neither of which consults for approval — every command
below still raises its own prompt there), replace it with the real
absolute path of this file's directory yourself, same as before.
allowed-toolsreferences/script-invocation.mdallowed-toolsrc=$? is mandatory on every detector invocation — see
Invoking scripts. A
bare ; true hides every red/ask result as green.AskUserQuestion Yes/No before auto-installing
Node (Step 1) or jf (Step 2); AskUserQuestion picker for
web-login vs. token (Step 3/4); AskUserQuestion picker for project
selection (Step 6). Everything else is read-only except Step 5's
placeholder substitution, Step 8's ~/.netrc write, and the Final
summary's state write.<server-id> for Steps 4-7 always comes from the shared resolver
(explicit arg → JF_SERVER_ID → isDefault → sole configured server
→ ask) — never invented, never jf's own fallback. Step 8 reuses the
same value. See
Resolving <server-id>.jfrog-state-file.mjs set whenever Steps 1-4 are green, regardless of
Step 5/6/7. See Final summary.jf's own process or in-memory for one fetch call. Step 8
is the one deliberate exception (writes ~/.netrc) — see
Step 8 and
Non-goals.../jfrog/SKILL.md's prerequisites — do not
run its environment check as a gate before starting this walk.../jfrog/SKILL.md for foundational
context — JFrog Platform concepts and terminology, and the
Server selection rules
this skill's own "Resolving <server-id>" section (below) follows the
same never-guess/never-infer philosophy of, via its own mechanism.jf is
already installed at a working version — /jfrog-init is what gets a
user from nothing installed to that point. Do not run the base skill's
environment check as a gate before starting this walk; Steps 1-4 below
are this skill's own, more granular equivalent (Node, jf CLI install,
connection, credentials) purpose-built for the "nothing works yet" case.JFROG_CLI_USER_AGENT, unlike the
base skill's invariant — see runJf() in scripts/lib/jf.mjs for why
(telemetry-only impact).The user does not need to see the checklist you are walking, but does need to see what actually happened. Run the detectors silently, capture their output for your own reasoning, and surface only what the user needs to know or act on:
AskUserQuestion or plain-text prompt — e.g. explaining that
unresolved wasn't "server", or that candidatesWithNames had two
or more entries, so this is "the generic ask using the first two
candidates." That reasoning (in server-picker.md, project-picker.md,
and the other reference docs' branch tables) is written for you to
follow silently, not to summarize out loud — the field names in it are
never user-facing. The only output the user sees at an ask point is
the prompt itself.Instead:
The rest of this file documents the flow for you (the model), not for the user.
Every detector command shown below signals red/ask states via a
non-zero exit code, by design — append ; rc=$?; true when invoking
any of them. rc=$? is not optional: every Step's branch table
below keys off the exit code, and a bare ; true throws it away, so
every red and ask silently reads as green. Read
references/script-invocation.md in full before running any command
in this walk — the exact pattern and why it's required, not optional
background.
Follow this flow literally. Every decision node is covered by a
detector or fix script below; every user-facing prompt uses the exact
wording documented in the corresponding step. Do not reorder, do not
skip, do not narrate the diagram to the user. Read
references/flow-diagram.md for the full flowchart before starting a
walk — the same logic as the Steps below, drawn as a map.
node --version / npx --version directlyjf) installed? — scripts/jfrog-detect-jf-cli.mjsjf connected to a server? — scripts/jfrog-detect-jf-config.mjsscripts/jfrog-detect-server-ping.mjs [server-id]scripts/jfrog-detect-jfrog-mcp.mjs [server-id]scripts/jfrog-detect-project.mjs [server-id] [project-input]scripts/jfrog-detect-catalog-runtime.mjs [server-id]scripts/jfrog-add-claude-marketplace.mjs [server-id] [project-key], Claude Code onlyRun detectors in this exact order and stop at the first non-green
result — except Step 5 going red/error (see Step 5), Step 6 hitting
its one-retry cap (see Step 6), Step 7's "not entitled" and "catalog
unreachable" outcomes (see Step 7), and Step 8 entirely (see Step 8),
all four non-blocking. Step
1 has no script — a Node script can't verify Node exists — so every
step after it is written in Node and can assume Node is present. The
JPD URL is read directly from
jf config; there is no separate
JFROG_PLATFORM_URL env var. The project key is asked every walk in
Step 6 (the state file at ~/.jfrog/setup.json may supply a
"reuse the current project?" hint); Step 7's catalog probe takes no
project argument — it only checks catalog reachability and entitlement
for the resolved server.
<server-id> for Steps 4-7Order (used by every detector that takes [server-id] — resolved
through the single shared scripts/jfrog-resolve-jf-server.mjs):
JF_SERVER_ID env var."isDefault": true in ~/.jfrog/jfrog-cli.conf.v6
— resolved automatically via scripts/jfrog-resolve-jf-server.mjs.candidates
list of the configured server IDs. Stop and read
references/server-picker.md in full — it has the exact
AskUserQuestion payload for showing the user the actual servers to
pick from; do not paraphrase or invent your own prompt. Never invent
a server, never rely on jf's own fallback.node --version; true
npx --version; true
No script — Node's own binary is the only thing that can answer
"is Node installed", so there's nothing a script would check that
these two commands don't already answer directly. Checked first
because every other script in this walk — including every other
detector — is a Node program. npx matters because the JFrog MCP
server (mcpServers.jfrog, Step 5) is launched via npx @jfrog/agent-guard — no npx means the MCP entry can't start,
regardless of everything else.
Read the output yourself, no JSON to parse:
command not found: node) → red:
Node.js (or npx) is not installed / the install is broken.node --version prints a version like v16.2.0 → parse the major
number yourself. < 18 → red: "Node.js <version> is too old —
jfrog-init requires Node ≥ 18."node --version ≥ 18 and npx --version succeeds → green →
proceed to Step 2.Never paste the raw shell output. Translate to plain English —
"npx is not installed" not `command not found`, "Node.js v16 is
too old" not the version string verbatim. The raw output is for your
reasoning, not for the user.
On red, stop and read references/node-install-prompt.md in full
before responding to the user. It has the exact AskUserQuestion
payload, the forbidden phrases, and the install commands — required
behavior, not optional background. Even on the install path there's no
detector script: a missing Node can't run a .mjs installer, so the
install is a bash/PowerShell command the model runs directly.
node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-jf-cli.mjs"; rc=$?; true
reason: "missing" → jf not found on PATH → stop
and read references/jf-cli-install-prompt.md in full — required
behavior, not optional background.reason: "broken" → jf is on PATH but hung or
failed to run → stop and read references/jf-cli-install-prompt.md
in full — it has a separate payload for this case; required
behavior, not optional background.reason: "outdated" → jf installed but below the
required minimum version → stop and read
references/jf-cli-update-prompt.md in full — required behavior,
not optional background.Read references/jf-cli-install-internals.md for the full plan
A/B/C breakdown — why this walk uses npm install -g jfrog-cli-v2-jf
instead of the base skill's OS-specific install docs, and how the
fallback to a checksum-verified direct binary download works.
jf connected to a server?node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-jf-config.mjs"; rc=$?; true
Checked here (right after installing jf) so the JFrog CLI is
finished — install + auth — before the walk moves on to any other
prereqs. Keeps the "get jf working" story in one contiguous block
from the user's point of view.
This step does not pick or validate any specific server — it only
checks that jf config show returns at least one configured server,
regardless of how many there are or whether one is marked isDefault.
If multiple servers are configured with none marked default, that
ambiguity is surfaced starting at Step 4, not here — see "Resolving
<server-id> for Steps 4-7" above.
jf is installed but not connected to any
server. Stop and read references/jf-config-auth-picker.md in
full before responding to the user — the Step 3 section has the
exact web-login-vs-token AskUserQuestion, this skill's own local
web-login script copies (no cross-skill call into the base jfrog
skill), and the token command template — required behavior, not
optional background.node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-server-ping.mjs" "[server-id]"; rc=$?; true
Stop and read references/jf-config-auth-picker.md's "Step 4's full
branch table" section in full — the two sub-checks and the required
exit-code branches (credentials-only fix on Exit 1, Exit 2 still
blocks) — required behavior, not optional background.
node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-jfrog-mcp.mjs" "[server-id]"; rc=$?; true
Pass the same <server-id> already resolved for Step 4 (empty string
if Step 4 resolved silently via default/single-server) — this reuses
it for the placeholder fix instead of re-resolving from scratch.
Read-only against the JFrog plugin's own mcp.json — with one
exception: automatic placeholder substitution of an unresolved
${JFROG_PLATFORM_URL} / ${JFROG_URL} with the real JPD URL from
jf config.
Stop and read references/mcp-plugin-config.md in full — exactly
how the substitution works, the per-harness plugin-config paths, and
the required exit-code branches (Exit 1/3 non-blocking, Exit 2 the one
outcome that still blocks) — required behavior, not optional
background.
node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-project.mjs" "[server-id]" "[project-input]"; rc=$?; true
State reuse across walks. Before asking the user for a project,
stop and read references/project-state-reuse.md in full — it has
the exact "reuse <KEY>?" AskUserQuestion and the jpdUrl-drift check
this step requires, not optional background.
Where the project list comes from. jfrog-detect-project.mjs fetches
GET <JPD>/access/api/v1/projects (the
GetProjectsList
endpoint, authenticated with credentials from jf config export) once
per walk and caches it in memory for a short TTL (lib/project-cache.mjs)
— the interactive picker re-invokes this script once per user attempt,
and re-enumerating on every typed guess would be wasted network traffic.
This is the list every "enumerated project list" / candidatesWithNames
reference below draws from.
Name-or-key input. The user answers with either the project's
canonical key OR its display name — whichever is easier for them.
jfrog-detect-project.mjs resolves it against the enumerated project
list (exact key, exact name, then progressively fuzzier tiers — see
references/project-matching.md for the exact algorithm), confirms
existence, and emits the canonical key on green in the JSON
resolvedKey field. An ambiguous input exits red with candidates
listing the tied keys.
Picking a project, interactively. Whenever the detector needs the
user to choose — no input was passed, the typed input didn't match
anything (404), or it matched more than one project (ambiguous) —
stop and read references/project-picker.md in full before
responding to the user. It has the exact AskUserQuestion payload
shapes for each case (a 404 with close suggestions, an ambiguous or
missing input, and the no-AskUserQuestion plain-text fallback) and
the forbidden-phrasing rules for each — this is required behavior for
the step, not optional background.
Stop and read references/project-resolution-branches.md in full
for exactly how to branch on the detector's exit code (green / ask /
red with the one-retry cap / error) — required behavior, not optional
background.
node "${CLAUDE_SKILL_DIR}/scripts/jfrog-detect-catalog-runtime.mjs" "[server-id]"; rc=$?; true
Stop and read references/catalog-runtime-branches.md in full —
the two sub-checks (anonymous reachability, authenticated entitlement)
and the required exit-code branches (Exit 1 "not hosted/unreachable"
and Exit 4 "not entitled" are both non-blocking; Exit 2 still blocks) —
required behavior, not optional background.
Two preconditions, in this order. Step 7 must have been green — the
marketplace is served by the same AI Catalog that Step 7 probes, so
after a non-blocking red there (unreachable, or not entitled) there is
nothing to register. Then, Claude Code only — check the current
harness by reusing detectHarness() from
scripts/jfrog-resolve-mcp-config.mjs (the same export Step 5 already
uses), e.g.
node -e "import('${CLAUDE_SKILL_DIR}/scripts/jfrog-resolve-mcp-config.mjs').then(function(m){console.log(m.detectHarness())})".
If either precondition fails, skip this step silently — never run
the script below, no AskUserQuestion, no note anywhere, not even in
the Final Summary. Treat it exactly as if Step 8 didn't exist for this
walk.
Otherwise run:
node "${CLAUDE_SKILL_DIR}/scripts/jfrog-add-claude-marketplace.mjs" "[server-id]" "[project-key]"; rc=$?; true
Pass the same <server-id> already resolved for Step 4 (empty string
if Step 4 resolved silently via default/single-server), then Step 6's
canonical project key, or an empty string if Step 6 resolved none.
Stop and read references/marketplace-setup.md in full before
acting on the exit code — required behavior, not optional
background.
Successfully added marketplace: <marketplace-name> — extract
<marketplace-name> for the Final Summary's trailing line.Persist the walk's state before rendering any outcome below. Whenever Steps 1-4 are green (regardless of what Step 5/6/7 reported), run:
node "${CLAUDE_SKILL_DIR}/scripts/jfrog-state-file.mjs" set "<server-id>" "<jpdUrl>" "<project-key>"; rc=$?; true
using the server-id resolved earlier in this walk, Step 4's own
jpdUrl field (present on its green JSON result), and Step 6's project
key — its resolvedKey on green, or "" if Step 6 never resolved one
(ambiguous input, 404, 403, or the one-retry cap was hit). This is the
only thing that writes ~/.jfrog/setup.json when the walk is followed
step-by-step; it's the same file Step 6's "reuse <KEY>?" prompt
(project-state-reuse.md) reads on a future walk, so skipping this call
means that prompt has nothing to offer next time. Skip it only if Steps
1-4 themselves didn't all pass — there's nothing resolved yet to
persist. (Running the whole walk via jfrog-detect-all.mjs instead —
see "Running everything at once" below — does this same write itself;
don't call both.)
Give the user a short recap, not the raw checklist. See "Customer-facing output" above — no step numbers, no raw JSON. Render a short, emoji-based checklist, not a prose paragraph or a five-line plain-text list. Three grouped lines cover all five checks:
jf installed and connected to a
server). Always fully resolved here — this checklist only renders
once Steps 1-4 all passed (see "Anything else red" below for the
alternative).Skip Node.js (Step 1) — implementation detail, not user-facing.
Rules for the checklist:
Do not use the word "done" anywhere in it.
Keep those checks in exactly these three grouped lines — never expand back out to five.
All three groups fully resolved → use this exact format, verbatim:
✨ JFrog initialization complete! ✅ JF CLI & Config ✅ JFrog MCP Plugin ✅ Project & AI Catalog
A group with something outstanding gets ⚠️ instead of ✅, plus a short fact after an em dash:
✨ JFrog initialization complete! ✅ JF CLI & Config ⚠️ JFrog MCP Plugin — not configured ✅ Project & AI Catalog
For the merged Project & AI Catalog line, if only one of the two
is outstanding name just that one; if both are, separate them with a
semicolon: ⚠️ Project & AI Catalog — project not set up yet; catalog access not entitled.
Step 8 gets a fourth checklist line, but only when it ran — nothing appears when it was skipped:
Success — ✅ JFrog Marketplace, plus this trailing sentence
after the checklist block, in this exact wording:
Added the JFrog marketplace
<marketplace-name>to Claude Code. Browse available plugins with/plugins, or install directly withclaude plugin install <plugin>@<marketplace-name>
Red — ⚠️ JFrog Marketplace — not registered, and no trailing
sentence.
Never phrase a ⚠️ line as a failure or as something the user needs to fix before continuing — all of them are non-blocking by design. The short fact after the em dash is the same underlying cause this skill has always surfaced, just worded without "pending":
not configured.
If the user asks why or how to fix it, that's when the specific cause
from Step 5's detail comes in — either run
jfrog-reinstall-jfrog-plugin.mjs (see Step 5) for the per-harness
reinstall remedy, or point at resolving jf config, matching
whichever cause Step 5 actually reported.project not set up yet. If the user asks, mention they can pick one whenever they're
ready. The server/JPD are still recorded to the state file either way
(see the persistence step at the top of this section); a project
picked in an earlier walk, if any, is left as-is rather than cleared.catalog access not entitled. If the user asks for the fix: ask your JFrog admin for the
"AI Catalog Read" role to browse or install MCPs from the catalog.catalog not reachable on this JPD. No fix instruction; there may be
nothing to fix (this JPD may simply not host the AI Catalog).jf CLI installed, jf config connected, a project resolved in Step 6, an MCP placeholder
substituted in Step 5, etc.): still the same checklist — the action
itself isn't called out per-line, ✅ is ✅ regardless of whether it
needed fixing this walk.Read references/batch-walk.md in full for jfrog-detect-all.mjs's
exact semantics — the non-blocking exceptions, the JSON summary
fields, and the state-file write behavior.
JF_PROJECT or any shell
profile. Step 6 asks every walk and threads the pick forward as a
positional argument only — nothing about project selection ever
touches a shell profile. (Two other, unrelated things in this walk
do: Step 1's nvm-based Node install, and Step 2's Plan C fallback
when npm itself isn't usable — both append one PATH line to the
user's shell rc file, disclosed up front in the install consent
prompts, see node-install-prompt.md / jf-cli-install-prompt.md.
Plans A/B of Step 2 — the common case — don't touch a shell profile
at all, relying on npm's own global bin directory instead.)jf's own
process (jf rt ping); Steps 6 and 7 extract it from jf config export only in memory, for one fetch call. Step 3/4's token-based
jf config path (see references/jf-config-auth-picker.md) never
touches this skill or the model at all — the user runs that command
themselves. Step 8 is the one deliberate exception — it writes
the token to ~/.netrc; see references/marketplace-setup.md./jfrog-init — checklistAt a glance invariants:
; rc=$?; true — never a bare
; trueAskUserQuestion before auto-installing Node (Step 1) or jf
(Step 2); picker for web-login vs. token (Step 3/4); picker for
project selection (Step 6)<server-id> for Steps 4-8 comes only from the shared resolver —
never invented, never jf's own fallbackjfrog-state-file.mjs set <server-id> <jpdUrl> <project-key> before rendering the final summary~/.netrc write../jfrog/SKILL.md for context; do not run its
environment check as a gate before this walk