@skill-map/cli 0.60.4 → 0.61.1

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

@@ -6,7 +6,7 @@ The live-UI prologue: the tester runs `sm init`, opens the browser, and watches
 
 Agent background (do NOT render this as a separate context paragraph; the tester-facing version is folded into the message below): `sm init` creates a hidden `.skill-map/` folder in the cwd holding the database where skill-map stores what it learns about the project, and runs an initial scan (mandatory first step). Typing `sm` alone (no arguments) in an initialised dir then starts the UI server with the watcher built in (it is just an alias of `sm serve` with all defaults; the moment you need any flag you write `sm serve --flag ...` explicitly). One process, one terminal: it boots the server, scans the `.md` files, detects changes, and pushes events over WebSocket to the live UI. The next chapters all run against this same `sm` session, you boot it here and keep it alive through the `ignore` chapter.
 
-Expected: `.skill-map/skill-map.db` appears (plus config files), and the initial scan reports a small node / link count from the demo-agent fixture. `sm init` runs and exits; `sm` then starts the UI server and stays running. (Agent context, do not narrate: pre-flight's `.skillmapignore` keeps the tutorial's own files, `sm-tutorial.md` / `findings.md` / `tutorial-state.yml`, out of the scan; `sm init` leaves that file alone since it only writes when absent.)
+Expected: `.skill-map/skill-map.db` appears (plus config files), and the initial scan reports a small node / link count from the demo-agent fixture. `sm init` runs and exits; `sm` then starts the UI server and stays running. (Agent context, do not narrate: pre-flight's `.skillmapignore` keeps the tutorial's own files, `sm-tutorial.md` / `findings.md` / `tutorial-state.json`, out of the scan; `sm init` leaves that file alone since it only writes when absent.)
 
 Give the tester the whole flow in ONE message with ONE confirmation, do NOT pause for the `sm init` output separately. Order matters: **lead with the browser setup**, then explain what the two commands do as you hand them over, then the command block, then the URL. Do NOT print the command block or an explanation paragraph before the browser instruction. Don't hardcode the URL, the verb logs the bound `http://host:port` after listen. Tell the tester:
 
@@ -36,114 +36,28 @@ Wait for confirmation. Mark `init`: done.
 
 ## Chapter `kinds` - The other kinds appear (~1 min)
 
-Leave the browser open and the terminal with `sm` running. You create five more nodes **without any cross-fixture links** yet, pure standalone nodes, so the tester sees five new dots pop in. Three new **kinds** show up in this step (skill, command, markdown); the last two files are sibling `markdown` notes (`demo-guideline`, `demo-guideline2`) the hub in the `connectors` chapter reaches two ways, a bare mention that resolves to nothing (which lands as a broken reference, no arrow drawn) and the same handle plus `.md` that resolves to a real file (a solid arrow).
-
-Create these five files (with `Write`), exactly in this order. Per §Provider detection, **substitute `.claude/` with the detected `<provider_dir>` and skip files whose kind is not in the provider's supported set** (`agent-skills` / Antigravity: skip both `demo-agent` and `demo-command`, only the skill + the three markdown notes remain). Adjust the node count, the "five new nodes" message, and the file list shown to the tester in the sample below accordingly:
-
-1. `.claude/skills/demo-skill/SKILL.md` (kind: skill):
-   ```markdown
-   ---
-   name: demo-skill
-   description: |
-     Example skill that walks a file and returns a Markdown report.
-     Showcases the `skill` kind in the demo map.
-   ---
-
-   # demo-skill
-
-   This skill walks a file and returns a report. Will be wired up
-   to the rest of the demo fixture in the next sub-step.
-
-   ## Steps
-   1. Read the `target`.
-   2. Validate the frontmatter against the schemas.
-   3. Generate the report.
-   ```
-
-2. `.claude/commands/demo-command.md` (kind: command):
-   ```markdown
-   ---
-   name: demo-command
-   description: |
-     Example slash command that wraps the demo-skill. Showcases the
-     `command` kind.
-   ---
-
-   # demo-command
-
-   Quick entry point for running the demo flow on a target file.
-   Connectors land in the next sub-step.
-   ```
-
-3. `notes/todo.md`, classified as `kind: markdown` today
-   (the catch-all for `.md` files outside the
-   skill / agent / command folders):
-   ```markdown
-   ---
-   name: Demo TODO list
-   description: |
-     Live list of things to review in the demo. Will become the
-     hub that points to the rest of the fixture in the next
-     sub-step.
-   ---
-
-   # Pending
-   ```
-
-4. `notes/demo-guideline.md`, second `kind: markdown` node, reached
-   in the `connectors` chapter by a bare `@`-mention that resolves to
-   no agent, so it surfaces as a broken reference instead of a drawn
-   connector:
-   ```markdown
-   ---
-   name: demo-guideline
-   description: |
-     Static reference notes the rest of the demo points at. The hub
-     reaches it with a bare `@`-mention, which resolves to no agent,
-     so skill-map flags it as a broken reference (0.50) instead of
-     drawing an arrow.
-   ---
-
-   # Demo Guideline
-
-   Conventions the demo fixture follows:
-
-   - Names match the file basename.
-   - Frontmatter `description` is short and human-readable.
-   - Body stays minimal, only what's needed to teach the kind.
-   ```
-
-5. `notes/demo-guideline2.md`, a sibling `markdown` node identical
-   to `demo-guideline`, reached by the same handle plus a `.md`
-   extension (`@demo-guideline2.md`), which makes it a file reference
-   that resolves to this node and lands at full confidence:
-   ```markdown
-   ---
-   name: demo-guideline2
-   description: |
-     Sibling of demo-guideline. The hub reaches it with an
-     `@`-mention that carries the `.md` extension, so the link
-     resolves to this file and lands certain (1.00).
-   ---
-
-   # Demo Guideline 2
-
-   Same conventions as demo-guideline; it exists so the hub can
-   reach it with a resolved reference instead of a bare mention.
-   ```
+Leave the browser open and the terminal with `sm` running. You create five more nodes **without any cross-fixture links** yet, pure standalone nodes, so the tester sees five new nodes pop in. Three new **kinds** show up in this step (skill, command, markdown); the last two files are sibling `markdown` notes (`demo-guideline`, `demo-guideline2`) the hub in the `connectors` chapter reaches two ways, a bare mention that resolves to nothing (which lands as a broken reference, no arrow drawn) and the same handle plus `.md` that resolves to a real file (a solid arrow).
+
+Lay these five files in one go (their content + translation live in `fixtures-data/`). The script resolves `__PROVIDER__` and auto-skips kinds the provider does not claim (`agent-skills` / Antigravity: both `demo-agent` and `demo-command` fold away, only the skill + the three markdown notes remain), so read the actual node count from the summary's `nodeCount`. Backstage (silent):
+
+```
+node .claude/skills/sm-tutorial/scripts/fixtures.js lay prologue --only "__PROVIDER__/skills/demo-skill/SKILL.md,__PROVIDER__/commands/demo-command.md,notes/todo.md,notes/demo-guideline.md,notes/demo-guideline2.md" --provider <provider> --lang <lang>
+```
+
+Adjust the node count, the "five new nodes" message, and the file list shown to the tester in the sample below to match the laid set.
 
 Tell the tester:
 
 > Look at the browser. Five new nodes should have popped in:
 > `demo-skill`, `demo-command`, **Demo TODO list**, `demo-guideline`,
 > and `demo-guideline2`.
-> Six total now, **still unconnected**: they're floating dots.
+> Six total now, **still unconnected**: they're floating nodes.
 > The viewport auto-fits whenever a node is added or removed, so
 > all six should be visible without panning.
 >
 > What I just did behind the scenes: I created five new files in
 > your project, and the watcher picked them up on its own, that's
-> why five new dots appeared without you running anything:
+> why five new nodes appeared without you running anything:
 >
 > - `.claude/skills/demo-skill/SKILL.md` (kind: skill)
 > - `.claude/commands/demo-command.md` (kind: command)
@@ -195,25 +109,20 @@ You edit `notes/todo.md` so it becomes the **hub** that points to each of the ot
 
 Five bullets, three kinds: `invokes` and `mentions` each appear twice, `references` once. The last two bullets are the resolution lesson: a bare `@demo-guideline` mention (which resolves to no agent, so it lands as a broken reference and draws no arrow) next to `@demo-guideline2.md`, the same handle shape plus a `.md` extension that points at a real sibling file (so it resolves and draws a solid arrow). Two separate nodes, one broken and one resolved. Five bullets but only four arrows on the canvas.
 
-Apply with `Edit` on `notes/todo.md` (do not rewrite the file). Per §Provider detection, **substitute `.claude/` with the detected `<provider_dir>` and drop any bullet whose target node was not created in the `kinds` chapter** (on `agent-skills` / Antigravity there is no agent and no command → skip the `@demo-agent` and `/demo-command` bullets; the two guideline bullets stay, so the resolution contrast, broken mention 0.50 (no arrow drawn) vs resolved reference 1.00 (solid arrow), is intact on those providers too).
+Apply the hub bullets (their content + translation live in `fixtures-data/`). The edit appends after the `# Pending` heading; the script drops any bullet whose target kind the provider does not claim (on `agent-skills` / Antigravity there is no agent and no command → the `@demo-agent` and `/demo-command` bullets fold away; the two guideline bullets stay, so the resolution contrast, broken mention 0.50 (no arrow drawn) vs resolved reference 1.00 (solid arrow), is intact on those providers too). Backstage (silent):
 
-**Edit `notes/todo.md`**: append these bullets after the `# Pending` heading:
-
-```markdown
-- [ ] Brief @demo-agent on the rough edges.
-- [ ] Run /demo-command before publishing.
-- [ ] Trigger /demo-skill when the input lands.
-- [ ] Ping @demo-guideline if the conventions change.
-- [ ] Ping @demo-guideline2.md if the conventions change.
+```
+node .claude/skills/sm-tutorial/scripts/fixtures.js edit todo-connectors --provider <provider> --lang <lang>
 ```
 
 Tell the tester:
 
-> Look at the magic again. **Demo TODO list** is now the hub. You
-> wrote five linking bullets, and **four arrows** light up between it
-> and the other nodes, each coloured by the link kind it carries:
+> Look at the magic again. **Demo TODO list** is now the hub. I added
+> five linking bullets to it (open `notes/todo.md` in your editor to
+> see them), and **four arrows** light up between it and the other
+> nodes, each coloured by the link kind it carries:
 >
-> - `Demo TODO list → demo-agent` (kind: `mentions`, the bare `@` handle resolves to a real agent)
+> - `Demo TODO list → demo-agent` (kind: `mentions`, the `@name` mention resolves to a real agent)
 > - `Demo TODO list → demo-command` (kind: `invokes`)
 > - `Demo TODO list → demo-skill` (kind: `invokes`)
 > - `Demo TODO list → demo-guideline2` (kind: `references`, the `@` handle with a `.md` extension)
@@ -224,17 +133,17 @@ Tell the tester:
 > extension turns the name drop into a file pointer.
 >
 > So why four arrows for five bullets? The fifth bullet,
-> `@demo-guideline`, is a bare `@`-mention, and a bare mention only
-> resolves to an *agent*. `demo-guideline` is a note, not an agent, so
-> the mention resolves to nothing: skill-map draws no arrow (there is
-> no node for it to land on) and instead flags the hub with a
+> `@demo-guideline`, is a reference skill-map cannot resolve: an
+> `@name` mention points at an *agent* with that name, and there is no
+> agent called `demo-guideline` (it is a note), so the reference lands
+> on nothing. skill-map draws no arrow and instead flags the hub with a
 > **broken reference**, a red error marker on the **Demo TODO list**
 > card. Compare it with the bullet right after: `@demo-guideline2.md`
-> adds the `.md`, so skill-map reads a file pointer, finds the real
-> `demo-guideline2.md` node, and draws a solid arrow to it. Same
-> handle, one `.md` apart, and one resolves while the other breaks.
-> (That is also why `@demo-agent` drew fine: a bare mention DOES
-> resolve when the target is a real agent.)
+> adds the `.md`, which makes it point at the **file** instead, so
+> skill-map finds the real `demo-guideline2.md` node and draws a solid
+> arrow. Same name, one `.md` apart: one resolves, the other does not.
+> (That is also why `@demo-agent` drew fine: an `@name` mention
+> resolves when an agent by that name really exists.)
 >
 > One word on solidity: skill-map draws each connector's
 > **confidence** as opacity, and every arrow you see here is fully
@@ -249,7 +158,7 @@ Tell the tester:
 > marker on the hub. If an arrow is missing, refresh the browser and
 > let me know.
 
-Expected: four drawn arrows plus one `core/reference-broken` error on `notes/todo.md` for the unresolved `@demo-guideline` mention (the prologue carries this single deliberate error from here on; it is the broken-reference preview the campaign and CLI parts build on). If an arrow is missing, do not advance, the next chapter inspects the same hub edit. Mark `connectors`: done.
+Expected: four drawn arrows plus one `core/reference-broken` error on `notes/todo.md` for the unresolved `@demo-guideline` mention (the broken-reference preview; the tester resolves it by hand in the `edit-link` chapter by adding `.md`, and the campaign and CLI parts re-seed their own pristine copy from `prologue-built`). If an arrow is missing, do not advance, the next chapter inspects the same hub edit. Mark `connectors`: done.
 
 ## Chapter `inspector` - The inspector and connections (~1 min)
 
@@ -262,8 +171,8 @@ The canvas only draws the resolved arrows; the full per-link breakdown, includin
 > first, otherwise it just re-arranges.
 >
 > 🆕 Open the Inspector for **Demo TODO list** (click the node on
-> the map). **Expand** the **Connections** section (it's collapsed
-> by default): it has two sections, **Outgoing** and **Incoming**.
+> the map). Find the **Connections** section: it has two sections,
+> **Outgoing** and **Incoming**.
 > Demo TODO list lists **5 links** under Outgoing (the canvas drew
 > four arrows, but the data keeps the broken `@demo-guideline` mention
 > as a fifth row) and 0 under Incoming. Each row shows the link kind
@@ -286,7 +195,7 @@ Mark `inspector`: done.
 
 ## Chapter `edit-link` - Edit a link, the topology changes (~3 min)
 
-**Context**: the `first-edit` chapter had the tester edit a scalar (`description`) and watch the inspector card refresh. This chapter raises the bar: edit a Markdown link and watch the MAP TOPOLOGY change (a connector disappears).
+**Context**: the `first-edit` chapter had the tester edit a scalar (`description`) and watch the inspector card refresh. This chapter raises the bar: edit Markdown links and watch the MAP TOPOLOGY change both ways, a connector disappears when you remove a link, and a new one appears (clearing the broken-reference error) when you fix the unresolved one.
 
 The server has been live since the `init` chapter, leave it running; this chapter and the next two (the workspace tour, then `.skillmapignore`) reuse it.
 
@@ -297,8 +206,24 @@ The server has been live since the `init` chapter, leave it running; this chapte
 > Expected: the `Demo TODO list → demo-agent` connector (kind:
 > `mentions`) disappears in real time. The two nodes stay in the
 > **Map**; only the edge goes.
+>
+> Tell me when the connector is gone.
 
-You verify by reading `notes/todo.md` to confirm the change was applied. (On `agent-skills`, where the `@demo-agent` bullet was never created in the `connectors` chapter, ask the tester to remove the only bullet they did add and watch THAT connector vanish, the lesson is the same.) Once they confirm, leave the server running, the next chapter reuses it. Mark `edit-link`: done.
+Once they confirm, the second edit fixes the broken reference. Tell the tester:
+
+> Now the other direction, fix the broken link. Edit `notes/todo.md`
+> again and add the `.md` extension to the `@demo-guideline` bullet so
+> it reads `@demo-guideline.md`. Save.
+>
+> Expected: a NEW arrow appears, `Demo TODO list → demo-guideline`
+> (kind: `references`), and the red broken-reference marker on the hub
+> clears. The `.md` turned the unresolved mention into a file
+> reference that lands on the real `demo-guideline.md`, the same fix
+> you saw side by side in the connectors chapter, now done by hand.
+>
+> Confirm when the new arrow is in and the red marker is gone.
+
+You verify by reading `notes/todo.md` to confirm both edits landed (the `@demo-agent` bullet gone, `@demo-guideline` now `@demo-guideline.md`); the prologue's broken reference is now resolved. (On `agent-skills`, where the `@demo-agent` bullet was never created in the `connectors` chapter, ask the tester to remove the only bullet they did add for the first edit; the `.md` fix on `@demo-guideline` is identical.) Once they confirm, leave the server running, the next chapter reuses it. Mark `edit-link`: done.
 
 ## Chapter `workspace` - Navigate the workspace (files, search, isolate) (~2 min)
 
@@ -306,7 +231,11 @@ You verify by reading `notes/todo.md` to confirm the change was applied. (On `ag
 
 Per §Provider detection, on `agent-skills` / Antigravity the fixture has fewer nodes (`demo-skill` plus the two `notes/` files), so swap the node names below for ones that exist in that set; the gestures are identical.
 
-**Beat 1, open the Files panel (tester does this).**
+Walk the three tester actions below one at a time (open the Files
+panel, then search, then isolate); each ends with its own
+confirmation, so present one and wait for the tester before the next.
+Do NOT prepend an intro line to a block, each already opens with the
+action itself.
 
 > Open the **Files** panel. It sits collapsed against the left edge
 > by default: click the expand handle there (the `>` arrow, its
@@ -317,8 +246,6 @@ Per §Provider detection, on `agent-skills` / Antigravity the fixture has fewer
 >
 > Tell me when the tree is open.
 
-**Beat 2, search (tester does this).**
-
 > At the top of that sidebar there's a search box (placeholder
 > `Search…`). Type `guideline`. Watch both halves at once: the tree
 > narrows down to the two guideline nodes (`demo-guideline` and
@@ -329,8 +256,6 @@ Per §Provider detection, on `agent-skills` / Antigravity the fixture has fewer
 > Now clear the box. All six nodes come back, in both the tree and
 > the Map. Confirm you saw it filter and then restore.
 
-**Beat 3, isolate (tester does this).**
-
 > Last one. In the tree, find the **Demo TODO list** row: at its
 > right edge there's a small **sitemap** icon (its tooltip reads
 > "Isolate this node and its direct links on the map"). Click it.
@@ -363,20 +288,10 @@ Earlier chapters showed the watcher picking up new files and edits (yours and th
 
 **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:
-
-```markdown
----
-name: private-credentials
-description: |
-  Personal API tokens, exists in the repo but should not show
-  up in skill-map's map. Demonstrates the .skillmapignore
-  flow.
----
+Lay `notes/private-credentials.md`, kind `markdown`, which simulates a file the tester would never want surfacing publicly (its content + translation live in `fixtures-data/`). Backstage (silent):
 
-# Private
-
-API_TOKEN: example-not-real
+```
+node .claude/skills/sm-tutorial/scripts/fixtures.js lay prologue --only "notes/private-credentials.md" --provider <provider> --lang <lang>
 ```
 
 It lands in the map as a seventh 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.

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

@@ -17,7 +17,7 @@ Before announcing the first step, verify the fixture is initialised
 `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
+bootstrap mismatch ("tutorial-state.json says we are running, but
 the bootstrap is missing. Re-run the tutorial from an empty dir or
 restore the files.") and stop.
 
@@ -189,8 +189,7 @@ Mark `tour-3-explore: done`.
 >
 > Anything weird worth logging? If not, back to the menu.
 
-Mark the plugins chapters done in `tutorial-state.yml`, update the
-matching harness task, return to the menu in `SKILL.md`.
+Mark the chapters done (rule #4) and return to the menu in `SKILL.md`.
 
 ## Reference: how `sm` decides what to load
 

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

@@ -65,16 +65,18 @@ Tell the tester:
 
 Wait for confirmation. Mark `kickoff`: done.
 
-## Chapter `manual` - The handbook and CLAUDE.md (~2 min)
+## Chapter `manual` - The handbook (AGENTS.md) and CLAUDE.md (~2 min)
 
 **Context**: the dogfood beat. Real Claude Code projects can
 reference the generic `AGENTS.md` from their `CLAUDE.md` (this very
 repo does). That one-line pointer is a real `references` link (the
-`.md` extension makes `@AGENTS.md` a file pointer, not a bare
-mention), the tester's first connector on the real project.
+`.md` extension makes `@AGENTS.md` a file pointer), the tester's first
+connector on the real project.
 
 Tell the tester to create the file themselves (it is their project's
-file, Inviolable rule #2):
+file, Inviolable rule #2). Backstage, get the content:
+`node .claude/skills/sm-tutorial/scripts/fixtures.js cat portfolio --file "CLAUDE.md" --provider <provider> --lang <lang>`,
+then render it in the fenced block the tester copies:
 
 > Create a file called `CLAUDE.md` at the project root with exactly
 > this content:
@@ -87,7 +89,7 @@ file, Inviolable rule #2):
 > `references` connector pointing at `AGENTS.md`, solid at 1.00.
 > Because `@AGENTS.md` carries the `.md` extension, skill-map reads it
 > as a file pointer (the same `@name.md` reference you met in the
-> prologue, not a bare mention), and since the handbook is right there
+> prologue), and since the handbook is right there
 > the link resolves with full confidence. It tells anyone (and
 > skill-map) that `CLAUDE.md` defers to the handbook. This is exactly
 > how this tool's own repo is wired.
@@ -98,33 +100,13 @@ Wait for confirmation. Mark `manual`: done.
 
 ## Chapter `first-agent` - The first harness agent (~2 min)
 
-`Write` `.claude/agents/content-editor.md` (substitute
-`<provider_dir>` per `_core.md`; on `agent-skills` / Antigravity,
-which has no `agent` kind, create a `skill` instead and adjust the
-prose):
-
-```markdown
----
-name: content-editor
-description: |
-  Writes and edits the portfolio's pages. Reads a brief, follows the
-  style guide, and emits the HTML into public/.
-tools: [Read, Write]
-model: sonnet
----
-
-# content-editor
-
-Turns a short brief into a finished portfolio page.
-
-## How to write a page
-1. Read the style guide and the shared stylesheet in public/.
-2. Write one HTML file under public/, named after the page (a projects page becomes `public/projects.html`).
-3. Start from `<!doctype html>`, link the stylesheet with `<link rel="stylesheet" href="/style.css">`, and set a `<title>`.
-4. Use one `<h1>`, group sections under `<h2>`, and reuse the shared header, nav, and footer so every page matches.
-5. Add a link back to Home, and link the new page from the home nav.
-
-Rules: plain static HTML, no framework, no client JS, one page per file.
+Lay the first harness agent (its content + translation live in
+`fixtures-data/`). The script resolves `__PROVIDER__`; on
+`agent-skills` / Antigravity, which has no `agent` kind, adjust the
+prose to the skill the set lays there. Backstage (silent):
+
+```
+node .claude/skills/sm-tutorial/scripts/fixtures.js lay portfolio --only "__PROVIDER__/agents/content-editor.md" --provider <provider> --lang <lang>
 ```
 
 Tell the tester:
@@ -134,6 +116,11 @@ Tell the tester:
 > `agent` node appeared on the map. Right now it stands alone; in the
 > next part we wire it to the handbook and the style guide.
 >
+> 💡 Tip: I create these harness files for you. If you'd like to see
+> what's inside, open `<provider_dir>/agents/content-editor.md` in your
+> editor, and feel free to peek at the files I add in the coming
+> chapters too.
+>
 > See the new agent node?
 
 Wait for confirmation. Mark `first-agent`: done.
@@ -145,45 +132,11 @@ 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 the Daily Loop's maintenance beats have something to point at.
 
-`Write` two docs (markdown kind):
-
-`docs/STYLE.md`:
-```markdown
----
-name: style-guide
-description: |
-  Writing and markup conventions every portfolio page follows.
----
-
-# Style guide
+Lay the two markdown docs the harness references later (their content
++ translation live in `fixtures-data/`). Backstage (silent):
 
-## Voice
-- Short, plain sentences. No marketing fluff.
-
-## Structure
-- One H1 per page; sections under H2.
-- Every page shares the same header, nav, and footer.
-- Every page links back to Home.
-
-## Markup
-- Plain static HTML: no framework, no client JS.
-- Link the shared stylesheet `/style.css` in every page head.
-- Use semantic tags: header, nav, main, footer.
 ```
-
-`docs/DEPLOY.md`:
-```markdown
----
-name: deploy-runbook
-description: |
-  How the portfolio gets published once the pages are written.
----
-
-# Deploy runbook
-
-1. Generate or update the pages in public/.
-2. Run the link check and fix anything it reports.
-3. Start the server with `node server.js`, then open the site in your browser.
+node .claude/skills/sm-tutorial/scripts/fixtures.js lay portfolio --only "docs/STYLE.md,docs/DEPLOY.md" --provider <provider> --lang <lang>
 ```
 
 Tell the tester: