@super-hands/connect 0.1.19 → 0.1.20

package/client.mjs

@@ -42,7 +42,7 @@ function codexConfigBlock(args) {
 }
 
 // lib/connect-skill.ts
-var CONNECT_SKILL_VERSION = 12;
+var CONNECT_SKILL_VERSION = 13;
 var CONNECT_SKILL_DIR = MCP_SERVER_KEY;
 var CONNECT_SKILL_FILENAME = "SKILL.md";
 var VERSION_MARKER = `[//]: # (superhands-skill-version: ${CONNECT_SKILL_VERSION})`;
@@ -71,6 +71,10 @@ Before you build, change, or restyle any UI:
    \`skill_version: ${CONNECT_SKILL_VERSION}\` \u2014 the version of this file, so
    the server can tell you when this file is out of date. The corpus comes
    back narrowed to that work, with everything not chosen still named.
+   - Keep the instruction activity visible in your working log as terse progress:
+     say "Searching instructions" while this call runs, then replace it with the
+     names selected when the answer arrives. Update that temporary status in
+     place instead of posting a second conclusion.
    - Pass \`paths\` too, when you already know which files this work touches \u2014
      the handful you have open or are about to edit, repository-relative, for
      example \`["app/marketing/pricing.tsx"]\`. The team writes down where
@@ -91,6 +95,8 @@ Before you build, change, or restyle any UI:
    everything under it, so \`better-ui/*\` is a whole skill and
    \`better-ui/SKILL#*\` is one file. It runs no selection and makes no model
    call, so it is a plain, fast lookup and it returns exactly what you named.
+   - In your working log, say "Checking: [part]", then replace that status with
+     "[module] picked up" when the call returns. Keep it factual and brief.
    - **Expect to make this call several times in one task.** A contact form is
      not one part: it is the form, then its inputs, then its buttons, then its
      validation errors, then its loading and empty states. One read at the
@@ -117,8 +123,15 @@ Before you build, change, or restyle any UI:
 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.
-7. When you finish, say you followed the team's Instructions \u2014 never that your
+   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.
+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.19",
+  "version": "0.1.20",
   "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"