npm - @prismer/runtime - Versions diffs - 2.0.8 → 2.2.63 - Mend

@prismer/runtime 2.0.8 → 2.2.63

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (633) hide show

package/built-in-skills/memory-curation/SKILL.md DELETED Viewed

@@ -1,135 +0,0 @@
----
-name: memory-curation
-description: |
-  When you have read / processed a workspace asset in this session and learned something
-  durable about it, write a memory page so future sessions benefit. Maintain the workspace
-  wiki's hierarchical structure as it grows.
-applies_to: [hermes, claude-code, openclaw, codex]
-version: 1
----
-# Memory Curation Skill
-You have access to a workspace memory layer. Every workspace asset (file uploaded to this
-workspace) is **indexed by metadata only** — filename, mime, size, optional description,
-timestamps. The system does **not** pre-process file contents.
-To inspect assets, use bounded asset tools:
-- `prismer.asset.search` to find candidate files
-- `prismer.asset.describe` before reading bytes
-- `prismer.asset.read` for explicit byte ranges only
-Do not claim to have read an asset unless one of these tool calls succeeded.
-Your job: when you actually open / read / analyze an asset and learn something durable
-about it, **record what you learned** so future sessions don't repeat the work.
-## When to write a memory page
-Write a memory page after handling an asset if and only if **all** of these are true:
-1. You actually read the asset content (not just listed it).
-2. You produced an analysis, decision, or summary that is non-trivial — not "this file is a
-   CSV with 1000 rows" but "this CSV is Q4 sales data with revenue collapse in region APAC".
-3. The conclusion is **durable** — it will still matter weeks from now.
-4. The conclusion is **not derivable** from the asset metadata alone or from re-reading
-   the asset directly.
-Do **not** write a memory page for:
-- Files you only listed / saw in a directory listing
-- Trivial summaries ("this is a PDF about marketing")
-- Conversation context that belongs in the session, not in long-term memory
-- Process artifacts: build logs, temporary downloads, cache files, scratch outputs
-- Anything the user explicitly asked you not to remember
-## What to write
-Format: short Markdown page (typical 200-1000 words). Required structure:
-```markdown
-# <Short descriptive title>
-**Source:** [original-filename.ext](prismer://workspace/<wid>/asset/<contentHash>)
-**Why this matters:** one sentence explaining the durable conclusion.
-<body — your actual analysis / decision / summary>
-## Provenance
-- Session: <session id or date>
-- Tools used: <which tools/skills you ran on this asset>
-```
-Use `prismer://` URIs for any cross-reference to other assets, memory pages, tasks, etc.
-This is the wiki link form — agents in future sessions navigate by following these.
-## Where to put it
-Path convention:
-```
-memory/<topic>/<source-slug>.md         ← leaf page about one source
-memory/<topic>/<source-slug>/<aspect>.md ← finer-grained aspect of one source
-```
-`<topic>` is your judgment: `datasets`, `customer-research`, `architecture`, etc. If you
-are uncertain, default to the asset's content kind (`datasets/` for tabular, `documents/`
-for text-heavy, etc.). The Dream consolidation phase will reorganize sub-optimal placements.
-## Index hygiene (important)
-The workspace has a top-level `INDEX.md` that points to memory pages. **Do not write
-directly into `INDEX.md`** — the system maintains it. Just write your page at the right
-path and the indexer will pick it up.
-If you notice the top-level INDEX already has >200 entries, **do not create a fresh
-top-level page**. Instead nest under an existing sub-index (e.g. `memory/datasets/INDEX.md`
-if it exists). The Dream phase will rebalance the hierarchy when it ticks.
-## Hub merging
-If you write a page about a topic and there is already a hub page for the same topic
-(check via `memory_search` before writing), **append to or update the existing hub**
-rather than creating a sibling. Hub merging at runtime keeps the wiki coherent and
-reduces work for the Dream phase later.
-## Deduplication
-Before writing, run `memory_search` with terms drawn from the asset content. If a memory
-page already contains the same conclusion, do nothing. If a memory page contains a
-**different** conclusion about the same source, do not silently overwrite — append a note
-or update with an explicit reason.
-## What the Dream phase will do for you
-You do not need to be perfect. The Dream phase runs periodically (typically idle ≥ 5
-minutes or session boundaries) and will:
-- Merge duplicates you missed
-- Cluster N pages about one topic into a new sub-hub
-- Mark stale pages (when the source asset was deleted or the conclusion contradicts a
-  newer page)
-- Prune low-signal pages that were never recalled and never linked
-- Enforce top-level INDEX size invariants
-This means: if you are uncertain whether a memory is worth writing, **err on the side of
-not writing**. Dream cannot reconstruct missing knowledge, but Dream can prune excess
-writes.
-## Anti-patterns
-- ❌ Writing one memory page per asset by default. Most assets are noise; only a fraction
-  yield durable knowledge.
-- ❌ Writing memory pages with content equal to a paste of the asset itself. Memory is
-  for **conclusions**, not raw content (the raw is already in the asset).
-- ❌ Writing memory pages for files the user said to ignore.
-- ❌ Editing `INDEX.md` directly.
-- ❌ Creating new top-level INDEX entries when one already exists for the topic.
-## Anti-pattern detector (rhetorical check)
-Before saving, ask yourself: "If I encounter this memory page 6 months from now in a
-different session, will it tell me something that re-reading the source asset would not?"
-If the answer is no, do not save.

package/built-in-skills/skill-authoring/SKILL.md DELETED Viewed

@@ -1,124 +0,0 @@
----
-name: skill-authoring
-description: Generate Prismer-compliant skill drafts from user intent, documentation URLs, existing code, or service endpoints. Use whenever the user says "make this a skill", "package this workflow", "create a skill for X", or wants to capture a repeatable workflow into a reusable artifact. Outputs a multi-file manifest (SKILL.md + skill.json + optional scripts/refs/assets) and persists as status=draft via cloud endpoint. Does NOT publish — that is a separate lifecycle step the user reviews via Studio Authoring.
-license: MIT
-compatibility:
-  - prismer-sdk
-  - hermes
-  - openclaw
-  - claude-code
-  - codex
----
-# Skill Authoring (Prismer)
-You generate Prismer-standard skill drafts. You do NOT publish — that's a separate
-lifecycle step the user reviews via Studio Authoring (`/evolution → Studio → Authoring`).
-## Pipeline
-1. **Capture intent** — clarify slug / name / trigger phrases / input-output / source kind.
-   The four valid source kinds are:
-   - `inline-spec`     — extract from the active conversation context
-   - `doc-url`         — fetch markdown / OpenAPI / README from a URL
-   - `code-source`     — grep existing repo paths and bundle matched snippets
-   - `service-endpoint`— probe an HTTP / MCP server's tool/endpoint catalog
-2. **Fetch sources** — based on source kind:
-   - `inline-spec`: extract directly from the chat history; do not call out
-   - `doc-url`:        `cloud load <url>` → returns compressed reference text
-                        (positional URL arg — there is NO `--url` flag)
-   - `code-source`:    `cloud code grep <pattern> --repo <abs-path>` → returns
-                        matched snippets to bundle as `references/*`
-   - `service-endpoint`: `cloud service introspect <url>` → returns tool /
-                          endpoint list to translate into a SKILL.md workflow
-3. **Compose manifest v1** — write:
-   - `SKILL.md` (frontmatter `name`/`description`/`license`/`compatibility` +
-     a body that follows Anthropic skill-creator's progressive-disclosure pattern)
-   - `skill.json` (structured `SkillPackageSpec` — see release201/07 §2.6)
-   - Optional `scripts/`, `references/`, `assets/`
-4. **Submit draft** — `cloud skill draft create --slug <slug> --manifest <path>`
-   which calls `POST /api/im/skills/draft`. The cloud server runs the 7 validation
-   gates and returns `{ id, slug, manifestRevision, reviewTaskId }` on success.
-5. **Report draft id** — surface the draft id back to the user; do NOT auto-publish.
-## Scenario 1 — API doc / URL → skill + callable script + auto tests
-This is the canonical, quantifiable path (release201/24). When the user gives
-you an API document, an OpenAPI/Swagger spec, or a doc URL and asks to "make
-this a skill", produce a draft that can be VERIFIED by real dispatch — not just
-prose. Generate ALL of:
-1. **`SKILL.md`** — workflow describing when/how to call the API, with the
-   concrete endpoints, auth, and the script entrypoint.
-2. **`scripts/call-api.*`** — a real, runnable script (Node `.ts`/`.mjs`, or
-   `.sh` using curl) that performs the API call. Read inputs from argv / env;
-   print the result to stdout. This is what the eval session actually exercises.
-3. **`skill.json`** — the `SkillPackageSpec` with:
-   - `runtime.kind = 'inline-script'` (or `'http-endpoint'`), `runtime.requires`
-     declaring `bins`/`env` the script needs (e.g. `env: ["EXAMPLE_API_KEY"]`).
-   - `inputs` / `outputs` describing the call contract.
-   - **`sampleTasks[]`** — at least 2 concrete tasks. EACH MUST have
-     `acceptanceCriteria[]` written as substrings/regex that the dispatch
-     OUTPUT must contain (e.g. `"\"status\":\\s*200"`, `"results"`). These ARE
-     the auto-generated mock tests — the daemon scorer matches them against the
-     real dispatch output (release201/24 §2.1). A sampleTask with no
-     acceptanceCriteria is scored `inconclusive` (NOT a pass), so always write
-     them.
-4. **`references/<api>.md`** — the compressed `cloud load <url>` /
-   `cloud service introspect <url>` output, so the workflow is grounded.
-Quantifiable acceptance: the skill is "good" when its eval run pass-rate (real
-dispatch of each sampleTask, scored against acceptanceCriteria) meets the
-lifecycle threshold. Write criteria that are tight enough to catch a broken
-call but not so tight they depend on volatile data.
-> Derive acceptanceCriteria from the spec: required response fields, status
-> codes, schema keys. If the spec lacks examples, add a criterion asserting the
-> script exits 0 and emits non-empty JSON, plus a field-presence check.
-## Boundaries
-- DO NOT call `POST /api/im/skills` directly — it bypasses draft state
-- DO NOT modify existing non-draft skills (use `skill-creator` reference if the
-  user asks "edit existing skill")
-- DO NOT trigger publish / share — the user reviews drafts in Studio Authoring
-- Reference Anthropic skill-creator at `/built-in-skills/skill-creator/SKILL.md`
-  for "how to write a good SKILL.md" patterns (progressive disclosure, allowed
-  tool surface, etc.). Treat it as documentation, not as an executor.
-## Quality gates (self-check before submit)
-The cloud server runs the 7 gates below at `createDraft` time and rejects with
-HTTP 400 on any blocking failure. Run the same checks locally before POSTing:
-| Gate           | Check                                                            | Blocking |
-|----------------|------------------------------------------------------------------|----------|
-| `manifest`     | files[] complete; merkle root reproducible                       | yes      |
-| `frontmatter`  | `name` matches `^[a-z][a-z0-9-]*$`; description ≥ 50 chars       | yes      |
-| `package`      | SKILL.md is files[0]; skill.json is files[1]                     | yes      |
-| `requires`     | runtime.requires declares env/bins/python/node explicitly        | warn     |
-| `security`     | security.dataAccess non-empty; sensitive scopes require approval | yes      |
-| `sample`       | at least 1 sampleTask + 1 acceptance criterion                   | warn     |
-| `runtime`      | sandbox executes sample task                                     | deferred |
-- `name` matches `^[a-z][a-z0-9-]*$`
-- `description` ≥ 50 chars, contains trigger context ("Use when...")
-- SKILL.md body ≤ 500 lines (progressive disclosure)
-- All scripts/refs/assets paths exist in manifest files[] array
-- Merkle root computed correctly:
-  `sha256(join("\n", sorted(files, by=path).map(f => path + ":" + sha256)))`
-## Output contract
-After a successful submit, return to the user:
-```
-Draft submitted.
-  id:               <skill id>
-  slug:             <slug>
-  manifest revision <merkle>
-  review task:      <task id>  (capability=skill-review, assignee=workspace owner)
-  next step:        Open in Studio Authoring → review → promote to eval (release201/08)
-```
-Do NOT chain into install / publish; lifecycle is the workspace owner's call.

package/built-in-skills/web-artifacts-builder/scripts/shadcn-components.tar.gz DELETED Viewed

Binary file