@moxxy/cli 0.14.8 → 0.14.9

package/dist/skills/add-provider.md

@@ -21,6 +21,7 @@ allowed-tools:
   - provider_test
   - vault_status
   - vault_list
+  - web_fetch
 ---
 
 The user wants to add a new LLM provider to moxxy so they can switch to it later (`/provider <name>` or via `provider.name` in moxxy.config.ts). Walk them through these steps; be terse and pause for confirmation between gather → register → key.
@@ -36,7 +37,7 @@ If the vendor speaks a different protocol (Anthropic-style, Google Vertex, custo
 Ask the user, or infer from their request:
 
 - **Provider slug** — short lowercase identifier (e.g. `zai`, `deepseek`, `groq`, `openrouter`). This becomes the registry key, the canonical vault entry name (`<SLUG>_API_KEY`), and what the user types in `/provider <slug>`. Must match `[a-z][a-z0-9-]*`.
-- **API base URL** — the vendor's OpenAI-compatible endpoint root. Examples:
+- **API base URL** — the vendor's OpenAI-compatible endpoint root. Examples below may be stale — vendors rotate endpoints; always confirm via `web_fetch` against current docs before registering:
   - z.ai → `https://api.z.ai/api/coding/paas/v4`
   - deepseek → `https://api.deepseek.com`
   - groq → `https://api.groq.com/openai/v1`
@@ -46,7 +47,7 @@ Ask the user, or infer from their request:
   - mistral → `https://api.mistral.ai/v1`
 - **Default model id** — the model to use when no other is specified (you'll usually pick the vendor's "flagship" or "best general purpose" model).
 
-If the user hasn't given you the baseURL, look it up via WebFetch on the vendor's docs (search for "openai compatible", "base url", "endpoint") and propose it back to them for confirmation. **Do not guess.**
+If the user hasn't given you the baseURL, look it up via `web_fetch` on the vendor's docs (search for "openai compatible", "base url", "endpoint") and propose it back to them for confirmation. **Do not guess.**
 
 ## 2. Discover the model list
 
@@ -54,13 +55,13 @@ You need to populate a `models` array. Each entry needs `id`, `contextWindow`, `
 
 Two paths, in order of preference:
 
-1. **WebFetch the vendor's models / pricing page** to extract the current catalog. Good search prompts: `"<vendor> models pricing context window"`, `"<vendor> api models list"`. Common locations:
+1. **`web_fetch` the vendor's models / pricing page** to extract the current catalog. Good search prompts: `"<vendor> models pricing context window"`, `"<vendor> api models list"`. Common locations (may be stale — confirm against current docs):
    - z.ai → `https://docs.z.ai/guides/llm/glm-4.6`, `https://z.ai/pricing`
    - deepseek → `https://api-docs.deepseek.com/quick_start/pricing`
    - groq → `https://console.groq.com/docs/models`
    - openrouter → `https://openrouter.ai/models`
    - fireworks → `https://fireworks.ai/models`
-2. **The vendor's `/v1/models` endpoint** lists canonical model ids (but not context windows). This needs the API key, which you will NOT have (see step 3 — the key goes straight into the vault, never to you). So prefer WebFetch for discovery; if you must use `/v1/models`, ask the user to run it themselves and paste the model-id list (not the key).
+2. **The vendor's `/v1/models` endpoint** lists canonical model ids (but not context windows). This needs the API key, which you will NOT have (see step 3 — the key goes straight into the vault, never to you). So prefer `web_fetch` for discovery; if you must use `/v1/models`, ask the user to run it themselves and paste the model-id list (not the key).
 
 Build the list, show it to the user as a markdown table (id / context / tools / images), and ask them to confirm or trim. **Do not invent context-window numbers.** If a model's context is unknown, ask the user or leave it out.
 
@@ -128,7 +129,7 @@ Report:
 ## Don't
 
 - Don't ask the user to paste their API key to you, and don't call any tool with the key as an argument. Direct them to `/vault set <SLUG>_API_KEY <key>` so it never enters the conversation.
-- Don't invent baseURLs, model ids, or context windows. If you're not sure, WebFetch or ask.
+- Don't invent baseURLs, model ids, or context windows. If you're not sure, `web_fetch` or ask.
 - Don't store the API key anywhere except the vault. Never write it into a file in the repo, never echo it back.
 - Don't try to handle non-OpenAI-compatible vendors here — those need a real provider plugin (`.claude/agents/provider-author.md`).
 - Don't overwrite an existing provider slug without telling the user first. Call `provider_list` if you're unsure whether the slug is taken.

package/dist/skills/generative-ui.md

@@ -1,6 +1,6 @@
 ---
 name: generative-ui
-description: Generate an interactive, navigable UI (a "generative UI" / "dynamic UI" / "agentic UI") for the user — rendered in their browser, backed by real data from your tools. Only when the user explicitly asks for a generative/dynamic/agentic UI.
+description: Generate an interactive, navigable UI (generative/dynamic/agentic UI) in the user's browser, backed by real data from your tools. Only when the user explicitly asks for one.
 triggers: ["generative ui", "dynamic ui", "agentic ui", "generative interface", "dynamic interface", "agentic interface", "interactive ui for", "generative app", "agentic app"]
 allowed-tools: [present_view, web_fetch, browser_session]
 ---

package/dist/skills/remember-this.md

@@ -20,9 +20,9 @@ The user wants you to commit something to long-term memory so it's available in
 1. **Distill** what the user just said into 1–2 sentences. If the original was a long ramble, summarize. If it was already terse, keep it.
 2. **Check existing memories** with `memory_recall(query)` for similar entries. If a related entry exists, prefer `memory_update` over creating a new one — don't fragment.
 3. **Save** with `memory_save({ name, type, description, body, tags })`:
-   - `name`: slug, ≤60 chars, kebab-case
-   - `description`: one sentence, ≤120 chars — this is what shows in the index
-   - `body`: ≤30 lines; the actual content
+   - `name`: slug, kebab-case — aim for ≤60 chars (`memory_save` hard cap 120)
+   - `description`: one sentence — aim for ≤120 chars (hard cap 280); this is what shows in the index
+   - `body`: keep it tight (~≤30 lines); the actual content
    - `tags`: optional, lowercase keywords for cross-cutting topics
 
 4. **Confirm** briefly: "Saved as `<name>`."

package/dist/skills/self-heal.md

@@ -18,6 +18,9 @@ triggers:
   - "self-heal"
   - "self heal"
   - "repair"
+# allowed-tools intentionally omitted: this skill drives a broad, evolving set of
+# privileged tools (Read, Grep, Glob, bash, Edit, Write, install_plugin, mcp_*,
+# synthesize_skill) — an omitted allowed-tools means "all tools", on purpose.
 ---
 
 # Self-heal — diagnose then propose ONE fix

package/dist/skills/self-update.md

@@ -14,6 +14,9 @@ triggers:
   - "change your code"
   - "you should be able to"
   - "can you learn to"
+# allowed-tools intentionally omitted: this skill drives a broad, evolving set of
+# privileged tools (self_update_*, install_plugin, Write, Edit, bash) — an omitted
+# allowed-tools means "all tools", on purpose. Don't add a list that would go stale.
 ---
 
 # Self-update — author or repair a capability, safely

package/dist/skills/synthesize-skill.md

@@ -2,19 +2,26 @@
 name: synthesize-skill
 description: When the user request doesn't match any existing skill, draft a new one and persist it for next time.
 triggers: ["create skill", "new skill", "save this as a skill"]
-allowed-tools: [Write, Read]
+allowed-tools: [synthesize_skill, Write, Read]
 ---
 # Synthesize a new skill
 
 The user has asked for something for which no existing skill matches. Your job is to:
 
 1. Identify the intent (one sentence).
-2. Draft a Markdown skill file with YAML frontmatter:
-   - `name`: kebab-case slug, no more than 60 chars
-   - `description`: one sentence, < 120 chars
+2. **Prefer the `synthesize_skill` tool** — pass the intent and let it draft, validate
+   the frontmatter against the canonical schema, pick a collision-free filename, persist
+   to `~/.moxxy/skills/`, and hot-swap the registry. This is the path that can't ship
+   invalid frontmatter or clobber an existing skill.
+3. Only hand-write the file with `Write` if the tool is unavailable. If you do, the
+   frontmatter MUST satisfy the schema (hard caps: `name` <=120, `description` <=240).
+   Aim well under those for legibility — these are style budgets, not the wall:
+   - `name`: kebab-case slug, aim for <=60 chars (schema hard cap 120)
+   - `description`: one sentence, aim for <=120 chars (schema hard cap 240)
    - `triggers`: 2–5 short phrases a user might say
    - `allowed-tools`: only the tools you need
-3. The body is the instructions for future invocations: numbered steps, the minimum needed to execute reliably.
-4. Save to `~/.moxxy/skills/<slug>.md` unless the user redirects to project scope.
+   The body is the instructions for future invocations: numbered steps, the minimum
+   needed to execute reliably. Save to `~/.moxxy/skills/<slug>.md` unless the user
+   redirects to project scope.
 
 Keep skill bodies short — under 30 lines. Long context belongs in code/files the skill reads at runtime, not in the skill itself.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@moxxy/cli",
-  "version": "0.14.8",
+  "version": "0.14.9",
   "description": "moxxy command-line binary. Subcommand dispatcher consuming the moxxy SDK.",
   "keywords": [
     "moxxy",
@@ -50,7 +50,7 @@
   },
   "dependencies": {
     "zod": "^3.24.0",
-    "@moxxy/sdk": "0.15.0"
+    "@moxxy/sdk": "0.15.1"
   },
   "optionalDependencies": {
     "@napi-rs/keyring": "^1.3.0",