@super-hands/connect 0.1.20 → 0.1.21

package/client.mjs

@@ -42,7 +42,7 @@ function codexConfigBlock(args) {
 }
 
 // lib/connect-skill.ts
-var CONNECT_SKILL_VERSION = 13;
+var CONNECT_SKILL_VERSION = 14;
 var CONNECT_SKILL_DIR = MCP_SERVER_KEY;
 var CONNECT_SKILL_FILENAME = "SKILL.md";
 var VERSION_MARKER = `[//]: # (superhands-skill-version: ${CONNECT_SKILL_VERSION})`;
@@ -122,15 +122,22 @@ Before you build, change, or restyle any UI:
    summary, passing \`handled\` for anything you already covered.
 6. When you have finished \u2014 not part-way through \u2014 send the files you wrote or
    changed with \`superhands_report_completed_build\`, naming the \`route\` if
-   you know it. The team looks at what their agents build there; it records
-   and does not review, so a failed report costs the work nothing. A successful
-   response ends with the run's Instructions receipt; include it once in your
-   final response so the person can see what was handed over up front, picked
-   up during the work, or only named for later. It is context provenance, not
-   proof that anything was applied.
-7. In that final response, state the concrete output change each picked-up
-   Instruction caused. If one caused no change, say so. This is your account of
-   the work, not a Superhands review or verification.
+   you know it, and \`instructionChanges\`: for each Instruction you were
+   handed up front or picked up during the work, its key exactly as it was
+   handed to you and one line on the concrete change it caused in what you
+   built \u2014 \`{ "key": "skill#every-view-has-its-states", "change": "added
+   loading, empty and error states to the orders table" }\`. If one caused no
+   change, say that in its line rather than leaving it out. The team looks at
+   what their agents build there and reads those lines as your words; it
+   records and does not review, so a failed report costs the work nothing. A
+   successful response ends with the run's Instructions receipt; include it
+   once in your final response so the person can see what was handed over up
+   front, picked up during the work, or only named for later, and what you
+   reported each changed. It is context provenance, not proof that anything
+   was applied.
+7. In that final response, state the same concrete output change each
+   picked-up Instruction caused, in your own words. This is your account of the
+   work, not a Superhands review or verification.
 8. When you finish, say you followed the team's Instructions \u2014 never that your
    work was checked. Reading Instructions is not a check, reporting a build is
    not a review, and nothing has looked at what you built.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@super-hands/connect",
-  "version": "0.1.20",
+  "version": "0.1.21",
   "description": "Connect the coding agents on this machine to your team's Superhands MCP server — with `start`, from a machine that has no Superhands account at all. Refresh it later with `update` (no token needed), and take it back off again with `uninstall`. Writes each client's own config; reads no repository, uploads nothing.",
   "bin": {
     "superhands-connect": "client.mjs"