@pathmode/mcp-server 1.21.0 → 1.22.0

package/README.md

@@ -104,12 +104,14 @@ Your implementation MUST satisfy ALL of these:
 
 ## Skill Pack for Claude Code
 
-The package also ships 8 Claude Code skills that auto-trigger based on what you ask — no slash commands required.
+The package also ships 9 Claude Code skills that auto-trigger based on what you ask — no slash commands required.
 
 | Skill | Use when |
 |-------|----------|
 | `setup-pathmode-workflow` | First-time project setup (test commands, issue tracker, status conventions) |
 | `compile-intent` | Building a structured spec for what to ship |
+| `preflight` | Running the deterministic six-gate readiness verdict before implementation |
+| `implement-intent` | Implementing a repository intent only after Preflight and required human authorization |
 | `verify-intent` | Designing the executable feedback loop for a spec |
 | `grill-intent` | Stress-testing an existing spec for weaknesses |
 | `split-intent-to-issues` | Breaking a spec into Linear / Jira / GitHub Issues tickets |

package/dist/index.js

@@ -72866,7 +72866,7 @@ module.exports = /*#__PURE__*/JSON.parse('{"$schema":"http://json-schema.org/dra
 /***/ ((module) => {
 
 "use strict";
-module.exports = /*#__PURE__*/JSON.parse('{"name":"@pathmode/mcp-server","version":"1.21.0","publishConfig":{"access":"public"},"mcpName":"io.github.pathmodeio/mcp-server","description":"Deterministic intent preflight before your agent builds: six calibrated gates, keyless, no model call. Draft and sharpen specs in conversation, or connect a Pathmode workspace to sync intent and evidence across a team.","main":"dist/index.js","bin":{"pathmode-mcp":"dist/index.js"},"files":["dist/","manifest.json","icon.svg","README.md","skills/"],"scripts":{"build":"rm -rf dist && ncc build src/index.ts -o dist","dev":"ts-node src/index.ts","prepublishOnly":"npm run build"},"keywords":["pathmode","mcp","model-context-protocol","claude-code","claude-code-skills","agent-skills","cursor","windsurf","intent-engineering","intent-compiler","ai-agents","product-development","dependency-graph","strategic-planning"],"author":"Pathmode","license":"MIT","type":"commonjs","engines":{"node":">=18.0.0"},"homepage":"https://pathmode.io","dependencies":{"@modelcontextprotocol/sdk":"^1.12.1","gray-matter":"^4.0.3","zod":"^3.24.0"},"overrides":{"@hono/node-server":"^1.19.17","body-parser":"^2.3.0","fast-uri":"^3.1.6","hono":"^4.13.5","ip-address":"^10.7.0","js-yaml":"^3.15.2"},"devDependencies":{"@types/node":"^25.1.0","@vercel/ncc":"^0.38.4","ts-node":"^10.9.2","typescript":"^5.9.3"}}');
+module.exports = /*#__PURE__*/JSON.parse('{"name":"@pathmode/mcp-server","version":"1.22.0","publishConfig":{"access":"public"},"mcpName":"io.github.pathmodeio/mcp-server","description":"Deterministic intent preflight before your agent builds: six calibrated gates, keyless, no model call. Draft and sharpen specs in conversation, or connect a Pathmode workspace to sync intent and evidence across a team.","main":"dist/index.js","bin":{"pathmode-mcp":"dist/index.js"},"files":["dist/","manifest.json","icon.svg","README.md","skills/"],"scripts":{"build":"rm -rf dist && ncc build src/index.ts -o dist","dev":"ts-node src/index.ts","prepublishOnly":"npm run build"},"keywords":["pathmode","mcp","model-context-protocol","claude-code","claude-code-skills","agent-skills","cursor","windsurf","intent-engineering","intent-compiler","ai-agents","product-development","dependency-graph","strategic-planning"],"author":"Pathmode","license":"MIT","type":"commonjs","engines":{"node":">=18.0.0"},"homepage":"https://pathmode.io","dependencies":{"@modelcontextprotocol/sdk":"^1.12.1","gray-matter":"^4.0.3","zod":"^3.24.0"},"overrides":{"@hono/node-server":"^1.19.17","body-parser":"^2.3.0","fast-uri":"^3.1.6","hono":"^4.13.5","ip-address":"^10.7.0","js-yaml":"^3.15.2"},"devDependencies":{"@types/node":"^25.1.0","@vercel/ncc":"^0.38.4","ts-node":"^10.9.2","typescript":"^5.9.3"}}');
 
 /***/ })
 
@@ -73044,10 +73044,10 @@ function startMcpServer() {
     const LOCAL_MODE_INSTRUCTIONS = 'Pathmode is running in keyless local mode: specs live in intent.md in this repo and nothing leaves the machine. ' +
         'First move: call check_intent_readiness. With no arguments it reads intent.md; pass a spec inline to preflight a draft. ' +
         'If no intent exists yet, draft one from the conversation, mark inferred fields as assumptions, preflight the draft, then offer intent_save. ' +
-        'A failing verdict names the exact blockers; repair them one targeted question at a time. Never block work on a failing verdict. ' +
+        'A failing verdict names the exact blockers; repair them one targeted question at a time. Never block saving a failing spec, but do not silently start implementation from one: the user must explicitly accept the named risk. ' +
         'To sync with a shared Pathmode workspace later, run: npx @pathmode/mcp-server setup pm_live_xxx';
     const CLOUD_MODE_INSTRUCTIONS = 'Pathmode is connected to a workspace (cloud mode). ' +
-        'First move: call check_intent_readiness before implementation starts. With no arguments it resolves this repo\'s intent.md from MCP workspace roots or the server launch directory. It falls back to the workspace current intent only after client-declared roots show that no repo-bound file exists; when the repository cannot be identified it refuses to guess. A failing verdict names the exact blockers to repair. ' +
+        'First move: call check_intent_readiness before implementation starts. With no arguments it resolves this repo\'s intent.md from MCP workspace roots or the server launch directory. It falls back to the workspace current intent only after client-declared roots show that no repo-bound file exists; when the repository cannot be identified it refuses to guess. A failing verdict names the exact blockers to repair. Do not silently implement from a failing spec: repair it or get the user\'s explicit acceptance of the named risk. ' +
         'If tools fail with API error (401), the configured key is invalid: re-run npx @pathmode/mcp-server setup with a fresh key from your workspace settings at https://pathmode.io, ' +
         'or remove PATHMODE_API_KEY and restart to fall back to free keyless local mode (specs live in intent.md, no account needed).';
     const server = new mcp_js_1.McpServer({
@@ -74222,12 +74222,31 @@ function startMcpServer() {
     server.prompt('implement-intent', 'Get full implementation context for a specific intent, including objective, outcomes, constraints, edge cases, and verification steps.', {
         intentId: zod_1.z.string().describe('The intent ID to implement'),
     }, async ({ intentId }) => {
+        const localSteps = `I need to implement the repository intent ${intentId}. Please:
+1. Read intent.md as the repository authority and call check_intent_readiness with no arguments before changing product code
+2. If Preflight has unresolved blockers, show its exact verdict and repair one blocker at a time. Do not begin implementation unless I explicitly accept the named blockers in this conversation
+3. If I explicitly accept unresolved blockers, preserve that judgment in intent.md with intent_save as a decision: "Proceed despite preflight blockers: <names>", the alternative "Repair every blocker before implementation", and my reason. This is accepted risk, not a waiver: re-run Preflight and keep the failing verdict visible
+4. Review the intent, repository instructions, and implementation context, then make a plan mapped to its outcomes
+5. Implement only the authorized scope and run the intent's verification checks
+6. Review the diff against the outcomes, constraints, and edge cases
+7. Use handoff-intent to preserve material decisions, discoveries, and blockers. Do not call cloud-only tools in keyless mode`;
+        const cloudSteps = `I need to implement intent ${intentId}. Please:
+1. Call check_intent_readiness for intent ${intentId} before changing product code
+2. If Preflight has unresolved blockers, show its exact verdict and repair one blocker at a time. Do not begin implementation unless I explicitly accept the named blockers in this conversation
+3. If I explicitly accept unresolved blockers, preserve that judgment with intent_save as a decision: "Proceed despite preflight blockers: <names>", the alternative "Repair every blocker before implementation", and my reason. This is accepted risk, not a waiver. The changed repository revision requires fresh human authorization; STOP until a signed-in product owner authorizes it
+4. Once Preflight passes (or I have explicitly accepted its still-visible blockers), use get_agent_prompt to fetch the full context. Use mode "execute" for a passing verdict and mode "draft" for explicitly accepted blockers; both include authorization state and open PM change requests
+5. If a change request is open, apply it to intent.md with intent_save using its exact changeRequestId and baseRepoBodyRevision, or reject it with a concrete reason. STOP until the resulting revision is authorized
+6. Stop on a pending, rejected, or stale authorization banner. Use get_constitution and implement only after the exact current revision is authorized
+7. Plan against the outcomes, implement, and use verify_implementation against the real diff
+8. Name the work so the merge can find it: branch intent/${intentId}, or put pathmode:${intentId} in the pull request body
+9. If a pull request is involved, do not call update_intent_status; the merge owns the diff-backed transition. Otherwise mark shipped only after the outcome is observable
+10. Use handoff-intent to preserve material decisions, discoveries, and blockers`;
         return {
             messages: [{
                     role: 'user',
                     content: {
                         type: 'text',
-                        text: `I need to implement intent ${intentId}. Please:\n1. Use get_agent_prompt to fetch the full execution prompt; it includes any open PM change requests\n2. If a change request is open, read it, apply it to intent.md, and call intent_save with its exact changeRequestId and baseRepoBodyRevision. If it cannot be applied, use reject_intent_change_request with a concrete reason\n3. After any requested spec change, STOP until a signed-in product owner authorizes that exact new revision. Do not implement from a pending or stale revision\n4. Use get_constitution to check for workspace constraints I must respect\n5. Review the authorized intent details and create an implementation plan\n6. Name the work so the merge can find it: branch \`intent/${intentId}\`, or put \`pathmode:${intentId}\` in the pull request body\n7. After implementation, use verify_implementation to AI-grade your work against the spec\n8. If this change goes through a pull request, STOP there — the merge grades the real diff and moves the intent to Shipped. Do NOT call update_intent_status: an intent already at shipped is skipped by the merge, so an early flip replaces a diff-backed verdict with an unverified one\n9. Only if there will be no pull request, use update_intent_status to mark it "shipped"\n10. Use log_implementation_note to document key technical decisions`,
+                        text: isLocalMode ? localSteps : cloudSteps,
                     },
                 }],
         };
@@ -74295,6 +74314,7 @@ function startMcpServer() {
         }).optional().describe('Scope boundaries — what to build and what to avoid'),
         verification: zod_1.z.object({
             checks: zod_1.z.array(zod_1.z.object({
+                id: zod_1.z.string().trim().min(1).optional(),
                 kind: zod_1.z.enum(['fastest', 'manual', 'shipped-signal', 'regression-guard', 'test']),
                 description: zod_1.z.string(),
                 status: zod_1.z.enum(['unknown', 'passing', 'failing']).optional(),

package/manifest.json

@@ -2,7 +2,7 @@
   "manifest_version": "0.3",
   "name": "pathmode",
   "display_name": "Pathmode",
-  "version": "1.21.0",
+  "version": "1.22.0",
   "description": "Deterministic preflight for the intent you hand to a coding agent: six calibrated gates, the exact blockers named, no model call, no key needed.",
   "long_description": "Pathmode MCP Server runs a deterministic preflight before your coding agent builds: check_intent_readiness scores an intent spec against six calibrated gates (title, objective, outcomes, constraints, edge cases, verification) and names the exact blockers, with no model call and no account. Keyless local mode works out of the box; specs live in intent.md in your repo, plain markdown you own, and skills for drafting, pressure-testing, and handing off intent ride along. Connect a Pathmode workspace with an API key to sync intent and evidence across a team, analyze dependency graphs, and verify pull requests against the outcomes you agreed to.",
   "author": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pathmode/mcp-server",
-  "version": "1.21.0",
+  "version": "1.22.0",
   "publishConfig": {
     "access": "public"
   },

package/skills/README.md

@@ -13,6 +13,7 @@ Listed in lifecycle order — most projects use them in roughly this sequence.
 | `setup-pathmode-workflow` | First-time setup — capturing test commands, issue tracker, status conventions |
 | `compile-intent` | Building a structured spec for what to ship |
 | `preflight` | Deterministic readiness verdict before an agent builds — six gates, exact blockers, no model call |
+| `implement-intent` | Build from the repository intent only after Preflight and any required human authorization |
 | `verify-intent` | Designing the executable feedback loop for a spec (fastest check, manual fallback, shipped signal) |
 | `grill-intent` | Stress-testing an existing spec for weaknesses before code is written |
 | `split-intent-to-issues` | Breaking a spec into paste-ready Linear / Jira / GitHub Issues tickets |

package/skills/implement-intent/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: implement-intent
+description: Implement the repository's active intent only after running its deterministic preflight. Use when the user asks to build, implement, fix, or change product code under an intent.md. Works in keyless local mode and connected team mode.
+---
+
+<what-to-do>
+
+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.
+
+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:
+
+- `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.
+
+In connected mode, a save changes the repository-body revision. Stop until a signed-in product owner 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 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.
+
+Create a small implementation plan mapped to the outcomes. Make only the changes needed for the authorized scope. Run the spec's verification checks, review the diff against outcomes, constraints, and edge cases, and finish with `handoff-intent` so material decisions and discoveries survive the session.
+
+</what-to-do>
+
+<supporting-info>
+
+## 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.
+- **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
+
+In connected mode, name the intent where the merge can find it: branch `intent/<intent-id>`, or `pathmode:<intent-id>` in the pull-request body. When a pull request is involved, do not call `update_intent_status`; the merge grades the real diff and owns the transition to Shipped. Without a pull request, mark Shipped only when the outcome is observable.
+
+</supporting-info>