diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json
index f2f48e6..a8d8353 100644
--- a/.claude-plugin/plugin.json
+++ b/.claude-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "pathmode",
   "displayName": "Pathmode",
-  "version": "0.1.51",
+  "version": "0.1.52",
   "description": "Run a deterministic preflight on your intent before an agent builds: /preflight scores six calibrated gates and names the exact blockers, no model call, no key. Pathmode also interrogates the intent behind a request (compile-intent), writes it to intent.md in your repo, and checks the code that comes back against the outcomes and constraints you agreed to. Free: uses the models you already have access to in Claude Code. Connect a Pathmode workspace to sync intent and evidence across a team.",
   "author": {
     "name": "Pathmode",
diff --git a/.mcp.json b/.mcp.json
index 71c0be8..d85a424 100644
--- a/.mcp.json
+++ b/.mcp.json
@@ -2,7 +2,7 @@
     "mcpServers": {
         "pathmode": {
             "command": "npx",
-            "args": ["-y", "@pathmode/mcp-server@1.42.0"],
+            "args": ["-y", "@pathmode/mcp-server@1.43.0"],
             "env": {
                 "PATHMODE_API_KEY": "${user_config.api_key}"
             }
diff --git a/README.md b/README.md
index 7ee253d..ac82efe 100644
--- a/README.md
+++ b/README.md
@@ -72,7 +72,7 @@ For workspace API access without a local intent, you can still create an API key
 
 ## What's bundled
 
-**MCP server** — `@pathmode/mcp-server@1.42.0`, pinned so the plugin skills and server tool contract update together. Local mode with no key; cloud mode with one.
+**MCP server** — `@pathmode/mcp-server@1.43.0`, pinned so the plugin skills and server tool contract update together. Local mode with no key; cloud mode with one.
 
 **Check the gate yourself** — `node scripts/readiness-suite.mjs` runs the pinned server's preflight over 192 labelled field fixtures and a set of whole `intent.md` documents, and prints where it disagrees. Read [CALIBRATION.md](CALIBRATION.md) first: the field score is a regression baseline, not an accuracy claim.
 
diff --git a/skills/implement-intent/SKILL.md b/skills/implement-intent/SKILL.md
index c4be9ab..b7de934 100644
--- a/skills/implement-intent/SKILL.md
+++ b/skills/implement-intent/SKILL.md
@@ -13,7 +13,7 @@ For team review of a new local draft, run `npx @pathmode/mcp-server@latest adopt
 
 Before applying a repository choice request, use `get_intent` to refresh the current body and read the request. Call `intent_save` using the request's original `changeRequestId` and `baseRepoBodyRevision`. Do not include new choice proposals or unrelated body edits in that apply. Unchanged sibling answers may apply sequentially; a changed target or parent needs renewed human review. Refused applies are not permission to bypass the request. A requested deferral still waits for application and remains a readiness blocker afterward.
 
-After application, inspect the returned revision and stop for separate whole-revision authorization. In a fresh implementation session, call `get_intent` and verify that `authorization` is authorized and `authorizedRepoBodyRevision` equals `repoBodyRevision`, then use the existing readiness/prompt path below. A change-request read receipt is not proof that this authorized revision was read.
+After application, inspect the returned revision and stop for separate whole-revision authorization. In a fresh implementation session, `check_intent_readiness` prints a `Revision:` line comparing this repository's `intent.md` with the workspace body. Build only when it says `intent.md` matches the authorized revision; `get_agent_prompt` with `mode: execute` refuses otherwise. A STALE line means run the pull command the line names, in the repository, and check again; a CONFLICT line means the file has local edits, which the person saves with `intent_save` or discards with the `pull --discard-local` command the line names. Run the commands exactly as the line names them: they match the server you are connected to. A pull of a revision that is not authorized brings the file current and still does not permit a build. When the line says the version is waiting for the person's approval, and you can run a background command, start the listener it names in the background (`--build` if they asked you to implement the change, `--no-build` if they asked only for a proposal) and end your turn. Do not poll or set timers: the listener brings `intent.md` to the approved revision and prints one line saying what to do. A change-request read receipt is not proof that this authorized revision was read.
 
 
 Read `intent.md` from the project root first. It is the repository-bound authority. Call `check_intent_readiness` before changing product code: with no arguments for that file, or with `intentId` only when the user explicitly selected a cloud-only intent.