JanneL · Oct 9, 2026 · Oct 9, 2026 · Oct 9, 2026
diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "pathmode",
   "displayName": "Pathmode",
-  "version": "0.1.47",
+  "version": "0.1.48",
   "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
@@ -2,7 +2,7 @@
     "mcpServers": {
         "pathmode": {
             "command": "npx",
-            "args": ["-y", "@pathmode/mcp-server@1.41.0"],
+            "args": ["-y", "@pathmode/mcp-server@1.41.1"],
             "env": {
                 "PATHMODE_API_KEY": "${user_config.api_key}"
             }

diff --git 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.41.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.41.1`, 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/compile-intent/SKILL.md b/skills/compile-intent/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: compile-intent
-description: Build a structured intent spec through guided conversation, one decision at a time with a recommended answer for each. Use when the user wants to define what to build, sharpen a vague idea into a testable spec, or capture product intent before writing code. Writes intent.md in the project root and (if an API key is set) syncs to a Pathmode workspace.
+description: Build a structured intent spec through guided conversation, one decision at a time with a recommended answer for each. Use when the user wants to define what to build, sharpen a vague idea into a testable spec, or capture product intent before writing code. Writes intent.md in the project root as a local draft; a Pathmode workspace sees it after adoption.
 ---
 
 <what-to-do>
@@ -25,7 +25,7 @@ The compile-intent prompt is interrogative on purpose. It pushes back on vague l
 
 ## Output shape
 
-`intent.md` at the project root:
+`intent.md` at the project root, abridged (`intent_save` writes it; a section appears only when it has content):
 
 ```markdown
 ---
@@ -44,14 +44,18 @@ status: "draft"
 ## Outcomes
 - [ ] [Observable state change, testable in under 5 minutes]
 
+## Constraints
+- [Hard limit — what must never happen]
+
 ## Edge Cases
 - **[Scenario]**: [Expected behavior]
 
-## Constraints
-- [Hard limit — what must never happen]
+## Verification
+**[Check kind]**:
+- [ ] [A check concrete enough to run without asking the author]
 ```
 
-If `PATHMODE_API_KEY` is set, the spec also syncs to the user's Pathmode workspace and becomes visible to other team members and other agents.
+A new spec is saved as a local draft and stays on this machine, even with `PATHMODE_API_KEY` set. Adoption (`npx @pathmode/mcp-server@latest adopt`, approved in the browser) brings it into the Pathmode workspace, where team members and their agents can see it. Once `intent.md` is connected, each save also syncs to the workspace.
 
 ## Evidence in a file that lives in git
 

diff --git a/skills/grill-intent/SKILL.md b/skills/grill-intent/SKILL.md
@@ -5,9 +5,9 @@ description: Adversarial review of an existing intent spec. Walk the spec field-
 
 <what-to-do>
 
-Load the active intent from `intent.md` in the project root first. That file is bound to this repository and remains the content authority even when `PATHMODE_API_KEY` is set. Only call `get_current_intent` when no local file exists. If the file carries a cloud id, use that id for any team-only note call below.
+Load the active intent from `intent.md` in the project root first. That file is bound to this repository and remains the content authority even when `PATHMODE_API_KEY` is set. If the repository has no `intent.md`, ask the user which saved intent they mean and load it with `get_intent`. With a workspace connected, `get_current_intent` picks by a workspace heuristic and can return an intent unrelated to this repository. If the file carries a cloud id, use that id for any team-only note call below.
 
-Walk the spec field-by-field — objective, outcomes, edge cases, constraints. For each field, find the weakest claim and pressure-test it. Ask ONE pointed question at a time. For each question, propose your best-guess answer based on the spec and the codebase.
+Walk the spec field-by-field — objective, outcomes, edge cases, constraints. For each field, find the weakest claim and pressure-test it. Ask one pointed question at a time. For each question, propose your best-guess answer based on the spec and the codebase.
 
 When a weakness is confirmed, edit the spec itself — not a note about it. Write the change back to `intent.md` and save with `intent_save` (it preserves the file's identity and syncs in team mode; use `update_intent` only when no local file exists). Then, in team mode, call `log_implementation_note` to record WHY the change was made: the note reaches the next agent's prompt, the spec carries the change.
 

diff --git a/skills/handoff-intent/SKILL.md b/skills/handoff-intent/SKILL.md
@@ -5,7 +5,7 @@ description: Capture context at the end of an implementation session — decisio
 
 <what-to-do>
 
-Load the active intent. Read `intent.md` from the project root first — the file is bound to this repository, which makes it the authority on what this session was working under. If `PATHMODE_API_KEY` is set and the file's frontmatter carries a cloud id, use that id for team-only calls below. Do not let `get_current_intent` choose the intent for you when a local file exists — "current" is a workspace heuristic, not a repo binding. Only fall back to `get_current_intent` when no local file exists.
+Load the active intent. Read `intent.md` from the project root first — the file is bound to this repository, which makes it the authority on what this session was working under. If `PATHMODE_API_KEY` is set and the file's frontmatter carries a cloud id, use that id for team-only calls below. Do not let `get_current_intent` choose the intent — "current" is a workspace heuristic, not a repo binding. If the repository has no `intent.md`, ask the user which saved intent this session worked under and load it with `get_intent`.
 
 Summarize the session in four buckets:
 
@@ -40,9 +40,9 @@ The "why" and the "what's still implicit" are the parts that disappear if you do
 - `shipped` — code is merged AND the outcome is observable in production
 - `verified` — the outcome metric has held for at least one full cycle (e.g., one week, one release)
 
-**When the change ships through a pull request, do NOT call `update_intent_status` yourself.** If the workspace has GitHub connected, the merge reads the real diff, grades it against the spec, moves the intent to Shipped, and records what the verdict rested on. The webhook skips intents that are already shipped, so flipping it early does not just duplicate that work — it suppresses it, replacing a diff-backed verdict with an unverified one. Stamp the reference, let the merge fire, and bump the status by hand only when the change will never appear in a PR.
+When the change ships through a pull request, do not call `update_intent_status` yourself. If the workspace has GitHub connected, the merge reads the real diff, grades it against the spec, moves the intent to Shipped, and records what the verdict rested on. The webhook skips intents that are already shipped, so flipping it early does not just duplicate that work — it suppresses it, replacing a diff-backed verdict with an unverified one. Stamp the reference, let the merge fire, and bump the status by hand only when the change will never appear in a PR.
 
-Do NOT bump to `shipped` if outcomes are only partially delivered. Either leave the status and log the partial delivery as a note, or propose a spec amendment that scopes the outcome to what was actually shipped.
+Do not bump to `shipped` if outcomes are only partially delivered. Either leave the status and log the partial delivery as a note, or propose a spec amendment that scopes the outcome to what was actually shipped.
 
 ## Difference from a commit message
 

diff --git a/skills/implement-intent/SKILL.md b/skills/implement-intent/SKILL.md
@@ -18,15 +18,15 @@ Read `intent.md` from the project root first. It is the repository-bound authori
 
 If Preflight has unresolved blockers, show its exact verdict and work through the `preflight` repair loop one targeted question at a time. Do not silently begin implementation from a failing spec.
 
-The user may explicitly accept named blockers and ask you to proceed. That is **accepted risk**, not a waiver: a waiver says a dimension does not apply, while accepted risk says the gap is real. Preserve the judgment by calling `intent_save` with the complete current spec and an added decision:
+In keyless mode, the user may explicitly accept named blockers and ask you to proceed. That is **accepted risk**, not a waiver: a waiver says a dimension does not apply, while accepted risk says the gap is real. Preserve the judgment by calling `intent_save` with the complete current spec and an added decision:
 
 - `choice`: `Proceed despite preflight blockers: <exact gate names>`
 - `ruledOut`: `Repair every blocker before implementation`
 - `reason`: the user's stated reason, without embellishment
 
-Re-run Preflight afterward and show the still-failing verdict. Never turn accepted risk into a green check. The acceptance authorizes only this implementation conversation; a later agent must ask again unless it has fresh human authorization for the exact revision.
+Re-run Preflight afterward and show the still-failing verdict. Never turn accepted risk into a green check. The acceptance covers only this implementation conversation; a later agent must ask again.
 
-In connected mode, a save changes the repository-body revision. Stop until a signed-in product manager authorizes that exact revision. Then call `get_agent_prompt`: use `mode: execute` when Preflight passes, or `mode: draft` when the user explicitly accepted still-visible blockers. Stop on an open change request or a pending, rejected, or stale authorization banner. Fetch `get_constitution` before implementation.
+In connected mode, accepted risk does not unlock implementation: `get_agent_prompt` with `mode: execute` refuses a spec that fails its checks, and that refusal means do not implement, so keep repairing the blockers with the user. A save changes the repository-body revision. Stop until a signed-in product manager authorizes that exact revision. Then call `get_agent_prompt` with `mode: execute` and implement only when it succeeds. Stop on an open change request or a pending, rejected, or stale authorization banner. Fetch `get_constitution` before implementation.
 
 In keyless mode, do not call `get_agent_prompt`, `get_constitution`, or other cloud-only tools. Use `intent.md`, the repository instructions, and the codebase itself as the implementation context.
 
@@ -39,7 +39,7 @@ Create a small implementation plan mapped to the outcomes. Make only the changes
 ## Three independent judgments
 
 - **Preflight** asks whether the spec is concrete enough to build and verify.
-- **Accepted risk** records a human decision to proceed while a known gap remains. It never changes the Preflight verdict.
+- **Accepted risk** (keyless mode only) records a human decision to proceed while a known gap remains. It never changes the Preflight verdict.
 - **Authorization** confirms that a human permits an agent-originated repository revision to be implemented. It does not make a failing gate pass.
 
 ## Pull-request delivery

diff --git a/skills/preflight/SKILL.md b/skills/preflight/SKILL.md
@@ -11,7 +11,7 @@ In connected mode, when the repo-bound file carries a cloud id, check for PM jud
 
 Show the user the verdict block exactly as returned — the blocker strings are the calibrated gate output, do not paraphrase them.
 
-If the verdict fails: repair, one blocker at a time. For each failing gate, ask the user ONE targeted question, and propose your best-guess answer from the spec and the codebase so they can correct rather than compose. Apply the agreed fix to the same authority you loaded: when `intent.md` exists, call `intent_save` (it also syncs in connected mode); only use `update_intent` when no local file exists. Then re-run `check_intent_readiness`. When you read the codebase to propose an answer, keep what you learned: pass it to `intent_save` as `implementationContext`, or call `record_implementation_context` for a cloud-only intent. It does not affect the verdict, and it saves the implementing agent from rediscovering what you just read. Stop when the verdict passes or the user explicitly accepts a named gap.
+If the verdict fails: repair, one blocker at a time. For each failing gate, ask the user one targeted question, and propose your best-guess answer from the spec and the codebase so they can correct rather than compose. Apply the agreed fix to the same authority you loaded: when `intent.md` exists, call `intent_save` (it also syncs in connected mode); only use `update_intent` when no local file exists. Then re-run `check_intent_readiness`. When you read the codebase to propose an answer, keep what you learned: pass it to `intent_save` as `implementationContext`, or call `record_implementation_context` for a cloud-only intent. It does not affect the verdict, and it saves the implementing agent from rediscovering what you just read. Stop when the verdict passes or the user explicitly accepts a named gap.
 
 If the verdict passes: say so and stop. Do not invent extra requirements beyond the six gates.
 

diff --git a/skills/review-against-intent/SKILL.md b/skills/review-against-intent/SKILL.md
@@ -19,7 +19,7 @@ Report:
 - Constraint violations (specific files/lines)
 - Edge cases that look unhandled
 
-Do NOT review for unrelated code style, formatting, or quality concerns. That's not this skill's job. Stay anchored to the intent.
+Leave unrelated code style, formatting, and quality concerns out of this review; it is anchored to the intent.
 
 </what-to-do>
 

diff --git a/skills/setup-pathmode-workflow/SKILL.md b/skills/setup-pathmode-workflow/SKILL.md
@@ -5,9 +5,6 @@ description: Interview the user about their development workflow and capture the
 
 <what-to-do>
 
-For team review, run npx @pathmode/mcp-server@latest adopt in the repository. It prints a link and a code; give both to the person for browser approval. If it reports AUTHORIZATION_PENDING, stop and rerun the same command after approval. No spec is uploaded before approval. The browser-generated `adopt pm_adopt_...` command still works.
-
-
 Walk the user through the workflow questions below. Ask ONE question at a time. For each question, propose your best-guess answer based on what you can see in the repo (package.json scripts, CI config, README, existing PRs). The user accepts or corrects.
 
 Questions to cover (in order):
@@ -34,7 +31,7 @@ When all questions are answered, output a single self-contained block the user c
 - Implementation notes: [convention]
 ```
 
-If `PATHMODE_API_KEY` is set, ALSO call `log_implementation_note` on the user's current intent (if any, otherwise the first intent in the workspace) so the conventions show in the Pathmode audit trail. Be honest about reach: that note rides only that one intent's future prompts — there is no workspace-level convention record yet. `CLAUDE.md` is what every agent session actually inherits, which is why the paste step above is the one that matters.
+If `PATHMODE_API_KEY` is set and the repository's `intent.md` carries a cloud id, also call `log_implementation_note` on that intent so the conventions show in the Pathmode audit trail. Be honest about reach: that note rides only that one intent's future prompts — there is no workspace-level convention record yet. `CLAUDE.md` is what every agent session actually inherits, which is why the paste step above is the one that matters.
 
 Do NOT write to a `.pathmode/` directory in the repo. The canonical conventions live in `CLAUDE.md` (visible to every agent session) and in the Pathmode workspace (visible to PMs). The repo is a consumer of intent, not where intent fossilizes.
 

diff --git a/skills/split-intent-to-issues/SKILL.md b/skills/split-intent-to-issues/SKILL.md
@@ -5,7 +5,7 @@ description: Break an intent spec into 3-10 paste-ready tickets for Linear, Jira
 
 <what-to-do>
 
-Load the active intent from `intent.md` in the project root first. That file is bound to this repository and remains the content authority even when `PATHMODE_API_KEY` is set. Only call `get_current_intent` when no local file exists.
+Load the active intent from `intent.md` in the project root first. That file is bound to this repository and remains the content authority even when `PATHMODE_API_KEY` is set. If the repository has no `intent.md`, ask the user which saved intent they mean and load it with `get_intent`. With a workspace connected, `get_current_intent` picks by a workspace heuristic and can return an intent unrelated to this repository.
 
 Analyze the spec. The outcomes are the natural decomposition unit — each outcome typically maps to 1-3 tickets, depending on complexity.
 

diff --git a/skills/verify-intent/SKILL.md b/skills/verify-intent/SKILL.md
@@ -5,9 +5,9 @@ description: Design the executable feedback loop for an intent — fastest check
 
 <what-to-do>
 
-Load the active intent from `intent.md` in the project root first. That file is bound to this repository and remains the content authority even when `PATHMODE_API_KEY` is set. Only call `get_current_intent` when no local file exists.
+Load the active intent from `intent.md` in the project root first. That file is bound to this repository and remains the content authority even when `PATHMODE_API_KEY` is set. If the repository has no `intent.md`, ask the user which saved intent they mean and load it with `get_intent`. With a workspace connected, `get_current_intent` picks by a workspace heuristic and can return an intent unrelated to this repository.
 
-Walk the user through the five verification dimensions below. Ask ONE question at a time. For each question, propose your best-guess answer based on the intent's outcomes and what's visible in the codebase (existing tests, observability hooks, CI config).
+Walk the user through the five verification dimensions below. Ask one question at a time. For each question, propose your best-guess answer based on the intent's outcomes and what's visible in the codebase (existing tests, observability hooks, CI config).
 
 The five dimensions: