npm - @skill-map/cli - Versions diffs - 0.51.0 → 0.53.0 - Mend

@skill-map/cli 0.51.0 → 0.53.0

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 (53) hide show

package/dist/cli/tutorial/sm-tutorial/SKILL.md +239 -1659
package/dist/cli/tutorial/sm-tutorial/references/_core.md +332 -0
package/dist/cli/tutorial/sm-tutorial/references/_manifest.yml +175 -0
package/dist/cli/tutorial/sm-tutorial/references/fixtures.md +251 -0
package/dist/cli/tutorial/{sm-master/references/tour-authoring.md → sm-tutorial/references/part-authoring.md} +14 -15
package/dist/cli/tutorial/sm-tutorial/references/part-cli.md +267 -0
package/dist/cli/tutorial/sm-tutorial/references/part-connect-harness.md +180 -0
package/dist/cli/tutorial/sm-tutorial/references/part-fundamentals.md +424 -0
package/dist/cli/tutorial/sm-tutorial/references/part-live-site.md +156 -0
package/dist/cli/tutorial/sm-tutorial/references/part-maintain.md +286 -0
package/dist/cli/tutorial/sm-tutorial/references/part-mcp.md +78 -0
package/dist/cli/tutorial/{sm-master/references/tour-plugins.md → sm-tutorial/references/part-plugins.md} +11 -11
package/dist/cli/tutorial/sm-tutorial/references/part-project-kickoff.md +186 -0
package/dist/cli/tutorial/{sm-master/references/tour-settings.md → sm-tutorial/references/part-settings.md} +22 -24
package/dist/cli.js +1253 -564
package/dist/index.d.ts +1 -1
package/dist/index.js +335 -208
package/dist/kernel/index.d.ts +320 -15
package/dist/kernel/index.js +335 -208
package/dist/migrations/001_initial.sql +36 -0
package/dist/ui/chunk-EQ72PEHT.js +1 -0
package/dist/ui/chunk-GBKHMJ4B.js +1110 -0
package/dist/ui/chunk-GEI6INVH.js +515 -0
package/dist/ui/chunk-JXRIGHET.js +552 -0
package/dist/ui/{chunk-WQMZOINB.js → chunk-K2MAVAHG.js} +1 -1
package/dist/ui/{chunk-BV323KTK.js → chunk-KHARMPTZ.js} +1 -1
package/dist/ui/chunk-L4NIF75A.js +2 -0
package/dist/ui/chunk-LCOYSPKE.js +1 -0
package/dist/ui/chunk-OFDQMBSJ.js +1 -0
package/dist/ui/chunk-P2DAPRK7.js +2 -0
package/dist/ui/chunk-Q2A6FWC7.js +4 -0
package/dist/ui/chunk-TXTY24G4.js +2204 -0
package/dist/ui/chunk-UBQUCSQ4.js +1 -0
package/dist/ui/chunk-WFLPMCK4.js +392 -0
package/dist/ui/chunk-WHZVGOS3.js +5 -0
package/dist/ui/chunk-YQFIXHKM.js +123 -0
package/dist/ui/index.html +2 -2
package/dist/ui/main-OYITFJ7B.js +4 -0
package/dist/ui/{styles-RG7Y33BT.css → styles-Q4NCOJQY.css} +1 -1
package/migrations/001_initial.sql +36 -0
package/package.json +10 -8
package/dist/cli/tutorial/sm-master/SKILL.md +0 -688
package/dist/cli/tutorial/sm-master/references/fixture-templates.md +0 -212
package/dist/ui/chunk-2GXE52AJ.js +0 -123
package/dist/ui/chunk-AEA5GIA7.js +0 -1
package/dist/ui/chunk-KHRNVLJW.js +0 -1
package/dist/ui/chunk-OZTRR4M7.js +0 -2312
package/dist/ui/chunk-Q5YJKCTP.js +0 -1066
package/dist/ui/chunk-RCT3JSFL.js +0 -1
package/dist/ui/chunk-VBTLX7GH.js +0 -1110
package/dist/ui/chunk-VJ57LHDR.js +0 -4
package/dist/ui/chunk-WMGW2UAL.js +0 -2
package/dist/ui/main-N7D2YBEX.js +0 -4

package/dist/cli/tutorial/sm-tutorial/references/part-live-site.md ADDED Viewed

@@ -0,0 +1,156 @@
+# Part 5: The site, live (step library, finale, `generate` + `serve`)
+This is the finale, the climax of the whole campaign. Pace
+`auto-advance`, preflight `reuse` (it builds straight on the
+portfolio harness from the earlier parts, same cwd). Two chapters,
+in order: `generate` (the agent writes the real HTML pages) then
+`serve` (the tester runs the site and sees it in the browser).
+Shared conventions live in `_core.md`.
+## Chapter `generate` - The agent generates the HTML in public/ (~3 min)
+**Context**: this is the payoff of the whole harness. The
+`content-editor` agent exists to write the site's pages, so now you
+(playing that agent) generate the actual HTML into `public/`. The
+honest beat the tester must hear: writing HTML does NOT move the
+skill-map graph. The graph is Layer 1, the `.md` harness that builds
+the site; the HTML is Layer 2, the harness's OUTPUT, and skill-map
+does not map it (HTML is not `.md`). So the Map will sit still while
+real files land on disk, and that is correct, not a bug. Keep the
+markup plain per the style guide: no framework, no client JS, one H1
+per page, every page links back home.
+**Preparation**: `Write` two static pages into `public/`. The
+pre-flight already left a placeholder `public/index.html`; this
+overwrites it with the real home page and adds an about page. Keep
+the markup plain.
+`public/index.html`:
+```html
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1" />
+    <title>My Portfolio</title>
+  </head>
+  <body>
+    <h1>My Portfolio</h1>
+    <p>Hi, I build small, sturdy things on the web.</p>
+    <nav>
+      <a href="/">Home</a> ·
+      <a href="/about.html">About</a>
+    </nav>
+  </body>
+</html>
+```
+`public/about.html`:
+```html
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1" />
+    <title>About</title>
+  </head>
+  <body>
+    <h1>About</h1>
+    <p>A short page about the person behind the portfolio.</p>
+    <nav>
+      <a href="/">Home</a>
+    </nav>
+  </body>
+</html>
+```
+```bash
+# Nothing for you to run yet. Look at both halves of your screen.
+```
+Tell the tester:
+> Here it is, the moment the whole harness was built for. Your
+> `content-editor` agent did its real job: it wrote the actual web
+> pages. Two HTML files just landed in your project under `public/`:
+> the home page (`public/index.html`) and an about page
+> (`public/about.html`), plain static markup that follows the style
+> guide you set up earlier.
+>
+> Now glance at the Map. It did not change, and that is exactly
+> right. Everything you watched grow on the canvas is your harness:
+> the `.md` files and how they reference each other (call that
+> Layer 1). The HTML pages are Layer 2, what the harness PRODUCES.
+> skill-map maps the harness, not the pages it outputs (HTML is not
+> `.md`), so writing real site files leaves the graph untouched. Two
+> layers, one project: the graph that builds the site, and the site
+> itself.
+>
+> Ready to see the site running?
+Wait for confirmation. Mark `generate`: done. Auto-advance to
+`serve`.
+## Chapter `serve` - node server.js: your portfolio, live, next to the graph (~4 min)
+**Context**: the climax. The tester installs the single dependency
+(Express) and starts the tiny server that the pre-flight already left
+in `server.js`, then opens the site in the browser. They end with two
+things side by side: the real portfolio they can click through, and
+the skill-map graph of the harness that built it. Express runs on
+Node, which the tester has from pre-flight (Node 24+), so no new
+install beyond `npm install`. This chapter is one of the few where
+the tester runs a non-`sm` command themselves (`npm install`,
+`node server.js`); guide them, do not run it for them.
+**Preparation**: none. `server.js` and `package.json` already exist
+from the kickoff pre-flight; the pages exist from the `generate`
+chapter. The tester runs everything in this chapter.
+```bash
+npm install
+node server.js
+```
+Tell the tester:
+> Last step, and it is the fun one. You have the pages; now let's
+> serve them. In your terminal, run these two commands:
+>
+> The first, `npm install`, downloads the one small library the
+> server needs (Express, a tiny web server). It runs on Node, which
+> you already installed at the very start, so there is nothing new to
+> set up.
+>
+> The second, `node server.js`, starts the server. It prints a line
+> telling you it is listening, something like `Listening on
+> http://localhost:3000`.
+>
+> Open `http://localhost:3000` in your browser. There it is: your
+> portfolio, live. Click the **About** link, then the **Home** link
+> to come back. Those are the very pages your harness produced.
+>
+> Now take a second to look at everything at once. On one side, the
+> real running site you can click through. On the other, the
+> skill-map graph of the harness that built it: the handbook, the
+> agent, the style guide, the publish command, the link checker, the
+> MCP tool, all wired together. You started in an empty folder with
+> nothing, and you have ended with a real, running thing and a living
+> map of how it all fits.
+>
+> Does the site load, and can you click between Home and About?
+Wait for confirmation. The tester runs the commands; do not run them
+for them. If `npm install` fails, check they are in the project root
+(the cwd they have used all along) and that Node is on PATH (`node
+--version` should print 24 or higher). If the port is busy, they can
+stop the server with Ctrl+C and the edge case for ports applies the
+same as elsewhere.
+When they confirm, this closes Part 5 and the campaign. Tell the
+tester they went from an empty directory to a real portfolio site
+plus a complete map of its harness, congratulate them plainly, and
+remind them the server stays running until they press Ctrl+C. Mark
+`serve`: done. The orchestrator returns to the ToC menu (the
+campaign spine is complete; the final wrap-up in `_core.md` applies
+when the tester signals they are finished).

package/dist/cli/tutorial/sm-tutorial/references/part-maintain.md ADDED Viewed

@@ -0,0 +1,286 @@
+# Part 3: Maintain the site (step library, `maintain`)
+This is the upkeep part. The harness from Part 2 is wired and clean; real projects drift, links break, drafts pile up, names collide. Here the tester breaks something on purpose and fixes it, meets the analyzer catalogue that catches those problems, finds an orphan nobody links to, clears a reserved-name warning, and learns the `.sm` companion files that carry the tool's bookkeeping. `pace: auto-advance` (walk straight into the next chapter once one is marked done), `preflight: reuse` (it builds on the portfolio harness from Parts 1 and 2, no fresh fixture of its own). Shared conventions (tone, provider detection / substitution, the `> ` rendering rule, the per-step cycle) live in `_core.md`; do not restate them here.
+## Chapter `broken-ref` - A link breaks (~3 min)
+**Context**: the most common kind of decay in a real project is a link that points at a file someone renamed or moved. Here the tester renames `docs/DEPLOY.md`, which breaks the `/publish -> docs/DEPLOY.md` reference from Part 2, and `sm check` surfaces it as `core/reference-broken`. Then they fix it by updating the link. Same watcher / live-UI loop they already know, plus the CLI verb that catalogues the issue.
+This chapter is the tester's hands the whole way (renaming and editing their own files, Inviolable rule #2). Tell the tester to start the server again first if it is not running:
+```bash
+sm
+```
+> Open the URL `sm` prints, same as before. Now break something on
+> purpose. Rename your deploy runbook from `docs/DEPLOY.md` to
+> `docs/DEPLOYMENT.md` (just change the filename, leave the contents
+> alone). On most systems that is one command in the terminal:
+>
+> ```bash
+> mv docs/DEPLOY.md docs/DEPLOYMENT.md
+> ```
+>
+> Watch the **Map**: the `publish -> docs/DEPLOY.md` arrow can no
+> longer find its target, because nothing called `docs/DEPLOY.md`
+> exists anymore. The link is now dangling.
+After they confirm the rename, have them ask skill-map about it:
+```bash
+sm scan
+sm check
+```
+> `sm scan` refreshes what skill-map knows from disk, then `sm check`
+> reports the problem: an issue from the `core/reference-broken`
+> analyzer (a rule that flags links pointing at files that do not
+> exist), naming the link `../../docs/DEPLOY.md` inside your `/publish`
+> command. That is the broken reference you just created.
+>
+> Now fix it. Open `.claude/commands/publish.md` in your editor and
+> change the deploy-runbook link so it points at the new filename:
+> `[deploy runbook](../../docs/DEPLOYMENT.md)`. Save, then re-check:
+>
+> ```bash
+> sm scan
+> sm check
+> ```
+>
+> `sm check` should print `✓ No issues` and the arrow comes back on
+> the **Map**. (If you would rather not keep the new name, renaming
+> the file back to `docs/DEPLOY.md` clears it just as well, but the
+> link edit is the more realistic fix.)
+>
+> Did the issue surface and then clear?
+Wait for confirmation. You MAY use `Read` on `.claude/commands/publish.md` to verify the link edit landed. Leave the server running, the next chapters reuse it. Mark `broken-ref`: done.
+## Chapter `analyzers` - The analyzer catalogue (~3 min)
+**Context**: `reference-broken` was just one rule. `sm check` runs a catalogue of around 16 deterministic analyzers, each catching a different family of problem. This chapter names a few and shows how to focus on one with `--analyzers`. No fixture changes, the tester just runs the verb against the clean harness.
+No file edits in this chapter.
+Tell the tester:
+> The broken-ref you just saw is one rule out of a catalogue. `sm
+> check` runs roughly 16 deterministic analyzers (each one a small
+> rule that scans your harness for a specific kind of problem). A few
+> of the families:
+>
+> - `core/reference-broken`: a link points at a file that does not
+>   exist (the one you just triggered).
+> - `core/name-reserved`: a file is named after a built-in the vendor
+>   runtime owns, so that runtime would ignore it (you will see this
+>   one live in a couple of chapters).
+> - `core/link-self-loop`: a node links to itself.
+> - `core/reference-redundant`: the same body points at the same
+>   target twice.
+> - `core/signal-collision`: two analyzers disagreed about the same
+>   slice of a file, and the warning explains who won and why.
+>
+> When you only care about one, focus on it:
+>
+> ```bash
+> sm check
+> sm check --analyzers reference-broken
+> ```
+>
+> The first runs the whole catalogue; the second narrows the report to
+> just the reference-broken rule. Your harness is clean right now, so
+> both print `✓ No issues`, but the same `--analyzers <id>` pattern
+> works for every rule in the catalogue.
+>
+> Paste me the output (or just an OK).
+Wait for confirmation. Mark `analyzers`: done.
+## Chapter `orphans` - A page nobody links to (~3 min)
+**Context**: a different kind of loose end. A node can be perfectly valid and still be an orphan: nothing in the harness links to it. We create a draft page that no one references, and `sm orphans` finds it. The point is to separate three ideas the tester now has names for: orphan (nothing points at it) vs broken-ref (a link with no target) vs issue (a rule violation).
+`Write` `docs/draft.md` (markdown kind), a half-finished page nobody has wired up yet:
+```markdown
+---
+name: draft
+description: |
+  Half-finished page nobody links to yet. Here to show what an
+  orphan looks like: a valid node with no incoming connectors.
+tags: [docs, portfolio, draft]
+---
+# Draft page
+Notes for a page that is not ready to link from anywhere yet.
+```
+Confirm the new `docs/draft` node appears on the **Map** as a floating dot with no arrows in or out.
+Tell the tester:
+> I dropped a new note into your project, `docs/draft.md`, a
+> half-finished page. Look at the **Map**: it shows up as a floating
+> dot with no arrows touching it. Nothing in your harness links to it,
+> which makes it an **orphan**.
+>
+> ```bash
+> sm orphans
+> ```
+>
+> `sm orphans` lists exactly that: nodes nothing points at. It is
+> worth keeping three ideas apart, because they are easy to confuse:
+>
+> - **orphan**: a real, valid node that simply has no incoming link
+>   (your `docs/draft`). Not an error, just unreferenced.
+> - **broken-ref**: a link whose target file does not exist (the one
+>   you triggered by renaming the runbook). That is a real issue.
+> - **issue**: any rule violation `sm check` reports (broken-ref is
+>   one family; name-reserved, self-loop and the rest are others).
+>
+> An orphan is not automatically a problem (a draft you have not wired
+> up yet is fine), it is just skill-map pointing out the page is not
+> reachable from anywhere. When you link to it later, it stops being
+> an orphan.
+>
+> Did `sm orphans` list `docs/draft`?
+Wait for confirmation. Mark `orphans`: done.
+## Chapter `reserved` - A reserved name collides (~3 min)
+**Context**: vendor runtimes own certain names (`/init`, `/help`, `/clear`, and friends). If the tester names a command after one of those, the runtime ignores their file and skill-map raises a `core/name-reserved` warning to say so. We create the collision, see the warning, then rename to clear it.
+`Write` `.claude/commands/init.md` (substitute `<provider_dir>` per `_core.md`; on `agent-skills` / Antigravity there is no `command` kind, so skip this whole chapter), deliberately named after the built-in `/init`:
+```markdown
+---
+name: init
+description: |
+  Bootstraps a fresh portfolio scaffold. Named init on purpose, to
+  collide with the runtime built-in and trigger name-reserved.
+args:
+  - name: target
+    type: path
+    description: Folder to scaffold into.
+    required: true
+---
+# /init
+Sets up the empty folders a new portfolio needs.
+```
+Confirm the new `init` command node appears on the **Map**.
+Tell the tester:
+> I added a command called `/init` to your harness. There is a catch:
+> `/init` is a name the vendor runtime already owns for its own
+> built-in, so the runtime would quietly ignore your file and never
+> run it. Skill-map flags exactly that:
+>
+> ```bash
+> sm scan
+> sm check
+> ```
+>
+> You will see a `core/name-reserved` warning naming the `init`
+> command. It is not skill-map being fussy, it is telling you "the
+> runtime will never invoke this file, pick another name". On the
+> **Map**, any link into a shadowed node is drawn faint for the same
+> reason.
+>
+> The fix is just to rename it. Rename `.claude/commands/init.md` to
+> something that is not reserved, for example
+> `.claude/commands/scaffold.md` (and update the `name:` in its
+> frontmatter to `scaffold`). On most systems:
+>
+> ```bash
+> mv .claude/commands/init.md .claude/commands/scaffold.md
+> ```
+>
+> Then re-check:
+>
+> ```bash
+> sm scan
+> sm check
+> ```
+>
+> The warning should be gone. A reserved name is one of the rare
+> mistakes skill-map can catch before the runtime ever bites you.
+>
+> Did the warning appear and then clear after the rename?
+Wait for confirmation. You MAY use `Read` to verify the rename landed. Mark `reserved`: done.
+## Chapter `sidecar` - The .sm companion file and its consent prompt (~3 min)
+**Context**: every `.md` skill-map tracks can get a sibling **companion file** with extension `.sm` that carries all of the tool's metadata about that markdown (version, history, tags, annotations), so the `.md` stays clean and only holds the content you write. The `.md` is yours; the `.sm` is bookkeeping the tool writes. The first time skill-map wants to create one in a project it asks for consent, and the choice is remembered in `settings.local.json`. We demonstrate on the handbook.
+This is a CLI beat, the tester runs everything. **Reset any prior consent first** so the `[Y/n]` prompt actually appears (an earlier session may have flipped the flag, in which case the verb would skip straight past it and the lesson would not land):
+```bash
+rm -f AGENTS.sm .skill-map/settings.local.json
+sm sidecar annotate AGENTS.md
+```
+> `sm sidecar annotate` creates a fresh `.sm` companion file next to a
+> markdown file. Because this is the first time skill-map wants to
+> write one here, it shows a short explanation and then a `[Y/n]`
+> prompt (capital Y is the default, so you can just press Enter to
+> accept). skill-map never writes a `.sm` to your project without your
+> OK.
+>
+> After you accept, two things happen: a new `AGENTS.sm` file appears
+> next to `AGENTS.md` (carrying an `identity:` block and an empty
+> `annotations: {}` block), and your project remembers the choice in
+> `.skill-map/settings.local.json` so it never asks again. Take a look:
+>
+> ```bash
+> cat AGENTS.sm
+> cat .skill-map/settings.local.json
+> ```
+>
+> You will see `AGENTS.sm` holds the tool's bookkeeping for the
+> handbook, and `settings.local.json` now contains
+> `{ "allowEditSmFiles": true }`. That flag lives in the local config
+> layer (gitignored), so each contributor consents on their own
+> checkout and the choice never travels through git.
+>
+> Did the prompt appear, and does `AGENTS.sm` exist now?
+Wait for confirmation. You MAY use `Read` on `AGENTS.sm` to verify it landed. Mark `sidecar`: done.
+## Chapter `versions` - Bump a version, read its history (~3 min)
+**Context**: now that the consent is granted, the day-to-day versioning verbs go through silently. `sm bump` increments a node's frontmatter version and appends a record to its `.sm` companion; `sm history` reads that trail back. We bump the content editor and read its history. Same consent gate as the previous chapter, already satisfied.
+This is a CLI beat, the tester runs everything (substitute `<provider_dir>` in the path per `_core.md`):
+```bash
+sm bump content-editor
+sm history content-editor
+```
+> `sm bump <node>` is the everyday versioning verb: it nudges the
+> `version` field in the node's frontmatter up by one and appends an
+> entry to that node's `.sm` companion file, recording that the bump
+> happened. Because you already granted consent in the last chapter,
+> it runs without prompting (the `.sm` write is pre-authorized for
+> this checkout).
+>
+> `sm history <node>` reads that trail back: it prints the version
+> entries skill-map has recorded for the content editor, so you can
+> see how it has changed over time. Right after one bump you will see
+> the single entry the bump just wrote.
+>
+> The two verbs are a pair: `sm bump` writes a version checkpoint into
+> the companion file, `sm history` reads the checkpoints back out.
+> Your `.md` body never gets cluttered with this, it all lives in the
+> `.sm` alongside it.
+>
+> Does `sm history` show the bump you just made?
+Wait for confirmation. Mark `versions`: done. This closes Part 3; the orchestrator returns to the ToC menu.

package/dist/cli/tutorial/sm-tutorial/references/part-mcp.md ADDED Viewed

@@ -0,0 +1,78 @@
+# Part 4: MCP (step library, `mcp-*` ids)
+This is a chapter apart, the one just before the finale. Pace
+`auto-advance`, preflight `reuse` (it builds straight on the
+connected portfolio harness from the earlier parts, same cwd, same
+live `sm` session). One chapter only. Shared conventions live in
+`_core.md`.
+## Chapter `mcp-node` - The agent reaches for an MCP tool (~3 min)
+**Context**: until now every node on the map has been a file you can
+open. This chapter introduces a node that is NOT a file: an MCP
+server the `content-editor` agent calls. MCP (Model Context
+Protocol) is the standard way an agent reaches an external tool, and
+Claude names those tools `mcp__<server>__<tool>` in an agent's
+frontmatter. When the agent declares it uses `mcp__images__search`
+(an image-search tool, so it can find art for the pages), skill-map's
+`core/mcp-tools` extractor reads that declaration and draws a
+virtual `mcp://images` node plus a `references` link from
+content-editor to it. The link confidence is around 0.85 (high, but
+not the 1.00 of a markdown link to a real file, because the target is
+an external service, not a file on disk). If several harness members
+named the same server, skill-map would draw a single shared
+`mcp://images` node, not one per caller.
+**Preparation**: `Edit` `<provider_dir>/agents/content-editor.md`
+(substitute `<provider_dir>` per `_core.md`; on `agent-skills` /
+Antigravity the editor is a `skill` instead, edit that file's
+frontmatter the same way). Do NOT rewrite the file. Change only the
+`tools:` line in the frontmatter so the MCP tool joins the existing
+two:
+```yaml
+tools: [Read, Write, mcp__images__search]
+```
+The rest of the file stays exactly as it was.
+```bash
+# Nothing for you to run here. Watch the Map.
+```
+Tell the tester:
+> Your `content-editor` agent just learned a new trick. I added an
+> external tool to its toolbelt: an image search it can call to find
+> art for the pages. In an agent's settings, Claude writes that kind
+> of tool as `mcp__images__search`. MCP (Model Context Protocol) is
+> just the agreed-on way an agent reaches a tool that lives outside
+> your files.
+>
+> Watch the Map. A brand-new node appears, but this one is not a
+> file you can open: `mcp://images`, with its own icon and colour
+> (kind `mcp`). A `references` connector runs from `content-editor`
+> to it, the agent declaring "I use this tool".
+>
+> Look at that connector's transparency. Earlier you saw a link to a
+> real file sit fully solid at 1.00. This one is a touch more
+> translucent (around 0.85): skill-map is confident the agent uses
+> the tool, but the tool is an outside service, not a file it can
+> verify on disk, so it holds back a little certainty. The opacity
+> tells that story, same as before.
+>
+> One honest note: skill-map learned about this tool from your
+> agent's own settings, what your harness says it CONSUMES. It did
+> not go read a server config to confirm the tool exists. Mapping the
+> server side (reading an `.mcp.json`) is a separate thing that may
+> come later; today the map shows MCP usage from the caller's point
+> of view.
+>
+> See the new `mcp://images` node and the connector into it?
+Wait for confirmation. If the node did not appear, have the tester
+save the file again (the watcher reacts on save) or refresh the
+browser, then re-check; the `tools:` line must be valid YAML on one
+line. Mark `mcp-node`: done. This closes Part 4; the orchestrator
+returns to the ToC menu (Part 5, "The site, live", the finale, is
+next on the spine).

package/dist/cli/tutorial/{sm-master/references/tour-plugins.md → sm-tutorial/references/part-plugins.md} RENAMED Viewed

@@ -1,4 +1,4 @@
-# Tour: plugins-tour
+# Part 6 (b): Extend skill-map - plugins (step library, `tour-*` ids)
 Guided tour of the **built-in plugins** that ship with `sm`. Three
 steps: a quick mental model of what plugins are plus a peek at
@@ -16,11 +16,11 @@ Before announcing the first step, verify the fixture is initialised
 `settings.json` and `skill-map.db`). Pre-flight already ran
 `sm init --no-scan` and appended the master entries to
 `.skillmapignore`. If any of that is missing, surface the
-bootstrap mismatch ("master-state.yml says we are running, but
-the bootstrap is missing. Run `sm-master` from an empty dir or
+bootstrap mismatch ("tutorial-state.yml says we are running, but
+the bootstrap is missing. Re-run the tutorial from an empty dir or
 restore the files.") and stop.
-## Step `tour-1-intro` — how plugins work (~4 min)
+## Step `tour-1-intro` - how plugins work (~4 min)
 **Context**: A short tour of what a plugin is, how it groups
 extensions, and a peek at the five plugins that ship
@@ -60,7 +60,7 @@ sm plugins list
 Mark `tour-1-intro: done`.
-## Step `tour-2-kinds` — the six extension kinds (~5 min)
+## Step `tour-2-kinds` - the six extension kinds (~5 min)
 > An extension has a **kind**. The kind tells the kernel where it
 > plugs into the pipeline. There are exactly six kinds:
@@ -104,7 +104,7 @@ Mark `tour-1-intro: done`.
 > **extensions**, each extension has a **kind**, the kind decides
 > where it plugs into the kernel.
 >
-> Heads up: every `sm plugins` verb you'll run in this tour is
+> Heads up: every `sm plugins` verb you'll run in this part is
 > also available from the UI. From any `sm serve` session, open
 > the **gear icon → Plugins** tab to browse and toggle plugins
 > from there. CLI and UI use the same store, so a change in one
@@ -124,7 +124,7 @@ all packed into a single plugin.
 Mark `tour-2-kinds: done`.
-## Step `tour-3-explore` — explore one extension up close (~4 min)
+## Step `tour-3-explore` - explore one extension up close (~4 min)
 **Context**: Drill into a single extension to see its detail,
 run the diagnostic, then toggle one off and back on so you see
@@ -172,7 +172,7 @@ if you restarted `sm`, the disabled state would still be there.
 Mark `tour-3-explore: done`.
-## Tour wrap-up
+## Wrap-up
 > All set. You now know:
 >
@@ -182,13 +182,13 @@ Mark `tour-3-explore: done`.
 > - How to list, inspect, diagnose, and toggle extensions from
 >   the CLI (and the same lives in the UI).
 >
-> If you want to dig deeper, the next menu option takes you into
+> If you want to dig deeper, the next chapters take you into
 > authoring your own plugin and into settings + view-slots. Or
 > if you've seen enough, "I'm done for today" closes us out.
 >
 > Anything weird worth logging? If not, back to the menu.
-Mark tour `plugins-tour: done` in `master-state.yml`, update the
+Mark the plugins chapters done in `tutorial-state.yml`, update the
 matching harness task, return to the menu in `SKILL.md`.
 ## Reference: how `sm` decides what to load
@@ -198,7 +198,7 @@ Not for the tester unless they ask. Cheat sheet for the agent:
 - Built-in plugins live inside the CLI bundle and are always
   discovered first.
 - Project plugins live under `<cwd>/.skill-map/plugins/`; the
-  authoring tour uses this path. There is no user / global
+  authoring chapters use this path. There is no user / global
   scope, `-g/--global` and `~/.skill-map/plugins/` were removed
   in v0.27.x.
 - Load order: built-in → project (project ids that collide with