@skill-map/cli 0.53.2 → 0.53.3
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.
- package/dist/cli/tutorial/sm-tutorial/SKILL.md +19 -10
- package/dist/cli/tutorial/sm-tutorial/references/_core.md +53 -5
- package/dist/cli/tutorial/sm-tutorial/references/_manifest.yml +22 -9
- package/dist/cli/tutorial/sm-tutorial/references/fixtures.md +10 -13
- package/dist/cli/tutorial/sm-tutorial/references/part-authoring.md +2 -2
- package/dist/cli/tutorial/sm-tutorial/references/part-cli.md +1 -1
- package/dist/cli/tutorial/sm-tutorial/references/part-connect-harness.md +12 -9
- package/dist/cli/tutorial/sm-tutorial/references/part-fundamentals.md +16 -22
- package/dist/cli/tutorial/sm-tutorial/references/part-live-site.md +111 -112
- package/dist/cli/tutorial/sm-tutorial/references/part-maintain.md +2 -2
- package/dist/cli/tutorial/sm-tutorial/references/part-mcp.md +4 -4
- package/dist/cli/tutorial/sm-tutorial/references/part-plugins.md +1 -1
- package/dist/cli/tutorial/sm-tutorial/references/part-project-kickoff.md +11 -13
- package/dist/cli/tutorial/sm-tutorial/references/part-run-harness.md +155 -0
- package/dist/cli/tutorial/sm-tutorial/references/part-settings.md +2 -2
- package/dist/cli.js +3 -3
- package/dist/index.js +3 -3
- package/dist/kernel/index.js +3 -3
- package/dist/ui/{chunk-UHNBYD6J.js → chunk-22XUPND3.js} +3 -3
- package/dist/ui/{chunk-OFDQMBSJ.js → chunk-4CXAL43H.js} +1 -1
- package/dist/ui/{chunk-IUZM6XLN.js → chunk-HWQTV6ZL.js} +1 -1
- package/dist/ui/{chunk-UV5Q423S.js → chunk-ISIHN6HU.js} +2 -2
- package/dist/ui/{chunk-EQ72PEHT.js → chunk-NBXEOYS4.js} +1 -1
- package/dist/ui/index.html +2 -2
- package/dist/ui/{main-TXPLL7VU.js → main-Z4RJNI4X.js} +3 -3
- package/dist/ui/{styles-Q4NCOJQY.css → styles-L6FZYH7X.css} +1 -1
- package/package.json +1 -1
|
@@ -1,62 +1,57 @@
|
|
|
1
|
-
# Part
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
1
|
+
# Part 6: Ship the site (the full publish pipeline) (step library, finale, `pipeline` + `golive`)
|
|
2
|
+
|
|
3
|
+
The finale, the climax of the whole campaign. In Part 3 you ran the
|
|
4
|
+
harness once, the simple way (generate two pages, serve them). Here you
|
|
5
|
+
operate it exactly as it was designed: you drive the `/publish` command
|
|
6
|
+
end to end, the way the handbook says to ship, and put a richer
|
|
7
|
+
multi-page site live next to the full graph. Pace `auto-advance`,
|
|
8
|
+
preflight `seed` (`harness-connected`), so a tester can jump straight
|
|
9
|
+
here. Two chapters, in order: `pipeline` (run `/publish`: check the
|
|
10
|
+
links, brief the editor, follow the deploy runbook) then `golive` (run
|
|
11
|
+
the server and click through the finished site). Shared conventions
|
|
12
|
+
live in `_core.md`.
|
|
13
|
+
|
|
14
|
+
## Chapter `pipeline` - Run /publish end to end (check-links, brief, deploy runbook) (~4 min)
|
|
15
|
+
|
|
16
|
+
**Context**: the harness is not just a picture, it is a set of
|
|
17
|
+
instructions, and `/publish` is the one that ties them together. Its
|
|
18
|
+
body says: run `/check-links`, brief `@content-editor` on any fix, then
|
|
19
|
+
follow the deploy runbook. Here the tester (playing the harness) walks
|
|
20
|
+
exactly those steps on a richer site. This is still Layer 1 vs Layer 2:
|
|
21
|
+
the pages are output, so the Map stays put while the files change, same
|
|
22
|
+
as Part 3, no need to re-teach it, just do not call it a bug if they
|
|
23
|
+
notice.
|
|
24
|
+
|
|
25
|
+
**Preparation** (the agent does this, playing `content-editor`):
|
|
26
|
+
|
|
27
|
+
1. Ensure the two base pages exist. If they are not already on disk
|
|
28
|
+
from Part 3 (a tester can land here via the seed), lay
|
|
29
|
+
`public/index.html` and `public/about.html` exactly as in
|
|
30
|
+
part-run-harness.md, chapter `generate`. They are the single source
|
|
31
|
+
for those two pages; do not restate their markup, copy it from
|
|
32
|
+
there.
|
|
33
|
+
2. Add a **Projects** link to the home nav. `Edit` `public/index.html`,
|
|
34
|
+
turning the About line of the nav into:
|
|
35
|
+
|
|
29
36
|
```html
|
|
30
|
-
|
|
31
|
-
<
|
|
32
|
-
<head>
|
|
33
|
-
<meta charset="utf-8" />
|
|
34
|
-
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
35
|
-
<title>My Portfolio</title>
|
|
36
|
-
</head>
|
|
37
|
-
<body>
|
|
38
|
-
<h1>My Portfolio</h1>
|
|
39
|
-
<p>Hi, I build small, sturdy things on the web.</p>
|
|
40
|
-
<nav>
|
|
41
|
-
<a href="/">Home</a> ·
|
|
42
|
-
<a href="/about.html">About</a>
|
|
43
|
-
</nav>
|
|
44
|
-
</body>
|
|
45
|
-
</html>
|
|
37
|
+
<a href="/about.html">About</a> ·
|
|
38
|
+
<a href="/projects.html">Projects</a>
|
|
46
39
|
```
|
|
47
40
|
|
|
48
|
-
`public/
|
|
41
|
+
3. `Write` the new page `public/projects.html` (plain markup, links
|
|
42
|
+
back home, per the style guide):
|
|
43
|
+
|
|
49
44
|
```html
|
|
50
45
|
<!doctype html>
|
|
51
46
|
<html lang="en">
|
|
52
47
|
<head>
|
|
53
48
|
<meta charset="utf-8" />
|
|
54
49
|
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
55
|
-
<title>
|
|
50
|
+
<title>Projects</title>
|
|
56
51
|
</head>
|
|
57
52
|
<body>
|
|
58
|
-
<h1>
|
|
59
|
-
<p>A
|
|
53
|
+
<h1>Projects</h1>
|
|
54
|
+
<p>A few small things I have shipped.</p>
|
|
60
55
|
<nav>
|
|
61
56
|
<a href="/">Home</a>
|
|
62
57
|
</nav>
|
|
@@ -65,47 +60,57 @@ the markup plain.
|
|
|
65
60
|
```
|
|
66
61
|
|
|
67
62
|
```bash
|
|
68
|
-
#
|
|
63
|
+
# Still nothing to run in the terminal. The publish steps below are
|
|
64
|
+
# you walking the harness; the server comes in the next chapter.
|
|
69
65
|
```
|
|
70
66
|
|
|
71
67
|
Tell the tester:
|
|
72
68
|
|
|
73
|
-
>
|
|
74
|
-
> `
|
|
75
|
-
>
|
|
76
|
-
>
|
|
77
|
-
>
|
|
78
|
-
> guide you set up earlier.
|
|
69
|
+
> Time to ship it the way your handbook says to. Open
|
|
70
|
+
> `.claude/commands/publish.md` and look at its steps: that command is
|
|
71
|
+
> the recipe, and you are about to run it by hand, the way the agent
|
|
72
|
+
> would. Three pages now live under `public/`: home, about, and a new
|
|
73
|
+
> projects page, with the home nav linking all three.
|
|
79
74
|
>
|
|
80
|
-
>
|
|
81
|
-
>
|
|
82
|
-
>
|
|
83
|
-
>
|
|
84
|
-
>
|
|
85
|
-
> `.md`), so writing real site files leaves the graph untouched. Two
|
|
86
|
-
> layers, one project: the graph that builds the site, and the site
|
|
87
|
-
> itself.
|
|
75
|
+
> **Step 1, check the links** (`/check-links`). Walk the three pages
|
|
76
|
+
> and follow every internal link: `/` resolves to the home page,
|
|
77
|
+
> `/about.html` and `/projects.html` to files that exist, and each
|
|
78
|
+
> page links back home. Nothing points at a missing file, so the link
|
|
79
|
+
> check is clean.
|
|
88
80
|
>
|
|
89
|
-
>
|
|
81
|
+
> **Step 2, brief the editor** (`@content-editor`). The check found
|
|
82
|
+
> nothing to fix, so there is no brief to hand off this time, that is
|
|
83
|
+
> the happy path. (Part 4 is where a link actually breaks and this
|
|
84
|
+
> step earns its keep.)
|
|
85
|
+
>
|
|
86
|
+
> **Step 3, follow the deploy runbook** (`docs/DEPLOY.md`). It lists:
|
|
87
|
+
> generate the pages (done), run the link check (done), start the
|
|
88
|
+
> server (next chapter). You have walked the whole `/publish` flow.
|
|
89
|
+
>
|
|
90
|
+
> Glance at the Map one more time: it did not move while you added a
|
|
91
|
+
> page and ran the pipeline. The pages are Layer 2 output; the harness
|
|
92
|
+
> on the canvas is Layer 1, and that is what skill-map maps.
|
|
93
|
+
>
|
|
94
|
+
> Ready to put it live?
|
|
90
95
|
|
|
91
|
-
Wait for confirmation.
|
|
92
|
-
|
|
96
|
+
Wait for confirmation. You MAY `Read` the three files in `public/`
|
|
97
|
+
afterwards to confirm the edit and the new page landed. Mark
|
|
98
|
+
`pipeline`: done. Auto-advance to `golive`.
|
|
93
99
|
|
|
94
|
-
## Chapter `
|
|
100
|
+
## Chapter `golive` - Ship it: the richer site live next to the full graph (~3 min)
|
|
95
101
|
|
|
96
|
-
**Context**: the climax. The tester
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
`node server.js`); guide them, do not run it for them.
|
|
102
|
+
**Context**: the climax. The tester starts the tiny Express server the
|
|
103
|
+
pre-flight left in `server.js` and clicks through the three-page site,
|
|
104
|
+
ending with the running portfolio on one side and the full skill-map
|
|
105
|
+
graph of the harness that built it on the other. This is one of the
|
|
106
|
+
few chapters where the tester runs non-`sm` commands themselves
|
|
107
|
+
(`npm install`, `node server.js`); guide them, do not run it for them.
|
|
108
|
+
`npm install` is idempotent, so it is safe whether or not they already
|
|
109
|
+
ran it in Part 3.
|
|
105
110
|
|
|
106
|
-
**Preparation**: none. `server.js` and `package.json`
|
|
107
|
-
|
|
108
|
-
|
|
111
|
+
**Preparation**: none. `server.js` and `package.json` exist from the
|
|
112
|
+
kickoff pre-flight; the three pages exist from the `pipeline` chapter.
|
|
113
|
+
The tester runs everything here.
|
|
109
114
|
|
|
110
115
|
```bash
|
|
111
116
|
npm install
|
|
@@ -114,43 +119,37 @@ node server.js
|
|
|
114
119
|
|
|
115
120
|
Tell the tester:
|
|
116
121
|
|
|
117
|
-
> Last step,
|
|
118
|
-
> serve them. In your terminal, run these two commands:
|
|
119
|
-
>
|
|
120
|
-
> The first, `npm install`, downloads the one small library the
|
|
121
|
-
> server needs (Express, a tiny web server). It runs on Node, which
|
|
122
|
-
> you already installed at the very start, so there is nothing new to
|
|
123
|
-
> set up.
|
|
122
|
+
> Last step, the fun one. In your terminal, run these two commands:
|
|
124
123
|
>
|
|
125
|
-
>
|
|
126
|
-
>
|
|
127
|
-
>
|
|
124
|
+
> `npm install` downloads the one small library the server needs
|
|
125
|
+
> (Express). If you already ran it in Part 3 it just confirms it is
|
|
126
|
+
> there. Then `node server.js` starts the server; it prints a line
|
|
127
|
+
> like `Listening on http://localhost:3000`.
|
|
128
128
|
>
|
|
129
|
-
> Open `http://localhost:3000
|
|
130
|
-
>
|
|
131
|
-
>
|
|
129
|
+
> Open `http://localhost:3000`. Click **About**, **Projects**, and
|
|
130
|
+
> **Home** to move between all three pages. Those are the pages your
|
|
131
|
+
> harness produced, shipped through the publish flow you just ran by
|
|
132
|
+
> hand.
|
|
132
133
|
>
|
|
133
|
-
> Now take
|
|
134
|
-
>
|
|
135
|
-
>
|
|
136
|
-
>
|
|
137
|
-
>
|
|
138
|
-
>
|
|
139
|
-
> map of how it all fits.
|
|
134
|
+
> Now take it all in at once. On one side, the real running site you
|
|
135
|
+
> can click through. On the other, the skill-map graph of the harness
|
|
136
|
+
> that built it: the handbook, the content editor, the style guide,
|
|
137
|
+
> the publish command, the link checker, the MCP tool, all wired
|
|
138
|
+
> together. You started in an empty folder with nothing, and you have
|
|
139
|
+
> ended with a real, running site and a living map of how it all fits.
|
|
140
140
|
>
|
|
141
|
-
> Does the site load, and can you click between Home and
|
|
141
|
+
> Does the site load, and can you click between Home, About and
|
|
142
|
+
> Projects?
|
|
142
143
|
|
|
143
144
|
Wait for confirmation. The tester runs the commands; do not run them
|
|
144
145
|
for them. If `npm install` fails, check they are in the project root
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
campaign spine is complete; the final wrap-up in `_core.md` applies
|
|
156
|
-
when the tester signals they are finished).
|
|
146
|
+
and Node is on PATH (`node --version` should print 24 or higher). If
|
|
147
|
+
the port is busy, stop the server with Ctrl+C and apply the ports edge
|
|
148
|
+
case. Remind them the server stays running until they press Ctrl+C.
|
|
149
|
+
|
|
150
|
+
This is the campaign finale. Congratulate them plainly: they went from
|
|
151
|
+
an empty directory to a real, running portfolio plus a complete map of
|
|
152
|
+
its harness. Mark `golive`: done. Last chapter of the part: apply
|
|
153
|
+
§Closing a part (name the part by its title; since this closes the
|
|
154
|
+
campaign spine, if every active part is now done route to the §Final
|
|
155
|
+
wrap-up instead of the menu).
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Part
|
|
1
|
+
# Part 4: Maintain the site (step library, `maintain`)
|
|
2
2
|
|
|
3
3
|
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.
|
|
4
4
|
|
|
@@ -283,4 +283,4 @@ sm history content-editor
|
|
|
283
283
|
>
|
|
284
284
|
> Does `sm history` show the bump you just made?
|
|
285
285
|
|
|
286
|
-
Wait for confirmation. Mark `versions`: done.
|
|
286
|
+
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).
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Part
|
|
1
|
+
# Part 5: MCP (step library, `mcp-*` ids)
|
|
2
2
|
|
|
3
3
|
This is a chapter apart, the one just before the finale. Pace
|
|
4
4
|
`auto-advance`, preflight `reuse` (it builds straight on the
|
|
@@ -73,6 +73,6 @@ Tell the tester:
|
|
|
73
73
|
Wait for confirmation. If the node did not appear, have the tester
|
|
74
74
|
save the file again (the watcher reacts on save) or refresh the
|
|
75
75
|
browser, then re-check; the `tools:` line must be valid YAML on one
|
|
76
|
-
line. Mark `mcp-node`: done.
|
|
77
|
-
|
|
78
|
-
next on the spine).
|
|
76
|
+
line. Mark `mcp-node`: done. Last chapter of the part: apply §Closing
|
|
77
|
+
a part (the close names the part by its title and routes back to the
|
|
78
|
+
menu; the full publish finale is next on the spine).
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Part
|
|
1
|
+
# Part 7 (b): Extend skill-map - plugins (step library, `tour-*` ids)
|
|
2
2
|
|
|
3
3
|
Guided tour of the **built-in plugins** that ship with `sm`. Three
|
|
4
4
|
steps: a quick mental model of what plugins are plus a peek at
|
|
@@ -5,8 +5,8 @@ starts an actual project: a tiny personal **portfolio website**,
|
|
|
5
5
|
fully static, served by a ~15-line Express server, plus the
|
|
6
6
|
`.claude/` **harness** that maintains it. skill-map maps the harness
|
|
7
7
|
(the `.md` assets and how they reference each other); the site itself
|
|
8
|
-
is plain HTML the harness produces (Part
|
|
9
|
-
|
|
8
|
+
is plain HTML the harness produces (Part 3 runs it, Part 6 ships it).
|
|
9
|
+
`pace: per-step`, `preflight: portfolio-init`. Shared
|
|
10
10
|
conventions live in `_core.md`.
|
|
11
11
|
|
|
12
12
|
The orchestrator's `portfolio-init` pre-flight (backstage, silent)
|
|
@@ -125,7 +125,7 @@ Wait for confirmation. Mark `first-agent`: done.
|
|
|
125
125
|
**Context**: the prologue showed the four kinds on abstract demo
|
|
126
126
|
nodes. Now name them on the real project, and add the two markdown
|
|
127
127
|
docs the harness references later (the style guide and the deploy
|
|
128
|
-
runbook), so Part
|
|
128
|
+
runbook), so Part 4's maintenance beats have something to point at.
|
|
129
129
|
|
|
130
130
|
`Write` two docs (markdown kind):
|
|
131
131
|
|
|
@@ -171,16 +171,14 @@ Tell the tester:
|
|
|
171
171
|
> - **agent**: `content-editor` (does work on your behalf).
|
|
172
172
|
> - **markdown**: `AGENTS.md`, `CLAUDE.md`, the two docs (plain notes
|
|
173
173
|
> and manuals).
|
|
174
|
-
> - **skill** and **command**:
|
|
175
|
-
> the
|
|
176
|
-
> together.
|
|
174
|
+
> - **skill** and **command**: you add these (the link checker and
|
|
175
|
+
> the publish command) in a later part.
|
|
177
176
|
>
|
|
178
|
-
> Your handbook now has a real harness around it
|
|
179
|
-
>
|
|
180
|
-
> skill, the whole graph lighting up.
|
|
177
|
+
> Your handbook now has a real harness around it: a `content-editor`
|
|
178
|
+
> agent plus its docs, all on the map.
|
|
181
179
|
>
|
|
182
|
-
>
|
|
180
|
+
> See the agent and the docs in the map?
|
|
183
181
|
|
|
184
|
-
Wait for confirmation. Mark `real-kinds`: done.
|
|
185
|
-
|
|
186
|
-
|
|
182
|
+
Wait for confirmation. Mark `real-kinds`: done. Last chapter of the
|
|
183
|
+
part: apply §Closing a part (the close names the part by its title and
|
|
184
|
+
routes back to the menu; do NOT lead into the next part from here).
|
|
@@ -0,0 +1,155 @@
|
|
|
1
|
+
# Part 3: Run the harness (your site, live) (step library, `generate` + `serve`)
|
|
2
|
+
|
|
3
|
+
The first payoff: the harness you built and wired in the earlier parts
|
|
4
|
+
finally does its job and you see a real site running, without waiting
|
|
5
|
+
for the finale. Pace `auto-advance`, preflight `seed` (`harness-connected`,
|
|
6
|
+
so a tester can jump straight here). Two chapters, in order:
|
|
7
|
+
`generate` (the agent writes the HTML pages) then `serve` (the tester
|
|
8
|
+
runs the site and sees it next to the graph). This is a deliberately
|
|
9
|
+
simple, working pass: maintenance, MCP and the full publish pipeline
|
|
10
|
+
come in the parts after it. Shared conventions live in `_core.md`.
|
|
11
|
+
|
|
12
|
+
These two HTML pages are the canonical site fixture: the full
|
|
13
|
+
publish finale (`live-site`) lays the same `public/index.html` and
|
|
14
|
+
`public/about.html` from here before adding its own extra page, so keep
|
|
15
|
+
them in sync here only.
|
|
16
|
+
|
|
17
|
+
## Chapter `generate` - The agent generates the HTML in public/ (~3 min)
|
|
18
|
+
|
|
19
|
+
**Context**: the `content-editor` agent exists to write the site's
|
|
20
|
+
pages, so now you (playing that agent) generate the actual HTML into
|
|
21
|
+
`public/`. The honest beat the tester must hear: writing HTML does NOT
|
|
22
|
+
move the skill-map graph. The graph is Layer 1, the `.md` harness that
|
|
23
|
+
builds the site; the HTML is Layer 2, the harness's OUTPUT, and
|
|
24
|
+
skill-map does not map it (HTML is not `.md`). So the Map will sit
|
|
25
|
+
still while real files land on disk, and that is correct, not a bug.
|
|
26
|
+
Keep the markup plain per the style guide: no framework, no client JS,
|
|
27
|
+
one H1 per page, every page links back home.
|
|
28
|
+
|
|
29
|
+
**Preparation**: `Write` two static pages into `public/`. The
|
|
30
|
+
pre-flight already left a placeholder `public/index.html`; this
|
|
31
|
+
overwrites it with the real home page and adds an about page. Keep the
|
|
32
|
+
markup plain.
|
|
33
|
+
|
|
34
|
+
`public/index.html`:
|
|
35
|
+
```html
|
|
36
|
+
<!doctype html>
|
|
37
|
+
<html lang="en">
|
|
38
|
+
<head>
|
|
39
|
+
<meta charset="utf-8" />
|
|
40
|
+
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
41
|
+
<title>My Portfolio</title>
|
|
42
|
+
</head>
|
|
43
|
+
<body>
|
|
44
|
+
<h1>My Portfolio</h1>
|
|
45
|
+
<p>Hi, I build small, sturdy things on the web.</p>
|
|
46
|
+
<nav>
|
|
47
|
+
<a href="/">Home</a> ·
|
|
48
|
+
<a href="/about.html">About</a>
|
|
49
|
+
</nav>
|
|
50
|
+
</body>
|
|
51
|
+
</html>
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
`public/about.html`:
|
|
55
|
+
```html
|
|
56
|
+
<!doctype html>
|
|
57
|
+
<html lang="en">
|
|
58
|
+
<head>
|
|
59
|
+
<meta charset="utf-8" />
|
|
60
|
+
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
61
|
+
<title>About</title>
|
|
62
|
+
</head>
|
|
63
|
+
<body>
|
|
64
|
+
<h1>About</h1>
|
|
65
|
+
<p>A short page about the person behind the portfolio.</p>
|
|
66
|
+
<nav>
|
|
67
|
+
<a href="/">Home</a>
|
|
68
|
+
</nav>
|
|
69
|
+
</body>
|
|
70
|
+
</html>
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
```bash
|
|
74
|
+
# Nothing for you to run yet. Look at both halves of your screen.
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
Tell the tester:
|
|
78
|
+
|
|
79
|
+
> Your `content-editor` agent just did its real job: it wrote the
|
|
80
|
+
> actual web pages. Two HTML files landed in your project under
|
|
81
|
+
> `public/`: the home page (`public/index.html`) and an about page
|
|
82
|
+
> (`public/about.html`), plain static markup that follows the style
|
|
83
|
+
> guide you set up earlier.
|
|
84
|
+
>
|
|
85
|
+
> Now glance at the Map. It did not change, and that is exactly
|
|
86
|
+
> right. Everything you watched grow on the canvas is your harness:
|
|
87
|
+
> the `.md` files and how they reference each other (call that
|
|
88
|
+
> Layer 1). The HTML pages are Layer 2, what the harness PRODUCES.
|
|
89
|
+
> skill-map maps the harness, not the pages it outputs (HTML is not
|
|
90
|
+
> `.md`), so writing real site files leaves the graph untouched. Two
|
|
91
|
+
> layers, one project: the graph that builds the site, and the site
|
|
92
|
+
> itself.
|
|
93
|
+
>
|
|
94
|
+
> Ready to see the site running?
|
|
95
|
+
|
|
96
|
+
Wait for confirmation. Mark `generate`: done. Auto-advance to `serve`.
|
|
97
|
+
|
|
98
|
+
## Chapter `serve` - node server.js: your portfolio, live next to the graph (~3 min)
|
|
99
|
+
|
|
100
|
+
**Context**: the tester installs the single dependency (Express) and
|
|
101
|
+
starts the tiny server that the pre-flight already left in
|
|
102
|
+
`server.js`, then opens the site in the browser. They end with two
|
|
103
|
+
things side by side: the real portfolio they can click through, and
|
|
104
|
+
the skill-map graph of the harness that built it. Express runs on
|
|
105
|
+
Node, which the tester has from pre-flight (Node 24+), so no new
|
|
106
|
+
install beyond `npm install`. This chapter is one of the few where the
|
|
107
|
+
tester runs a non-`sm` command themselves (`npm install`,
|
|
108
|
+
`node server.js`); guide them, do not run it for them.
|
|
109
|
+
|
|
110
|
+
**Preparation**: none. `server.js` and `package.json` already exist
|
|
111
|
+
from the kickoff pre-flight; the pages exist from the `generate`
|
|
112
|
+
chapter. The tester runs everything in this chapter.
|
|
113
|
+
|
|
114
|
+
```bash
|
|
115
|
+
npm install
|
|
116
|
+
node server.js
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
Tell the tester:
|
|
120
|
+
|
|
121
|
+
> You have the pages; now let's serve them. In your terminal, run
|
|
122
|
+
> these two commands:
|
|
123
|
+
>
|
|
124
|
+
> The first, `npm install`, downloads the one small library the
|
|
125
|
+
> server needs (Express, a tiny web server). It runs on Node, which
|
|
126
|
+
> you already installed at the very start, so there is nothing new to
|
|
127
|
+
> set up.
|
|
128
|
+
>
|
|
129
|
+
> The second, `node server.js`, starts the server. It prints a line
|
|
130
|
+
> telling you it is listening, something like `Listening on
|
|
131
|
+
> http://localhost:3000`.
|
|
132
|
+
>
|
|
133
|
+
> Open `http://localhost:3000` in your browser. There it is: your
|
|
134
|
+
> portfolio, live. Click the **About** link, then the **Home** link
|
|
135
|
+
> to come back. Those are the very pages your harness produced.
|
|
136
|
+
>
|
|
137
|
+
> Take a second to look at both halves: on one side the running site
|
|
138
|
+
> you can click through, on the other the skill-map graph of the
|
|
139
|
+
> harness that built it. You built the harness, wired it, and now you
|
|
140
|
+
> have run it once end to end.
|
|
141
|
+
>
|
|
142
|
+
> Does the site load, and can you click between Home and About?
|
|
143
|
+
|
|
144
|
+
Wait for confirmation. The tester runs the commands; do not run them
|
|
145
|
+
for them. If `npm install` fails, check they are in the project root
|
|
146
|
+
(the cwd they have used all along) and that Node is on PATH (`node
|
|
147
|
+
--version` should print 24 or higher). If the port is busy, they can
|
|
148
|
+
stop the server with Ctrl+C and the edge case for ports applies the
|
|
149
|
+
same as elsewhere. Remind them they can leave the server running or
|
|
150
|
+
stop it with Ctrl+C; either way the next parts do not need it.
|
|
151
|
+
|
|
152
|
+
Mark `serve`: done. Last chapter of the part: apply §Closing a part
|
|
153
|
+
(the close names the part by its title and routes back to the menu;
|
|
154
|
+
this is a mid-campaign payoff, NOT the campaign finale, so do not
|
|
155
|
+
sign the campaign off here).
|
|
@@ -1,6 +1,6 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Part 7 (a): Extend skill-map - settings (step library, `settings-*` ids)
|
|
2
2
|
|
|
3
|
-
Step bodies for the settings chapters of Part
|
|
3
|
+
Step bodies for the settings chapters of Part 7 (config layers, the
|
|
4
4
|
`sm config` verbs, the active provider lens), plus the shared step
|
|
5
5
|
`settings-6-contributions` that the plugin-authoring chapters reuse.
|
|
6
6
|
The SKILL.md orchestrator dispatches each `settings-*` chapter id
|
package/dist/cli.js
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
// cli/entry.ts
|
|
2
2
|
|
|
3
|
-
!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="
|
|
3
|
+
!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="542dae21-a4ed-50bb-ad3c-62e84e47b380")}catch(e){}}();
|
|
4
4
|
import { existsSync as existsSync33 } from "fs";
|
|
5
5
|
import { Builtins, Cli as Cli2 } from "clipanion";
|
|
6
6
|
|
|
@@ -246,7 +246,7 @@ function bucketByKind(kind, instance, bag) {
|
|
|
246
246
|
// package.json
|
|
247
247
|
var package_default = {
|
|
248
248
|
name: "@skill-map/cli",
|
|
249
|
-
version: "0.53.
|
|
249
|
+
version: "0.53.3",
|
|
250
250
|
description: "skill-map reference implementation \u2014 kernel + CLI + adapters.",
|
|
251
251
|
license: "MIT",
|
|
252
252
|
type: "module",
|
|
@@ -30251,4 +30251,4 @@ function resolveBareDefault() {
|
|
|
30251
30251
|
process.exit(ExitCode.Error);
|
|
30252
30252
|
}
|
|
30253
30253
|
//# sourceMappingURL=cli.js.map
|
|
30254
|
-
//# debugId=
|
|
30254
|
+
//# debugId=542dae21-a4ed-50bb-ad3c-62e84e47b380
|
package/dist/index.js
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
// kernel/i18n/registry.texts.ts
|
|
2
2
|
|
|
3
|
-
!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="
|
|
3
|
+
!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="89adb52b-2657-5932-aa07-61e08ebbf98b")}catch(e){}}();
|
|
4
4
|
var REGISTRY_TEXTS = {
|
|
5
5
|
duplicateExtension: "Extension already registered: {{kind}}:{{qualifiedId}}",
|
|
6
6
|
unknownKind: "Unknown extension kind: {{kind}}",
|
|
@@ -102,7 +102,7 @@ import { Tiktoken as Tiktoken2 } from "js-tiktoken/lite";
|
|
|
102
102
|
// package.json
|
|
103
103
|
var package_default = {
|
|
104
104
|
name: "@skill-map/cli",
|
|
105
|
-
version: "0.53.
|
|
105
|
+
version: "0.53.3",
|
|
106
106
|
description: "skill-map reference implementation \u2014 kernel + CLI + adapters.",
|
|
107
107
|
license: "MIT",
|
|
108
108
|
type: "module",
|
|
@@ -3632,4 +3632,4 @@ export {
|
|
|
3632
3632
|
runScanWithRenames
|
|
3633
3633
|
};
|
|
3634
3634
|
//# sourceMappingURL=index.js.map
|
|
3635
|
-
//# debugId=
|
|
3635
|
+
//# debugId=89adb52b-2657-5932-aa07-61e08ebbf98b
|
package/dist/kernel/index.js
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
// kernel/i18n/registry.texts.ts
|
|
2
2
|
|
|
3
|
-
!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="
|
|
3
|
+
!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="eda01250-1ec1-5934-9fb3-c95548eccf56")}catch(e){}}();
|
|
4
4
|
var REGISTRY_TEXTS = {
|
|
5
5
|
duplicateExtension: "Extension already registered: {{kind}}:{{qualifiedId}}",
|
|
6
6
|
unknownKind: "Unknown extension kind: {{kind}}",
|
|
@@ -102,7 +102,7 @@ import { Tiktoken as Tiktoken2 } from "js-tiktoken/lite";
|
|
|
102
102
|
// package.json
|
|
103
103
|
var package_default = {
|
|
104
104
|
name: "@skill-map/cli",
|
|
105
|
-
version: "0.53.
|
|
105
|
+
version: "0.53.3",
|
|
106
106
|
description: "skill-map reference implementation \u2014 kernel + CLI + adapters.",
|
|
107
107
|
license: "MIT",
|
|
108
108
|
type: "module",
|
|
@@ -3632,4 +3632,4 @@ export {
|
|
|
3632
3632
|
runScanWithRenames
|
|
3633
3633
|
};
|
|
3634
3634
|
//# sourceMappingURL=index.js.map
|
|
3635
|
-
//# debugId=
|
|
3635
|
+
//# debugId=eda01250-1ec1-5934-9fb3-c95548eccf56
|