@rhize/skill-forge 0.6.0 → 0.7.0

package/dist/ingest-prompt.md

@@ -51,7 +51,8 @@ is a JSON object shaped like:
         "prompts": ["statically-extracted prompt names"],
         "transport": "stdio | http (optional, best-effort)",
         "declaredConfidence": "high | partial | none"
-      }
+      },
+      "origin": "evolve (optional — absent means a normal add-sourced entry)"
     }
   ]
 }
@@ -75,6 +76,18 @@ Check the entry's `artifactType` before continuing:
   `mcp.json`, an MCP-server-shaped `package.json`, or an extracted npm tarball with no
   `SKILL.md` is an MCP server.)
 
+Also check `origin` (since skill-forge v0.7): if it's `"evolve"`, this skill was
+**self-evolved** via `skill-forge evolve` (SkillOpt-Sleep), not installed from an external
+source — `source`/`installedPath` both point at the skill's own (already-live) directory,
+and `gate` already reflects a re-gate of the *evolved* content, run at adopt time. §2–7
+still apply, but read them as reviewing an evolution rather than vetting an outsider: skip
+license triage (§4) and the overlap-driven verb table in §3 (there's nothing external to
+compare against) and instead judge whether the change itself is worth keeping — does it
+actually improve the skill, or should it be reverted? DEFER (keep the evolution as adopted)
+and REJECT (revert it — restore the pre-evolution `SKILL.md`/`CLAUDE.md` yourself, since
+skill-forge does not) are the two verbs that make sense here; ABSORB/FORK/WATCH don't apply
+to a skill evolving into itself.
+
 ---
 
 ## If artifactType is `"mcp"`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rhize/skill-forge",
-  "version": "0.6.0",
+  "version": "0.7.0",
   "publishConfig": {
     "access": "public"
   },