@skill-map/cli 0.62.1 → 0.63.0

package/dist/cli/tutorial/sm-tutorial/SKILL.md

@@ -306,7 +306,7 @@ the `__PROVIDER__` token and skip kinds the provider does not claim.
      `daily-loop`).
   3. Provision the lens: the seeded portfolio has a root `AGENTS.md`
      (the `openai`/Codex marker) next to `.claude/`, but `openai` is
-     coming soon, so auto-detect ignores it and a plain `sm init`
+     experimental (ships disabled), so auto-detect ignores it and a plain `sm init`
      resolves the `claude` lens with no prompt. Run `sm init`, then
      `sm scan`. (If `.skill-map/` already exists, just `sm scan`.)
   4. Mark the skipped predecessors: `state.js set-part <predecessor> skipped`

package/dist/cli/tutorial/sm-tutorial/references/_core.md

@@ -133,10 +133,10 @@ element. Decide with §Provider detection:
   left bar): emit tester-facing messages with `> ` on every line,
   including blank lines inside a multi-paragraph block. This is the
   only active path today.
-- `provider != claude` (coming soon: Antigravity CLI, agent-skills,
+- `provider != claude` (experimental: Antigravity CLI, agent-skills,
   any other host where most non-Claude renderers show `>` as a
   literal character): emit **plain prose**, NO `> ` prefix anywhere.
-  Kept as the wiring for the coming-soon providers; not exercised
+  Kept as the wiring for the experimental providers; not exercised
   while the tutorial demos `claude` only.
 
 Sample messages throughout the part files are written in the Claude
@@ -259,24 +259,24 @@ on-disk convention:
 | Provider       | Base dir          | Kinds it claims             | Detect via env var(s)                                  |
 |----------------|-------------------|-----------------------------|--------------------------------------------------------|
 | `claude`       | `.claude/`        | `agent`, `command`, `skill` | `CLAUDECODE=1` OR `AI_AGENT` starts with `claude-code` |
-| `agent-skills` | `.agents/skills/` | `skill` only (vendor-neutral; also the on-disk home for Google's Antigravity CLI, which replaced the Gemini CLI on 2026-05-19 and adopted this open standard) | coming soon (not selectable in the tutorial yet) |
-| `openai`       | `.codex/`         | `agent` (`.codex/agents/*.toml`) | coming soon (not selectable in the tutorial yet) |
+| `agent-skills` | `.agents/skills/` | `skill` only (vendor-neutral; also the on-disk home for Google's Antigravity CLI, which replaced the Gemini CLI on 2026-05-19 and adopted this open standard) | experimental (ships disabled; `sm tutorial --experimental` to offer it) |
+| `openai`       | `.codex/`         | `agent` (`.codex/agents/*.toml`) | experimental (ships disabled by default) |
 
 **Decision logic, applied silently during pre-flight**: the tutorial
 demonstrates the `claude` provider only. `agent-skills` and `openai`
-are **coming soon** and are not selectable here, so there is no
-runtime to detect or opt into.
+are **experimental** (ship disabled by default) and are not selectable
+here, so there is no runtime to detect or opt into.
 
 1. `provider = claude`, `<provider_dir> = .claude`, kinds =
    `{agent, command, skill}`. Always.
 2. Do NOT offer Antigravity / agent-skills / openai as an alternative,
    and do NOT ask the tester which runtime hosts them. If a tester
    says they use another runtime, acknowledge it briefly and explain
-   that those providers are coming soon, the tutorial demos `claude`
+   that those providers are experimental, the tutorial demos `claude`
    (`.claude/`) today:
 
    > Heads up: skill-map also reads Antigravity, agent-skills and
-   > Codex projects, but those providers are coming soon in this
+   > Codex projects, but those providers are experimental in this
    > tutorial. We'll demo skill-map's Claude provider (`.claude/`)
    > today.
 

package/dist/cli/tutorial/sm-tutorial/references/part-authoring.md

@@ -146,16 +146,27 @@ content, not configuration). Append at the end:
 - [ ] XXX revisit naming.
 ```
 
-Now re-scan so the extractor re-reads its settings and re-counts:
+Now restart `sm` so it re-reads the plugin. `sm` loads the plugin
+(its settings, its slot, the contribution itself) **once, at
+boot**, so a server left running from an earlier chapter froze that
+view at startup and will not see the new `XXX` keyword. Stop it
+with Ctrl+C and run it again (or just run it, if it is not up):
 
 ```bash
-sm scan
+sm
 ```
 
-The scan re-emits the contribution with the new count. To see it,
-run `sm`, open the browser, click `notes/ideas`, and find the chip
-in the card's **left footer** (it also shows in the inspector). It
-reads `🔍 kw 3`, one match per keyword.
+Booting runs a fresh scan, so the extractor re-reads
+`ctx.settings.keywords` (now including `XXX`) and re-counts. Open
+the browser, click `notes/ideas`, and find the chip in the card's
+**left footer** (it also shows in the inspector). It reads
+`🔍 kw 3`, one match per keyword.
+
+> Heads up: editing only the fixture (`notes/ideas.md`) updates
+> live through the watcher, but it recounts with the OLD keyword
+> set, so the chip would read `🔍 kw 2`. The new `XXX` keyword
+> lives in the plugin, and the plugin is read at boot, that is why
+> restarting `sm` is the step that takes the count to 3.
 
 > Three matches. The setting flowed from the extension's `settings`
 > through `ctx.settings.keywords` into the extractor, the extractor
@@ -175,15 +186,15 @@ The tester edits the extractor source:
 > Find the `slot` line in the `count` contribution. Change
 > `'card.footer.left'` to `'card.footer.right'`. Save.
 
-Re-scan:
+The slot is part of the plugin's definition, and `sm` reads that
+**once, at boot**. The watcher re-counts content on the fly, but it
+does not reload a plugin, so the slot move is not live. Restart
+`sm` to pick it up (Ctrl+C, then `sm` again):
 
 ```bash
-sm scan
+sm
 ```
 
-If `sm` is still running, the watcher picks up the file change
-and re-emits contributions live. If not, run the scan manually.
-
 Refresh the UI, the chip should now appear in the **right footer**
 of the node card instead of the left.
 

package/dist/cli/tutorial/sm-tutorial/references/part-project-kickoff.md

@@ -31,7 +31,7 @@ lingers, mention it once and move on.
 **Context (agent, do not narrate the plumbing): the lens.** This
 project has a root `AGENTS.md` (the `openai`/Codex marker) sitting next
 to the `.claude/` folder (the `claude` marker, where the tutorial skill
-itself lives). `openai` is **coming soon**, though, so auto-detect
+itself lives). `openai` is **experimental** (ships disabled), though, so auto-detect
 ignores its marker and `sm init` resolves the lens to `claude`
 silently, exactly like the prologue: only `claude` is selectable today,
 so there is no ambiguity and no prompt. Do not promise the tester a
@@ -50,7 +50,7 @@ Tell the tester:
 > site). skill-map maps that harness.
 >
 > Run `sm init`, it auto-detects the `claude` lens (this is a Claude
-> project; the other lenses are coming soon). Then run `sm` to boot the
+> project; the other lenses are experimental). Then run `sm` to boot the
 > live UI.
 >
 > Open the URL `sm` printed. You'll see **one node**: `AGENTS.md`,

package/dist/cli/tutorial/sm-tutorial/references/part-settings.md

@@ -147,8 +147,8 @@ Expected: the scan prints a line like `Auto-detected activeProvider
 is just a key in `settings.json`, persisted like any other setting.
 
 > Other lenses exist in the engine (`openai` for Codex,
-> `agent-skills`, `antigravity`), but they are **coming soon** in the
-> tutorial: today we demo the `claude` lens only. The idea to keep is
+> `agent-skills`, `antigravity`), but they are **experimental** (ship
+> disabled by default): today we demo the `claude` lens only. The idea to keep is
 > the one above, one project reads through exactly one provider at a
 > time, chosen by `activeProvider`. The lens is cheap to change later
 > because the graph is always rebuilt from your files, never the