chore: sync skills to v0.18.0

marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "jfrog",
       "description": "JFrog Platform integration with MCP, security skills, and supply-chain best practices",
-      "version": "1.0.7",
+      "version": "1.0.8",
       "source": "plugin",
       "categories": [
         "security",

plugin/skills/jfrog-ai-catalog-skills/SKILL.md

@@ -56,18 +56,15 @@ Pick the row matching the user's intent and read that reference file.
   same `<SID>` to Agent Guard as `--server "<SID>"` so it targets the same server
   as your `jf` calls. Agent Guard also reads `JFROG_URL` / `JF_URL` directly when
   set, so make sure the `<SID>` you resolved points at that same host.
-- **Resolve the project (`<PROJECT>`) only when needed, and always to a key.**
-  `<PROJECT>` must be the JFrog **project key**, not the display name. It is
-  required for `--list-skills`, `--list-skill-versions`, and
-  `--provision-skills-repository`. Take the value from `JF_PROJECT` or the user,
-  then resolve it to a key against the projects list (see *List all projects* in
-  the base `jfrog` skill's [`references/projects-api.md`](../jfrog/references/projects-api.md)):
-  ```bash
-  jf api '/access/api/v1/projects' --server-id "<SID>" \
-    | jq -r '.[] | select(.project_key=="<value>" or .display_name=="<value>") | .project_key'
-  ```
-  Use the printed key. If it prints nothing, ask the user for the key. Never
-  assume `default`, never invent one. Install, update, remove, and publishing to
+- **Resolve the project (`<PROJECT>`) only when needed.**
+  It is required for `--list-skills`, `--list-skill-versions`, and
+  `--provision-skills-repository`. Take it from `JF_PROJECT` or the user.
+  There is no non-admin way to look up or validate project keys (the
+  `/access/api/v1/projects` list endpoint needs admin), so you cannot
+  silently correct a display name to a key. If the value looks like a
+  display name (spaces, mixed case) rather than a short slug, ask the
+  user to confirm the project **key** specifically. Never assume
+  `default`, never invent one. Install, update, remove, and publishing to
   an explicit `--repo` are keyed by skill **name** and/or **repo**, not a
   project.
 

plugin/skills/jfrog-ai-catalog-skills/references/publishing-skills.md

@@ -137,6 +137,8 @@ template and do not run `jf skills publish` until the user agrees:
 
   > Publishing skill `<slug>` uploads it to repository `<repo>` on server `<SID>`. Do you want to publish it?
 
+Never combine this final confirmation step with the previous signing step into one prompt.
+
 If the user says no or names a different repo/name, use that instead and confirm
 again. Only proceed to *Publish* after an explicit "yes".
 

plugin/skills/jfrog/SKILL.md

@@ -18,7 +18,7 @@ compatibility: >-
   Requires jq on PATH.
 metadata:
   role: base
-  version: "0.16.0"
+  version: "0.18.0"
 ---
 
 # JFrog Skill
@@ -93,12 +93,11 @@ bash <skill_path>/scripts/check-environment.sh <model-slug>
 # 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`.
+Pass your own model slug, lowercased, with version (e.g. `opus-4.7`,
+`gpt-5.6-sol`, `gemini-2.5-pro`, `composer-2-fast`). Examples, not an
+allowlist — emit a new/unlisted name verbatim, not `unknown`. Not
+harness/role (`subagent`, `agent`) or bare family (`claude`, `gpt`);
+subagents inherit the parent's slug. `unknown` only if truly unidentifiable.
 
 ### Export `JFROG_CLI_USER_AGENT` once per bash invocation
 
@@ -112,9 +111,12 @@ 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.
+on every line). This is a **session-global invariant**: it applies to *every*
+`jf` invocation in the session, including `jf` calls you make while following
+any workflow skill that builds on this base skill. 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 |
 |------|---------|