@insitue/claude-plugin 0.6.1 → 0.6.2

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "insitue",
-  "version": "0.5.1",
+  "version": "0.5.2",
   "description": "Drive a Claude Code session from the InSitue browser overlay. Pick an element in your app, claude reads the file and proposes the edit.",
   "mcpServers": {
     "insitue": {

package/CHANGELOG.md

@@ -1,5 +1,9 @@
 # @insitue/claude-plugin
 
+## 0.6.2
+
+- **Echo the request before fixing.** The cloud-issue instructions (connect.md + the `claim_cloud_issue` tool) now require Claude to print the exact request verbatim ("Fixing locally: …") before any analysis or edits, so you always see what it's about to act on.
+
 ## 0.6.1
 
 - **Fix: refuse to reuse a stale companion.** `ensureCompanion` now checks a reachable companion's version via the handshake and, if it is older than the cloud-feature floor (0.7.0), tears it down and spawns the current one — instead of silently attaching to a stale companion left on the port.

package/commands/connect.md

@@ -160,8 +160,14 @@ action.
 **Typical loop:**
 
 1. `list_cloud_issues` → pick an issue with the user.
-2. `claim_cloud_issue <id>` → read `source.file` around `source.line`,
-   understand the repro from `note` + `consoleErrors`, make the fix.
+2. `claim_cloud_issue <id>` → **before doing anything else**, echo the
+   exact request verbatim to the developer:
+
+   > **Fixing locally:** [verbatim `note` from the claim response]
+   > (Source: `source.file:source.line`)
+
+   Then read `source.file` around `source.line`, understand the repro
+   from `note` + `consoleErrors`, make the fix.
 3. Open a PR.
 4. `resolve_cloud_issue <id> <prUrl>`.
 
@@ -169,6 +175,18 @@ The cloud-issue workflow follows the same guardrails as browser picks:
 never auto-apply writes, always wait for explicit user approval before
 editing files.
 
+**Echo guardrail (cloud-issue path).** Mirroring the pick-loop rule
+("Always echo the prompt back first"): after a successful
+`claim_cloud_issue`, the FIRST thing you output to the developer MUST
+be the exact issue `note` in the format above — verbatim, not
+paraphrased. The CLI transcript only shows your output, not the
+dashboard description the reporter wrote. Without the echo the
+developer cannot confirm you're acting on the right issue before edits
+begin. Note: when an issue arrives via the browser "Fix locally"
+button it flows through the normal pick loop and the existing
+pick-echo rule already applies — but the same requirement holds when
+you claim via the cloud-issue tool path directly.
+
 ## Failure modes to handle gracefully
 
 - **`source.file` doesn't exist**: tell the user the path the

package/dist/mcp-server.js

@@ -999,7 +999,7 @@ server.registerTool(
               source,
               url,
               consoleErrors,
-              instructions: "Read the source file around the line, reproduce the issue from the description, make the fix, open a PR, then call resolve_cloud_issue with the PR url."
+              instructions: 'FIRST, echo the exact issue note verbatim to the developer before any analysis or edits: output "**Fixing locally:** <note>" followed by "(Source: <file>:<line>)" so they can confirm what is being acted on. THEN read the source file around the line, reproduce the issue from the description, make the fix, open a PR, then call resolve_cloud_issue with the PR url.'
             })
           }
         ]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@insitue/claude-plugin",
-  "version": "0.6.1",
+  "version": "0.6.2",
   "description": "Drive Claude (Code AND Desktop) from the InSitue browser overlay — pick an element in your app, claude reads the file and proposes the edit.",
   "keywords": [
     "insitue",