jfrog · davida-jfrog · Sep 9, 2026 · Sep 8, 2026
@@ -1,7 +1,7 @@
 {
   "name": "jfrog",
   "displayName": "JFrog Platform",
-  "version": "0.3.7",
+  "version": "0.3.8",
   "description": "Official JFrog plugin for Devin. Ships the JFrog skills bundle (platform ops, init, MCP management, AI Catalog, package safety, reference architecture, package-manager setup) and registers the JFrog Platform MCP server (remote HTTP + OAuth).",
   "author": {
     "name": "JFrog Ltd.",

@@ -1,6 +1,6 @@
 {
   "repo": "jfrog/jfrog-skills",
-  "pin": "v0.36.0",
+  "pin": "v0.37.0",
   "paths": [
     "skills"
   ]

@@ -2,12 +2,15 @@
 
 `node scripts/jfrog-detect-all.mjs [server-id] [project-key]` runs Steps 1–7
 in order and stops at the first non-green result — except Step 5 going
-red/error, Step 6 going red (ambiguous/404/403), and Step 7 going red
+red/error, Step 5b going red/error, Step 6 going red (ambiguous/404/403), and Step 7 going red
 in either of its two non-blocking shapes (exit 1: catalog not hosted /
 unreachable / 5xx, or exit 4: reachable but not entitled), all of which
 are non-blocking: Steps 1-4 passing is what "green" means here,
-and the MCP-plugin, project-resolution, and catalog-availability gaps
-are each reported as separate signals. This script makes exactly one
+and the MCP-plugin, MCP-auth, project-resolution, and catalog-availability
+gaps are each reported as separate signals. Step 5b itself only runs when
+Step 5 came back green **and** `detectHarness()` returns `opencode` — every
+other harness authenticates MCP tools through `jf config` credentials
+directly, so there's nothing for it to check. This script makes exactly one
 project-resolution attempt per invocation and has no way to tell a
 first attempt from a last one, so it always treats a Step 6 red as
 non-blocking — the interactive walk (see Step 6 in `SKILL.md`) is what
@@ -20,18 +23,26 @@ picked project as arg 2 — unless that `ask` carries `"unresolved":
 "server"`, in which case it's a server pick (see Step 6's branches) and
 the re-invocation picks server-id (arg 1) instead.
 
-Exit 0 = Steps 1-4 green (MCP configured or not, project resolved
-or not, catalog entitled or not); exit 1 = something needs fixing. The
-final JSON line adds `mcpConfigured: true|false`, `projectResolved:
+Exit 0 = Steps 1-4 green (MCP configured or not, MCP token present or not,
+MCP server enabled or not, project resolved or not, catalog entitled or
+not); exit 1 = something needs fixing. The final JSON line adds
+`mcpConfigured: true|false`, `mcpAuthed: "ok" | "missing" |
+"not_applicable"`, `mcpResponding: true|false`, `projectResolved:
 true|false`, and `catalogEntitled: true|false` so a caller can tell the
 exit-0 cases apart — plus `catalogReason: "unreachable" | "not_entitled"`
-whenever `catalogEntitled` is `false`, so the Final Summary can name the
-specific gap instead of a generic one. Writes the `~/.jfrog/setup.json`
-state-file hint whenever Steps 1-4 are green, **regardless of
-`projectResolved`, `mcpConfigured`, or `catalogEntitled`** — the server
-and JPD URL are worth remembering on their own, independent of whether
-a project got picked, the MCP plugin is wired up, or the AI Catalog is
-reachable/the user is entitled to it. An unresolved project is passed
+whenever `catalogEntitled` is `false`, and `mcpRespondingReason:
+"not_enabled" | "unreachable"` whenever `mcpResponding` is `false`, so the
+Final Summary can name the specific gap instead of a generic one.
+`mcpAuthed` is `"not_applicable"` on every harness but OpenCode — there is
+no gap to report where the check never runs, and a boolean there would
+conflate "no gap" with "not checked". Writes the
+`~/.jfrog/setup.json` state-file hint whenever Steps 1-4 are green,
+**regardless of `projectResolved`, `mcpConfigured`, `mcpAuthed`,
+`mcpResponding`, or `catalogEntitled`** — the server and JPD URL are worth
+remembering on their own, independent of whether a project got picked, the
+MCP plugin is wired up, its auth token is present, the MCP server is
+enabled on the JPD, or the AI Catalog is reachable/the user is entitled to
+it. An unresolved project is passed
 to `jfrog-state-file.mjs` as an empty key, which leaves any previously
 recorded `currentActiveProject` alone rather than erasing it (see
 `jfrog-state-file.mjs`); it's never written as a fresh, unvalidated

@@ -0,0 +1,96 @@
+# Final summary — recap rendering rules
+
+**Give the user a short recap, not the raw checklist.** See
+"Customer-facing output" in `SKILL.md` — 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 CLI & Config** — `jf` installed and connected to a server. Always
+  fully resolved here — this checklist only renders once every
+  prerequisite up through server connectivity has passed (see "Anything
+  else red" below for the alternative).
+- **JFrog MCP Plugin** — the MCP plugin check.
+- **Project & AI Catalog** — the project-resolution and AI-Catalog-access
+  checks, together.
+
+Skip the Node.js setup step — implementation detail, not user-facing.
+
+**Rules for the checklist:**
+1. Do **not** use the word "done" anywhere in it.
+2. Keep those checks in exactly these three grouped lines — never
+   expand back out to five.
+3. All three groups fully resolved → use this exact format, verbatim:
+
+   > ✨ **JFrog initialization complete!**
+   > ✅ JF CLI & Config
+   > ✅ JFrog MCP Plugin
+   > ✅ Project & AI Catalog
+
+4. 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`.
+
+5. **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 with
+     > `claude plugin install <plugin>@<marketplace-name>`
+
+   - **Red** — `⚠️ JFrog Marketplace — not registered`, and no trailing
+     sentence.
+
+**If the user asks why** (troubleshooting reference — not part of the render itself):
+
+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":
+
+- **Step 5 red/error (MCP plugin not configured):** `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.
+- **Step 5 MCP status** (only when the config check above is green) — the
+  **probe** decides, the only signal tied to *this* JPD:
+  - exit 4 → ⚠️ `not enabled on this JPD` (+ ask admin, docs from `detail`)
+  - exit 1 → ⚠️ `could not confirm it's enabled`
+  - exit 0 → MCP is on; check your session for JFrog MCP tools **on this JPD**
+    (same base URL, else they don't count): visible → ✅; else ⚠️ `enabled — sign
+    in to use it`, and offer sign-in **after the summary, never mid-walk**
+- **Step 5b red (OpenCode OAuth incomplete):** `not authenticated`. If
+  the user asks, that's when `opencode mcp auth jfrog` comes in.
+- **Step 6 hit its retry cap (no project resolved):** `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 `SKILL.md`'s Final summary
+  section); a project picked in an earlier walk, if any, is left as-is
+  rather than cleared.
+- **Step 7 returned exit 4 (not entitled):** `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.
+- **Step 7 returned exit 1 (catalog not hosted / unreachable):**
+  `catalog not reachable on this JPD`. No fix instruction; there may be
+  nothing to fix (this JPD may simply not host the AI Catalog).
+- **Something happened this walk** (Node.js/`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.
+- **Anything else red** (Steps 1-4 not all green): one or two sentences
+  naming what's blocking and what to do next, no checklist — there's
+  nothing to check off yet. Include the raw detector error line if it
+  helps debug, without the JSON wrapper.
@@ -68,7 +68,10 @@ flowchart TD
     ASKSRV5 --> S5
     S5 -->|missing/invalid/no entry, incl. substitution failure| F5["Note: reinstall or update the JFrog plugin, or resolve jf config (non-blocking)"]:::fixBox
     F5 --> S6
-    S5 -->|yes, valid url| S6
+    S5 -->|yes, valid url| S5R["5b. JFrog MCP server enabled on this JPD? (jfrog-detect-jfrog-mcp-responding.mjs, anonymous GET &lt;JPD&gt;/mcp — non-blocking)"]:::stepBox
+    S5R -->|not_enabled: ask admin / unreachable: couldn't confirm| F5R["Note: surface in Final Summary (non-blocking)"]:::fixBox
+    S5R -->|enabled: ✅ if signed in to this JPD, else offer sign-in AFTER Final Summary| S6
+    F5R --> S6
 
     S6["6. Project resolved?"]:::stepBox
     S6 -->|state file has current project| ASKREUSE["AskUserQuestion: reuse CURRENT or pick different"]:::fixBox

@@ -0,0 +1,72 @@
+# Operating rules: silent walk, exit codes, and flow
+
+## Customer-facing output
+
+**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:
+
+- **Do not** narrate step numbers ("Step 1…", "moving to Step 3…")
+  while the walk is in progress.
+- **Do not** paste detector JSON, exit codes, or shell command output
+  into the reply.
+- **Do not** narrate the branch-selection reasoning behind an
+  `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.
+- **Do not** narrate whether the `AskUserQuestion` tool is available in
+  the current harness before falling back to the plain-text prompt
+  (e.g. "the AskUserQuestion tool isn't available here, I'll present
+  this as a plain question instead"). If it isn't available, silently
+  use the plain-text fallback already documented for that ask point.
+- **Do not** announce that you're about to run the checklist, or name
+  which check comes first — not even generically ("I'll run the setup
+  checklist silently, starting with the JFrog CLI check" is itself a
+  violation: it names a step while claiming to be silent). The same
+  applies to reading reference docs: "I'll start by reading the flow
+  docs" is a preamble. Silently means no preamble message at all — not
+  before running commands, not before reading files. Say nothing until
+  you have something the user needs to act on (an ask, a failing result)
+  or the final summary.
+
+Instead:
+
+- **When everything passes**, give a short recap in the final summary
+  (see SKILL.md's "Final summary" section): a short, emoji-based checklist — JF CLI
+  & Config, JFrog MCP Plugin, Project & AI Catalog — so the user sees
+  the end state of every check at a glance, not raw step numbers and
+  not the Node.js check (an implementation detail, not user-facing).
+- **When something fails**, say *what's wrong in plain English* and
+  *what the user needs to do next*, in one or two sentences. Show the
+  exact command they need to run (they must see what they're
+  approving).
+- **On failure, the raw detector error line is fair game** to include
+  verbatim as a debugging aid — one line, without the JSON wrapper.
+
+SKILL.md documents the flow **for you (the model)**, not for the user.
+
+## Invoking scripts: exit codes are signal, not failure
+
+Every detector command shown in SKILL.md signals a failure or an ask 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
+in SKILL.md keys off the exit code, and a bare `; true` throws it away, so
+every failure and ask silently reads as success. **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.
+
+## Flow
+
+**Follow this flow literally.** Every decision node is covered by a
+detector or fix script in SKILL.md; 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 SKILL.md's Steps, drawn as a map.