@skill-map/cli 0.53.2 → 0.53.4

package/dist/cli/tutorial/sm-tutorial/references/part-connect-harness.md

@@ -1,6 +1,6 @@
 # Part 2: Connect the harness (step library, `connect-harness`)
 
-This is the wiring part. Part 1 grew a small set of standalone nodes around the handbook (the portfolio harness); here the tester turns that scatter of dots into a connected graph: a link checker, a publish command that pulls three pieces together, the handbook becoming a real hub, and a close-up on how sure skill-map is of each connection. `pace: auto-advance` (walk straight into the next chapter once one is marked done), `preflight: reuse` (it builds on the portfolio harness from Part 1, 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.
+This is the wiring part. Part 1 grew a small set of standalone nodes around the handbook (the portfolio harness); here the tester turns that scatter of dots into a connected graph: a link checker, a publish command that pulls three pieces together, the handbook becoming a real hub, and a close-up on how sure skill-map is of each connection. `pace: auto-advance` (walk straight into the next chapter once one is marked done), `preflight: seed` (it builds on the portfolio harness from Part 1, reusing the accumulated state when its predecessors are done, 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 `check-links` - The link checker (~3 min)
 
@@ -53,7 +53,11 @@ Wait for confirmation. Mark `check-links`: done.
 
 **Context**: this is the chapter where the graph comes alive. The `/publish` command ties three pieces together in one body: it invokes the link checker, mentions the content editor, and references the deploy runbook. Three connectors light up from a single new node, one per link syntax.
 
-`Write` `.claude/commands/publish.md` (substitute `<provider_dir>` per `_core.md`; on `agent-skills` / Antigravity there is no `command` kind, so skip this whole chapter and fold its purpose into the prose of the next one):
+On `agent-skills` / Antigravity there is no `command` kind, so skip this whole chapter and fold its purpose into the prose of the next one.
+
+Tell the tester to create the file themselves (it is their project's file, Inviolable rule #2). Substitute `<provider_dir>` per `_core.md` in the path you give them:
+
+> Create `.claude/commands/publish.md` with exactly this content:
 
 ```markdown
 ---
@@ -69,7 +73,7 @@ args:
     required: true
 ---
 
-# /publish
+# publish
 
 The one command you run when the site is ready to go out.
 
@@ -79,12 +83,11 @@ The one command you run when the site is ready to go out.
 3. Follow the [deploy runbook](../../docs/DEPLOY.md) to ship.
 ```
 
-Tell the tester:
+Continue the tester message:
 
-> I added the `/publish` command, the single entry point you run when
-> the site is ready to go live. Watch the **Map**: **three** new
-> arrows light up at once from the new `publish` node, and each one is
-> a different colour because each one is a different kind of link:
+> Save it. Watch the **Map**: **three** new arrows light up at once
+> from the new `publish` node, and each one is a different colour
+> because each one is a different kind of link:
 >
 > - `publish -> check-links` (kind: `invokes`), from the `/check-links`
 >   token in the body.
@@ -98,7 +101,7 @@ Tell the tester:
 >
 > Did the three arrows appear?
 
-Wait for confirmation. Mark `publish`: done.
+Wait for confirmation. You MAY use `Read` on the file afterwards to verify it landed. Mark `publish`: done.
 
 ## Chapter `links` - The handbook becomes the hub (~4 min)
 
@@ -159,7 +162,7 @@ Tell the tester:
 > the more solid the arrow; the less sure, the more translucent.
 >
 > Open the Inspector for the `publish` node (click it on the **Map**).
-> Scroll down to the **Linked nodes** panel and read the **Outgoing**
+> Scroll down to the **Connections** panel and read the **Outgoing**
 > rows. Each row shows the link kind and a confidence badge:
 >
 > - `publish -> docs/DEPLOY.md` (`references`) reads **1.00** and looks
@@ -177,4 +180,4 @@ Tell the tester:
 >
 > Do you see the confidence badges in the Inspector?
 
-Wait for confirmation. Mark `confidence`: done. This closes Part 2; the orchestrator returns to the ToC menu (Part 3, "Maintain the site", is next on the spine).
+Wait for confirmation. Mark `confidence`: done. Last chapter of the part: apply §Closing a part (the close names the part by its title and routes back to the menu; do NOT lead into the next part from here).

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

@@ -229,7 +229,7 @@ Tell the tester:
 
 If a connector is missing, do not advance, the next chapter inspects the same hub edit. Mark `connectors`: done.
 
-## Chapter `inspector` - The inspector and linked nodes (~1 min)
+## Chapter `inspector` - The inspector and connections (~1 min)
 
 The connector opacity tells the confidence story at a glance; the exact per-link breakdown lives in the Inspector. Open it on the hub so the tester registers the surface before the `edit-link` chapter changes topology.
 
@@ -324,9 +324,9 @@ Leave the server running, the next chapter (`.skillmapignore`) is the last one t
 
 Earlier chapters showed the watcher picking up new files and edits (yours and theirs). This chapter flips the direction: a file the tester DOES NOT want in the map (a draft, a scratch file, a secret) gets hidden by a single line in `.skillmapignore`. Same live mechanism, no restart.
 
-`sm init` already wrote a starter `.skillmapignore` at the scope root. The flow has three beats:
+`sm init` already wrote a starter `.skillmapignore` at the scope root. The chapter is one step with a single confirmation (the node vanishing): the agent seeds a file the tester would never want public, shows where it lives, and the tester hides it with one glob.
 
-**Beat 1, you create one new fixture file (the agent does this).**
+**The agent seeds the file (no tester action, no separate pause).**
 
 `Write` `notes/private-credentials.md`, kind `markdown`, simulates a file the tester would never want surfacing publicly:
 
@@ -344,13 +344,15 @@ description: |
 API_TOKEN: example-not-real
 ```
 
-Confirm the file appears in the map as a sixth node (`notes/private-credentials`). The watcher sees it like any other `.md`, that's the point of the demo. (If the tester doesn't see it, they may need to click **Show all** in the map toolbar to clear any leftover selection.)
+It lands in the map as a sixth node (`notes/private-credentials`); the watcher sees it like any other `.md`. Do NOT pause to confirm the appearance, it folds into the single vanish confirmation at the end of this step.
 
-**Beat 2, you show the project structure (the agent does this).**
+**The tester hides it (single tester-facing message, one confirmation).**
 
-Before asking the tester to touch `.skillmapignore`, give them a mental map of the folder so they know where the file lives and what's around it. Use `Bash` (`ls -la` and `ls -la notes/` if a deeper view helps) and present the listing as a tester-facing message (apply the host-dependent rendering rule) so the tester sees what their cwd holds:
+Give the tester a mental map of the folder so they know where the file lives, then the glob that hides it, all in ONE message. Use `Bash` (`ls -la`, plus `ls -la notes/` if a deeper view helps) for the real listing and apply the host-dependent rendering rule. Per Inviolable rule #2, the agent does NOT touch `.skillmapignore` with its `Edit` tool, the tester edits it from their own editor:
 
-> One last step. Here's what your directory looks like right now:
+> One last step. Your `private-credentials` note just popped into
+> the map as a sixth node, that's the watcher again. Now let's hide
+> it. Here's what your directory looks like right now:
 
 ```
 .                            ← your cwd
@@ -368,19 +370,10 @@ Before asking the tester to touch `.skillmapignore`, give them a mental map of t
     └── private-credentials.md   ← what we want to hide
 ```
 
-> The `.skillmapignore` at the root is the file we'll touch
-> next. Same syntax as `.gitignore`. Anything matching a pattern
-> there is invisible to skill-map's scan.
-
-Adjust the actual tree shown to whatever `ls -la` returns, the goal is "tester recognises their own filesystem", not a copy of the snippet above.
-
-**Beat 3, the tester edits `.skillmapignore` (NOT the agent).**
-
-Per Inviolable rule #2, the agent does NOT touch `.skillmapignore` with your `Edit` tool. Tell the tester to do it from their editor:
-
-> Last step. Open `.skillmapignore` (it's at the cwd root) in your
-> editor of choice. At the end of the file, on a new line, append
-> this pattern:
+> The `.skillmapignore` at the root uses the same syntax as
+> `.gitignore`: anything matching a pattern there is invisible to
+> skill-map's scan. Open it in your editor (it's at the cwd root)
+> and append this pattern on a new line at the end:
 
 ```
 notes/private-*.md
@@ -399,6 +392,7 @@ notes/private-*.md
 >
 > Did the node vanish?
 
-After they confirm, you MAY use `Read` on `.skillmapignore` to verify the appended pattern landed correctly (in case `sm check` later reports something odd), that is read-only and allowed. Once confirmed, ask them to stop the server with **Ctrl+C** in the terminal before continuing.
+Adjust the actual tree shown to whatever `ls -la` returns, the goal is "tester recognises their own filesystem", not a copy of the snippet above. After they confirm, you MAY use `Read` on `.skillmapignore` to verify the appended pattern landed correctly (in case `sm check` later reports something odd), that is read-only and allowed. Once confirmed, ask them to stop the server with **Ctrl+C** in the terminal before continuing.
 
-Mark `ignore`: done.
+Mark `ignore`: done. Last chapter of the part: apply §Closing a part
+(the close names the part by its title and routes back to the menu).

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

@@ -1,62 +1,57 @@
-# 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`:
+# Part 6: Ship the site (the full publish pipeline) (step library, finale, `pipeline` + `golive`)
+
+The finale, the climax of the whole campaign. In Part 3 you ran the
+harness once, the simple way (generate two pages, serve them). Here you
+operate it exactly as it was designed: you drive the `/publish` command
+end to end, the way the handbook says to ship, and put a richer
+multi-page site live next to the full graph. Pace `auto-advance`,
+preflight `seed` (`harness-connected`), so a tester can jump straight
+here. Two chapters, in order: `pipeline` (run `/publish`: check the
+links, brief the editor, follow the deploy runbook) then `golive` (run
+the server and click through the finished site). Shared conventions
+live in `_core.md`.
+
+## Chapter `pipeline` - Run /publish end to end (check-links, brief, deploy runbook) (~4 min)
+
+**Context**: the harness is not just a picture, it is a set of
+instructions, and `/publish` is the one that ties them together. Its
+body says: run `/check-links`, brief `@content-editor` on any fix, then
+follow the deploy runbook. Here the tester (playing the harness) walks
+exactly those steps on a richer site. This is still Layer 1 vs Layer 2:
+the pages are output, so the Map stays put while the files change, same
+as Part 3, no need to re-teach it, just do not call it a bug if they
+notice.
+
+**Preparation** (the agent does this, playing `content-editor`):
+
+1. Ensure the two base pages exist. If they are not already on disk
+   from Part 3 (a tester can land here via the seed), lay
+   `public/index.html` and `public/about.html` exactly as in
+   part-run-harness.md, chapter `generate`. They are the single source
+   for those two pages; do not restate their markup, copy it from
+   there.
+2. Add a **Projects** link to the home nav. `Edit` `public/index.html`,
+   turning the About line of the nav into:
+
 ```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>
+      <a href="/about.html">About</a> ·
+      <a href="/projects.html">Projects</a>
 ```
 
-`public/about.html`:
+3. `Write` the new page `public/projects.html` (plain markup, links
+   back home, per the style guide):
+
 ```html
 <!doctype html>
 <html lang="en">
   <head>
     <meta charset="utf-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <title>About</title>
+    <title>Projects</title>
   </head>
   <body>
-    <h1>About</h1>
-    <p>A short page about the person behind the portfolio.</p>
+    <h1>Projects</h1>
+    <p>A few small things I have shipped.</p>
     <nav>
       <a href="/">Home</a>
     </nav>
@@ -65,47 +60,57 @@ the markup plain.
 ```
 
 ```bash
-# Nothing for you to run yet. Look at both halves of your screen.
+# Still nothing to run in the terminal. The publish steps below are
+# you walking the harness; the server comes in the next chapter.
 ```
 
 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.
+> Time to ship it the way your handbook says to. Open
+> `.claude/commands/publish.md` and look at its steps: that command is
+> the recipe, and you are about to run it by hand, the way the agent
+> would. Three pages now live under `public/`: home, about, and a new
+> projects page, with the home nav linking all three.
 >
-> 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.
+> **Step 1, check the links** (`/check-links`). Walk the three pages
+> and follow every internal link: `/` resolves to the home page,
+> `/about.html` and `/projects.html` to files that exist, and each
+> page links back home. Nothing points at a missing file, so the link
+> check is clean.
 >
-> Ready to see the site running?
+> **Step 2, brief the editor** (`@content-editor`). The check found
+> nothing to fix, so there is no brief to hand off this time, that is
+> the happy path. (Part 4 is where a link actually breaks and this
+> step earns its keep.)
+>
+> **Step 3, follow the deploy runbook** (`docs/DEPLOY.md`). It lists:
+> generate the pages (done), run the link check (done), start the
+> server (next chapter). You have walked the whole `/publish` flow.
+>
+> Glance at the Map one more time: it did not move while you added a
+> page and ran the pipeline. The pages are Layer 2 output; the harness
+> on the canvas is Layer 1, and that is what skill-map maps.
+>
+> Ready to put it live?
 
-Wait for confirmation. Mark `generate`: done. Auto-advance to
-`serve`.
+Wait for confirmation. You MAY `Read` the three files in `public/`
+afterwards to confirm the edit and the new page landed. Mark
+`pipeline`: done. Auto-advance to `golive`.
 
-## Chapter `serve` - node server.js: your portfolio, live, next to the graph (~4 min)
+## Chapter `golive` - Ship it: the richer site live next to the full graph (~3 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.
+**Context**: the climax. The tester starts the tiny Express server the
+pre-flight left in `server.js` and clicks through the three-page site,
+ending with the running portfolio on one side and the full skill-map
+graph of the harness that built it on the other. This is one of the
+few chapters where the tester runs non-`sm` commands themselves
+(`npm install`, `node server.js`); guide them, do not run it for them.
+`npm install` is idempotent, so it is safe whether or not they already
+ran it in Part 3.
 
-**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.
+**Preparation**: none. `server.js` and `package.json` exist from the
+kickoff pre-flight; the three pages exist from the `pipeline` chapter.
+The tester runs everything here.
 
 ```bash
 npm install
@@ -114,43 +119,37 @@ 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.
+> Last step, the fun one. In your terminal, run these two commands:
 >
-> The second, `node server.js`, starts the server. It prints a line
-> telling you it is listening, something like `Listening on
-> http://localhost:3000`.
+> `npm install` downloads the one small library the server needs
+> (Express). If you already ran it in Part 3 it just confirms it is
+> there. Then `node server.js` starts the server; it prints a line
+> 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.
+> Open `http://localhost:3000`. Click **About**, **Projects**, and
+> **Home** to move between all three pages. Those are the pages your
+> harness produced, shipped through the publish flow you just ran by
+> hand.
 >
-> 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.
+> Now take it all in 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 content editor, 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 site and a living map of how it all fits.
 >
-> Does the site load, and can you click between Home and About?
+> Does the site load, and can you click between Home, About and
+> Projects?
 
 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).
+and Node is on PATH (`node --version` should print 24 or higher). If
+the port is busy, stop the server with Ctrl+C and apply the ports edge
+case. Remind them the server stays running until they press Ctrl+C.
+
+This is the campaign finale. Congratulate them plainly: they went from
+an empty directory to a real, running portfolio plus a complete map of
+its harness. Mark `golive`: done. Last chapter of the part: apply
+§Closing a part (name the part by its title; since this closes the
+campaign spine, if every active part is now done route to the §Final
+wrap-up instead of the menu).

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

@@ -1,6 +1,6 @@
-# Part 3: Maintain the site (step library, `maintain`)
+# Part 4: 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.
+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: seed` (it builds on the portfolio harness from Parts 1 and 2, reusing the accumulated state when its predecessors are done, 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)
 
@@ -12,6 +12,21 @@ This chapter is the tester's hands the whole way (renaming and editing their own
 sm
 ```
 
+This part is the first time the live server and one-off `sm` commands run side by side, so give the tester the third-terminal heads-up below (substitute `<cwd>` with the tester's actual cwd, same substitution as every other `<cwd>` mention):
+
+> ⚠️ Heads up: from here you run one-off commands (`sm scan`, `sm
+> check`, the `mv` below) **while the `sm` server keeps running**. The
+> server holds its terminal until you Ctrl+C it, so open a **third
+> terminal** and anchor it to this same folder, that is where every
+> one-off command from here on goes:
+
+```bash
+cd <cwd>
+```
+
+> Three terminals now: this chat, the one running the live `sm` server
+> (leave it alone), and this new one for the one-off commands.
+
 > 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
@@ -167,7 +182,7 @@ args:
     required: true
 ---
 
-# /init
+# init
 
 Sets up the empty folders a new portfolio needs.
 ```
@@ -283,4 +298,4 @@ sm history content-editor
 >
 > 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.
+Wait for confirmation. Mark `versions`: done. Last chapter of the part: apply §Closing a part (the close names the part by its title and routes back to the menu).

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

@@ -1,4 +1,4 @@
-# Part 4: MCP (step library, `mcp-*` ids)
+# Part 5: 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
@@ -73,6 +73,6 @@ Tell the tester:
 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).
+line. Mark `mcp-node`: done. Last chapter of the part: apply §Closing
+a part (the close names the part by its title and routes back to the
+menu; the full publish finale is next on the spine).

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

@@ -1,4 +1,4 @@
-# Part 6 (b): Extend skill-map - plugins (step library, `tour-*` ids)
+# Part 7 (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
@@ -13,9 +13,10 @@ which verbs reach which surface.
 Before announcing the first step, verify the fixture is initialised
 (the cwd has `.claude/agents/master-agent.md`,
 `.claude/skills/master-skill/SKILL.md`, AND `.skill-map/` with
-`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
+`settings.json` and `skill-map.db`). The `extend` part's
+`backstage-init` preflight ran `sm init --no-scan` to provision it;
+the universal `.skillmapignore` from pre-flight keeps the tutorial's
+own files out of the scan. If any of that is missing, surface the
 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.

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

@@ -5,8 +5,8 @@ starts an actual project: a tiny personal **portfolio website**,
 fully static, served by a ~15-line Express server, plus the
 `.claude/` **harness** that maintains it. skill-map maps the harness
 (the `.md` assets and how they reference each other); the site itself
-is plain HTML the harness produces (Part 5 generates it and runs the
-server). `pace: per-step`, `preflight: portfolio-init`. Shared
+is plain HTML the harness produces (Part 3 runs it, Part 6 ships it).
+`pace: per-step`, `preflight: portfolio-init`. Shared
 conventions live in `_core.md`.
 
 The orchestrator's `portfolio-init` pre-flight (backstage, silent)
@@ -125,7 +125,7 @@ Wait for confirmation. Mark `first-agent`: done.
 **Context**: the prologue showed the four kinds on abstract demo
 nodes. Now name them on the real project, and add the two markdown
 docs the harness references later (the style guide and the deploy
-runbook), so Part 3's maintenance beats have something to point at.
+runbook), so Part 4's maintenance beats have something to point at.
 
 `Write` two docs (markdown kind):
 
@@ -171,16 +171,14 @@ Tell the tester:
 > - **agent**: `content-editor` (does work on your behalf).
 > - **markdown**: `AGENTS.md`, `CLAUDE.md`, the two docs (plain notes
 >   and manuals).
-> - **skill** and **command**: coming in the next part, when we add
->   the link checker and the publish command and wire everything
->   together.
+> - **skill** and **command**: you add these (the link checker and
+>   the publish command) in a later part.
 >
-> Your handbook now has a real harness around it. Next we connect it:
-> the agent reaching the style guide, the command invoking the
-> skill, the whole graph lighting up.
+> Your handbook now has a real harness around it: a `content-editor`
+> agent plus its docs, all on the map.
 >
-> Ready to connect the harness?
+> See the agent and the docs in the map?
 
-Wait for confirmation. Mark `real-kinds`: done. This closes Part 1;
-the orchestrator returns to the ToC menu (Part 2, "Connect the
-harness", is next on the spine).
+Wait for confirmation. Mark `real-kinds`: done. Last chapter of the
+part: apply §Closing a part (the close names the part by its title and
+routes back to the menu; do NOT lead into the next part from here).