@super-hands/connect 0.1.19 → 0.1.21

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.
Files changed (2) hide show
  1. package/client.mjs +24 -4
  2. package/package.json +1 -1
package/client.mjs CHANGED
@@ -42,7 +42,7 @@ function codexConfigBlock(args) {
42
42
  }
43
43
 
44
44
  // lib/connect-skill.ts
45
- var CONNECT_SKILL_VERSION = 12;
45
+ var CONNECT_SKILL_VERSION = 14;
46
46
  var CONNECT_SKILL_DIR = MCP_SERVER_KEY;
47
47
  var CONNECT_SKILL_FILENAME = "SKILL.md";
48
48
  var VERSION_MARKER = `[//]: # (superhands-skill-version: ${CONNECT_SKILL_VERSION})`;
@@ -71,6 +71,10 @@ Before you build, change, or restyle any UI:
71
71
  \`skill_version: ${CONNECT_SKILL_VERSION}\` \u2014 the version of this file, so
72
72
  the server can tell you when this file is out of date. The corpus comes
73
73
  back narrowed to that work, with everything not chosen still named.
74
+ - Keep the instruction activity visible in your working log as terse progress:
75
+ say "Searching instructions" while this call runs, then replace it with the
76
+ names selected when the answer arrives. Update that temporary status in
77
+ place instead of posting a second conclusion.
74
78
  - Pass \`paths\` too, when you already know which files this work touches \u2014
75
79
  the handful you have open or are about to edit, repository-relative, for
76
80
  example \`["app/marketing/pricing.tsx"]\`. The team writes down where
@@ -91,6 +95,8 @@ Before you build, change, or restyle any UI:
91
95
  everything under it, so \`better-ui/*\` is a whole skill and
92
96
  \`better-ui/SKILL#*\` is one file. It runs no selection and makes no model
93
97
  call, so it is a plain, fast lookup and it returns exactly what you named.
98
+ - In your working log, say "Checking: [part]", then replace that status with
99
+ "[module] picked up" when the call returns. Keep it factual and brief.
94
100
  - **Expect to make this call several times in one task.** A contact form is
95
101
  not one part: it is the form, then its inputs, then its buttons, then its
96
102
  validation errors, then its loading and empty states. One read at the
@@ -116,9 +122,23 @@ Before you build, change, or restyle any UI:
116
122
  summary, passing \`handled\` for anything you already covered.
117
123
  6. When you have finished \u2014 not part-way through \u2014 send the files you wrote or
118
124
  changed with \`superhands_report_completed_build\`, naming the \`route\` if
119
- you know it. The team looks at what their agents build there; it records
120
- and does not review, so a failed report costs the work nothing.
121
- 7. When you finish, say you followed the team's Instructions \u2014 never that your
125
+ you know it, and \`instructionChanges\`: for each Instruction you were
126
+ handed up front or picked up during the work, its key exactly as it was
127
+ handed to you and one line on the concrete change it caused in what you
128
+ built \u2014 \`{ "key": "skill#every-view-has-its-states", "change": "added
129
+ loading, empty and error states to the orders table" }\`. If one caused no
130
+ change, say that in its line rather than leaving it out. The team looks at
131
+ what their agents build there and reads those lines as your words; it
132
+ records and does not review, so a failed report costs the work nothing. A
133
+ successful response ends with the run's Instructions receipt; include it
134
+ once in your final response so the person can see what was handed over up
135
+ front, picked up during the work, or only named for later, and what you
136
+ reported each changed. It is context provenance, not proof that anything
137
+ was applied.
138
+ 7. In that final response, state the same concrete output change each
139
+ picked-up Instruction caused, in your own words. This is your account of the
140
+ work, not a Superhands review or verification.
141
+ 8. When you finish, say you followed the team's Instructions \u2014 never that your
122
142
  work was checked. Reading Instructions is not a check, reporting a build is
123
143
  not a review, and nothing has looked at what you built.
124
144
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@super-hands/connect",
3
- "version": "0.1.19",
3
+ "version": "0.1.21",
4
4
  "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.",
5
5
  "bin": {
6
6
  "superhands-connect": "client.mjs"