@nanopm/cli 0.1.18 → 0.1.20

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nanopm/cli",
-  "version": "0.1.18",
+  "version": "0.1.20",
   "description": "An autonomous product manager for builders who run several small products. Runs on your machine, drives your own coding harness.",
   "type": "module",
   "license": "MIT",

package/skills/build/SKILL.md

@@ -24,20 +24,34 @@ NanoPM commits each step for you and opens the pull request when you are done.
 2. If the code contradicts the spec — what it asks already exists, a step it assumes is not
    there, the size does not hold — `ask_user` before you plan: what the spec says, what the code
    has, what it changes, and the options. Do not guess what the founder decided.
-3. `build_plan`: your plan, 1 to 8 steps, in order, each a change the founder can recognise, in
-   their words. The last step is your check of the whole change.
+3. `build_plan`: first, in `understood`, what you understood, in your own words and plain
+   language — the problem, what you will change, what you will not touch. The founder reads it
+   before anything else; a misunderstanding must show there, not in the pull request. Then your
+   plan, 1 to 8 steps, in order, each a change the founder can recognise, in their words. The last
+   step is your check of the whole change: the project's checks, then the app itself (step 5).
 4. Build one step at a time. After each: run its tests and the project's own checks (the ones
    CLAUDE.md, the README or `package.json` name), fix what they report, then `build_step` with the
    step's number and one line on what you did. NanoPM commits right then, so a step is committed
    only when it works. Never run `git commit`, `git push` or anything that rewrites history.
-5. When every step is done, stop with a short report, in the founder's words, which becomes the
+5. **Check each acceptance criterion**, inside your last step: go through each one of
+   `.nanopm/SPEC.md` and check it as close to what the user sees as you can here — run the code
+   path it names (call the handler, run the script, render the component), and note what you saw.
+   Your sandbox cannot open a local port, so a running server, a browser or a device is out of
+   reach: say so for what needs one. Never touch a database, a service or a file outside your copy
+   to check something. Keep package caches in `$TMPDIR` (`npm install --cache "$TMPDIR/npm"`, a
+   pnpm store there): your home is outside the sandbox. Stop everything you started before you
+   finish.
+6. When every step is done, stop with a short report, in the founder's words, which becomes the
    pull request's description:
    - **What was built**: two or three sentences.
    - **Decisions I made**: each choice the spec left open, with its why.
    - **Differs from the spec**: or *Nothing*.
    - **Left to do**: or *Nothing*.
-   - **How I checked it**: the commands you ran, and their result.
-6. `log` one line: what you built.
+   - **How I checked it**: first one line per acceptance criterion, exactly `- AC1 — saw: what you
+     saw` or `- AC1 — could not: what, because why`. *Saw* is for what you saw happen when you ran
+     the code the criterion is about — say how (a handler called with what, a script's output);
+     what you could not reach is *could not*, with why. Never say you saw what you did not run. Then the commands you ran, and their result.
+7. `log` one line: what you built.
 
 ## When to ask the founder