@rhize/skill-forge 0.4.0 → 0.6.0

package/dist/ingest-prompt.md

@@ -1,9 +1,11 @@
 # Skill Ingestion Pass
 
-You are running the deep decide/absorb pass on a skill that has just cleared the
-`skill-forge` quarantine → profile → safety scan → overlap-analysis gate. The gate already
-answered "is this safe to install?" — your job is the harder question: "given everything
-already in this skill set, what should actually be *done* with it?"
+You are running the deep decide/absorb pass on a candidate — a skill, or (since
+skill-forge v0.6) an MCP server — that has just cleared the `skill-forge` quarantine →
+profile → safety scan → overlap-analysis gate. The gate already answered "is this safe to
+install?" — your job is the harder question: "given everything already configured, what
+should actually be *done* with it?" §1 below tells you which branch to follow depending on
+the candidate's type.
 
 You may be any coding agent (Claude Code, Codex CLI, Cursor, Windsurf, OpenCode, Gemini
 CLI, or another). Nothing below assumes a specific one. Use whatever file-reading,
@@ -29,7 +31,7 @@ is a JSON object shaped like:
   "entries": [
     {
       "id": "a1b2c3d4",
-      "source": "the original slug / git URL / local path the skill was installed from",
+      "source": "the original slug / git URL / local path the skill or server was installed from",
       "sourceType": "skills.sh | git | local",
       "installedPath": "final path after promote, or null if only held in quarantine",
       "quarantinePath": "path to the quarantine sandbox this entry was gated from",
@@ -37,11 +39,19 @@ is a JSON object shaped like:
         "license": "detected license string, or null",
         "safetyVerdict": "pass | warn | block",
         "safetyFindings": ["human-readable safety findings, one per string"],
-        "overlapTop": [{ "skill": "nearest-existing-skill-name", "score": 0.0 }],
+        "overlapTop": [{ "skill": "nearest-existing-skill-or-server-name", "score": 0.0 }],
         "suggestedVerb": "DEFER | ABSORB | FORK | REJECT | WATCH | null"
       },
       "status": "pending | ingested | dismissed",
-      "createdAt": "ISO-8601 timestamp"
+      "createdAt": "ISO-8601 timestamp",
+      "artifactType": "skill | mcp (optional — absent means 'skill')",
+      "capabilities": {
+        "tools": ["statically-extracted tool names — mcp entries only, optional field"],
+        "resources": ["statically-extracted resource templates/URIs"],
+        "prompts": ["statically-extracted prompt names"],
+        "transport": "stdio | http (optional, best-effort)",
+        "declaredConfidence": "high | partial | none"
+      }
     }
   ]
 }
@@ -52,9 +62,92 @@ Pick the entry with `"status": "pending"` whose `installedPath` (or `quarantineP
 user and ask which to process, or work through them one at a time — don't silently drain
 the whole queue.
 
-If there is no matching queue entry at all (you were pointed straight at a skill directory
-with no CLI queue involved), that's fine — do the same evaluation, just skip the "close the
-entry" step at the end since there's nothing to close.
+If there is no matching queue entry at all (you were pointed straight at a skill or server
+directory with no CLI queue involved), that's fine — do the same evaluation, just skip the
+"close the entry" step at the end since there's nothing to close.
+
+Check the entry's `artifactType` before continuing:
+
+- **`"skill"` or absent** — this is a skill candidate; continue with §2–7 below.
+- **`"mcp"`** — this is an MCP server candidate; skip §2–7 and follow **"If artifactType is
+  `mcp`"** immediately below instead. (If you have no queue entry to check, infer it: a
+  directory with a `SKILL.md` is a skill; a directory/package with an `.mcp.json`/
+  `mcp.json`, an MCP-server-shaped `package.json`, or an extracted npm tarball with no
+  `SKILL.md` is an MCP server.)
+
+---
+
+## If artifactType is `"mcp"`
+
+The target is an MCP **server**, not a skill — the decide/act/record steps below replace
+§2–7 for this entry. The five-verb matrix, license triage, and record/close mechanics are
+the same ones §2–7 use for skills; only what you're evaluating and where you act changes.
+
+### Gather context — statically only, always
+
+- **Read the entry's `capabilities` field** (introduced in skill-forge v0.6):
+  `{ tools, resources, prompts, transport?, declaredConfidence }`, a **statically-extracted**
+  profile — tool/resource/prompt names parsed from the candidate's `package.json`, any
+  shipped `.mcp.json`/manifest, and MCP SDK source-text patterns (e.g.
+  `server.tool("name", ...)`, `setRequestHandler(ListToolsRequestSchema, ...)`,
+  `server.resource(...)`, `server.prompt(...)`). It is never derived by running the server.
+- **Do not run or install the server to inspect it.** No `npm install`, no executing its
+  binary or entry point, no invoking its tools to see what they do. If `capabilities` is
+  absent, empty, or `declaredConfidence` is `"partial"`/`"none"`, read more source
+  statically yourself (package.json, README, exported tool/resource/prompt registrations)
+  — never execute anything to fill the gap. This is a hard security invariant, not a style
+  preference: it mirrors the CLI's own static-only extraction.
+- **Reuse `gate.safetyVerdict` / `gate.safetyFindings`** — the MCP safety scan (unpinned
+  `npx`, inline credentials, dangerous launch flags, broad filesystem args) already ran;
+  don't re-scan.
+- **Judge redundancy against already-configured servers** using `gate.overlapTop` (nearest
+  server-name/package matches) plus your own read of the target mcp config file for
+  capability overlap: do any already-configured servers expose the same or near-identical
+  tools/resources as this candidate's `capabilities`?
+
+### Decide — same five verbs, applied to a server
+
+Weigh the same dimensions as skills (overlap, quality, license, maintenance, fit), reading
+"quality" as `declaredConfidence` plus the safety verdict, and "overlap" as
+tool/resource/prompt redundancy with an already-configured server:
+
+- **DEFER** — genuinely new capability, cleanly scoped; keep the promoted config entry
+  exactly as installed.
+- **ABSORB** — overlaps partially with something already configured but adds real
+  capability; keep it, but **tighten its config first** — trim `env` to only the variables
+  its declared tools actually need, narrow broad `args` (e.g. a filesystem root), and
+  record which values you removed or narrowed.
+- **FORK** — worth keeping but its default config doesn't fit house convention (wrong
+  scope, wrong invocation style, name collision); adjust the config to fit rather than
+  installing it verbatim.
+- **REJECT** — duplicates an already-configured server's capability, fails the license
+  triage, or `gate.safetyVerdict` is `"block"`; **remove the server entry** from the
+  target mcp config with a documented edit (state which entry you removed and why).
+- **WATCH** — promising but not ready to trust (e.g. `declaredConfidence: "none"` and you
+  can't determine enough statically), or upstream looks immature; leave the config as-is
+  (or don't promote it) and leave a WATCH note — don't silently drop it.
+
+License triage (§4 below) applies unchanged: classify `gate.license` before committing to
+ABSORB or FORK, and never ABSORB/FORK on a copyleft, none-stated, or restrictive license
+without the user's explicit sign-off.
+
+### Act
+
+Apply the config change (or deliberate non-change) implied by your verb directly to the
+promoted mcp config file — the file the CLI's promote step wrote to (see `installedPath`
+on the entry, or its `--mcp-target` resolution). Edit only the `mcpServers`/`servers` entry
+for this candidate; never touch other servers' entries in the same file. Verify the file
+still parses as valid JSON and the kept/tightened entry's `command`/`args`/`env` shape is
+still well-formed — you're validating the *config*, not spawning the server.
+
+### Record and close the queue entry
+
+Record the same fields §6 asks for (candidate name/source, license class, verb chosen,
+what actually changed in the config, reasoning, "n/a" where nothing applies), then close
+the queue entry exactly as in §6's "Close the queue entry": set `status` to `"ingested"`
+once recorded, or `"dismissed"` if the user declined. Report back per §7.
+
+---
 
 ## 2. Gather context
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rhize/skill-forge",
-  "version": "0.4.0",
+  "version": "0.6.0",
   "publishConfig": {
     "access": "public"
   },
@@ -42,9 +42,12 @@
     "commander": "^12.1.0"
   },
   "devDependencies": {
-    "@types/node": "^22.10.5",
-    "tsup": "^8.3.5",
-    "typescript": "^5.7.3",
-    "vitest": "^2.1.8"
+    "@types/node": "^26.1.1",
+    "tsup": "^8.5.1",
+    "typescript": "^7.0.2",
+    "vitest": "^4.1.10"
+  },
+  "overrides": {
+    "esbuild": "0.28.1"
   }
 }