@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.
- package/client.mjs +24 -4
- 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 =
|
|
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
|
|
120
|
-
|
|
121
|
-
|
|
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.
|
|
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"
|