@pathmode/mcp-server 1.4.5 → 1.6.0

package/dist/install-skills.d.ts

@@ -0,0 +1,13 @@
+/**
+ * Pathmode MCP Install Skills Command
+ *
+ * Copies the bundled Claude Code skill pack into .claude/skills/
+ * (project-local, default) or ~/.claude/skills/ (global, with --global).
+ *
+ * Usage:
+ *   npx @pathmode/mcp-server install-skills
+ *   npx @pathmode/mcp-server install-skills --global
+ *   npx @pathmode/mcp-server install-skills --force
+ */
+export declare function isInstallSkillsCommand(argv?: string[]): boolean;
+export declare function runInstallSkills(): Promise<void>;

package/dist/install-skills.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"","sourceRoot":"","sources":["file:///Users/jannelammi/code/Pathmode/packages/mcp-server/src/install-skills.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAmBH,wBAAgB,sBAAsB,CAAC,IAAI,WAAe,GAAG,OAAO,CAEnE;AAoDD,wBAAsB,gBAAgB,kBAsGrC"}

package/dist/intent-compiler.d.ts

@@ -32,6 +32,17 @@ export interface IntentFields {
         unitTests?: string[];
         e2eTests?: string[];
     };
+    /** Repo-analysis context (cloud intents). Richer than the structured fields:
+     *  risks are real edge cases, verificationSuggestions are sharp grader checks. */
+    implementationContext?: {
+        relevantAreas?: {
+            path: string;
+            reason: string;
+        }[];
+        currentBehavior?: string;
+        risks?: string[];
+        verificationSuggestions?: string[];
+    } | null;
 }
 /**
  * Returns the system prompt that turns Claude into a Socratic intent interviewer.
@@ -54,3 +65,25 @@ export declare function formatCursorRules(spec: IntentFields): string;
  * Adapted from lib/agentPromptGenerator.ts generateClaudeMdContent().
  */
 export declare function formatClaudeMdSection(spec: IntentFields): string;
+export interface OutcomeRubricOptions {
+    /**
+     * Workspace constitution rules. Rendered as cross-cutting "out of bounds"
+     * criteria the grader fails the artifact on if violated. Not present on the
+     * local IntentFields — supplied by the cloud export path.
+     */
+    constitutionRules?: string[];
+    /** Suggested grade-and-revise loop cap. Outcomes default is 3, max 20. */
+    maxIterations?: number;
+}
+/**
+ * Generate a Claude Managed Agents "Outcomes" rubric document for an intent.
+ *
+ * Outcomes (`user.define_outcome`) takes two separate fields: a `description`
+ * the writer agent reads, and a `rubric` the independent grader reads. This
+ * exporter renders both — clearly separated so they paste straight into the API —
+ * turning the intent's outcomes, edge cases, constraints, constitution rules and
+ * verification into checkable, evidence-forcing grader criteria.
+ *
+ * Docs: https://platform.claude.com/docs/en/managed-agents/define-outcomes
+ */
+export declare function formatOutcomeRubric(spec: IntentFields, opts?: OutcomeRubricOptions): string;

package/dist/intent-compiler.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"","sourceRoot":"","sources":["file:///Users/jannelammi/code/Pathmode/packages/mcp-server/src/intent-compiler.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAMH,MAAM,WAAW,YAAY;IACzB,EAAE,CAAC,EAAE,MAAM,CAAC;IACZ,KAAK,EAAE,MAAM,CAAC;IACd,SAAS,EAAE,MAAM,CAAC;IAClB,QAAQ,EAAE,CAAC,MAAM,GAAG;QAAE,EAAE,CAAC,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAC;QAAC,QAAQ,CAAC,EAAE,MAAM,GAAG,QAAQ,GAAG,OAAO,CAAA;KAAE,CAAC,EAAE,CAAC;IAC7F,WAAW,CAAC,EAAE,MAAM,EAAE,CAAC;IACvB,SAAS,CAAC,EAAE;QAAE,QAAQ,EAAE,MAAM,CAAC;QAAC,gBAAgB,EAAE,MAAM,CAAA;KAAE,EAAE,CAAC;IAC7D,aAAa,CAAC,EAAE,MAAM,EAAE,CAAC;IACzB,KAAK,CAAC,EAAE;QAAE,OAAO,CAAC,EAAE,MAAM,EAAE,CAAC;QAAC,UAAU,CAAC,EAAE,MAAM,EAAE,CAAA;KAAE,CAAC;IACtD,YAAY,CAAC,EAAE;QACX,YAAY,CAAC,EAAE,MAAM,EAAE,CAAC;QACxB,SAAS,CAAC,EAAE,MAAM,EAAE,CAAC;QACrB,QAAQ,CAAC,EAAE,MAAM,EAAE,CAAC;KACvB,CAAC;CACL;AAwDD;;;GAGG;AACH,wBAAgB,sBAAsB,IAAI,MAAM,CA2D/C;AAOD;;;GAGG;AACH,wBAAgB,cAAc,CAAC,IAAI,EAAE,YAAY,GAAG,MAAM,CA+FzD;AAOD;;;GAGG;AACH,wBAAgB,iBAAiB,CAAC,IAAI,EAAE,YAAY,GAAG,MAAM,CAwF5D;AAOD;;;;GAIG;AACH,wBAAgB,qBAAqB,CAAC,IAAI,EAAE,YAAY,GAAG,MAAM,CAsDhE"}
+{"version":3,"file":"","sourceRoot":"","sources":["file:///Users/jannelammi/code/Pathmode/packages/mcp-server/src/intent-compiler.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAMH,MAAM,WAAW,YAAY;IACzB,EAAE,CAAC,EAAE,MAAM,CAAC;IACZ,KAAK,EAAE,MAAM,CAAC;IACd,SAAS,EAAE,MAAM,CAAC;IAClB,QAAQ,EAAE,CAAC,MAAM,GAAG;QAAE,EAAE,CAAC,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAC;QAAC,QAAQ,CAAC,EAAE,MAAM,GAAG,QAAQ,GAAG,OAAO,CAAA;KAAE,CAAC,EAAE,CAAC;IAC7F,WAAW,CAAC,EAAE,MAAM,EAAE,CAAC;IACvB,SAAS,CAAC,EAAE;QAAE,QAAQ,EAAE,MAAM,CAAC;QAAC,gBAAgB,EAAE,MAAM,CAAA;KAAE,EAAE,CAAC;IAC7D,aAAa,CAAC,EAAE,MAAM,EAAE,CAAC;IACzB,KAAK,CAAC,EAAE;QAAE,OAAO,CAAC,EAAE,MAAM,EAAE,CAAC;QAAC,UAAU,CAAC,EAAE,MAAM,EAAE,CAAA;KAAE,CAAC;IACtD,YAAY,CAAC,EAAE;QACX,YAAY,CAAC,EAAE,MAAM,EAAE,CAAC;QACxB,SAAS,CAAC,EAAE,MAAM,EAAE,CAAC;QACrB,QAAQ,CAAC,EAAE,MAAM,EAAE,CAAC;KACvB,CAAC;IACF;sFACkF;IAClF,qBAAqB,CAAC,EAAE;QACpB,aAAa,CAAC,EAAE;YAAE,IAAI,EAAE,MAAM,CAAC;YAAC,MAAM,EAAE,MAAM,CAAA;SAAE,EAAE,CAAC;QACnD,eAAe,CAAC,EAAE,MAAM,CAAC;QACzB,KAAK,CAAC,EAAE,MAAM,EAAE,CAAC;QACjB,uBAAuB,CAAC,EAAE,MAAM,EAAE,CAAC;KACtC,GAAG,IAAI,CAAC;CACZ;AAwDD;;;GAGG;AACH,wBAAgB,sBAAsB,IAAI,MAAM,CA2D/C;AAOD;;;GAGG;AACH,wBAAgB,cAAc,CAAC,IAAI,EAAE,YAAY,GAAG,MAAM,CA+FzD;AAOD;;;GAGG;AACH,wBAAgB,iBAAiB,CAAC,IAAI,EAAE,YAAY,GAAG,MAAM,CAwF5D;AAOD;;;;GAIG;AACH,wBAAgB,qBAAqB,CAAC,IAAI,EAAE,YAAY,GAAG,MAAM,CAsDhE;AAOD,MAAM,WAAW,oBAAoB;IACjC;;;;OAIG;IACH,iBAAiB,CAAC,EAAE,MAAM,EAAE,CAAC;IAC7B,0EAA0E;IAC1E,aAAa,CAAC,EAAE,MAAM,CAAC;CAC1B;AA6KD;;;;;;;;;;GAUG;AACH,wBAAgB,mBAAmB,CAAC,IAAI,EAAE,YAAY,EAAE,IAAI,GAAE,oBAAyB,GAAG,MAAM,CAuC/F"}

package/manifest.json

@@ -2,7 +2,7 @@
   "manifest_version": "0.3",
   "name": "pathmode",
   "display_name": "Pathmode",
-  "version": "1.4.4",
+  "version": "1.5.0",
   "description": "Build structured intent specs through Socratic AI conversation, or connect to your Intent Layer for strategic context and dependency graphs.",
   "long_description": "Pathmode MCP Server includes the Intent Compiler — a zero-config Socratic conversation that helps you build structured intent specs (objectives, outcomes, constraints, edge cases) right in Claude Code. No signup needed. For teams, connect to your Pathmode workspace for dependency graph analysis (critical path, bottlenecks, cycles), workspace strategy context, and governance — so AI agents build the right thing, not just any thing.",
   "author": {
@@ -65,4 +65,4 @@
   },
   "tools_generated": true,
   "prompts_generated": true
-}
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pathmode/mcp-server",
-  "version": "1.4.5",
+  "version": "1.6.0",
   "publishConfig": {
     "access": "public"
   },
@@ -14,7 +14,8 @@
     "dist/",
     "manifest.json",
     "icon.svg",
-    "README.md"
+    "README.md",
+    "skills/"
   ],
   "scripts": {
     "build": "ncc build src/index.ts -o dist",
@@ -26,6 +27,8 @@
     "mcp",
     "model-context-protocol",
     "claude-code",
+    "claude-code-skills",
+    "agent-skills",
     "cursor",
     "windsurf",
     "intent-engineering",

package/skills/README.md

@@ -0,0 +1,77 @@
+# Pathmode Skills for Claude Code
+
+A skill pack that turns Claude Code into a product-intent-aware development partner.
+
+These skills work with the [@pathmode/mcp-server](https://www.npmjs.com/package/@pathmode/mcp-server). They auto-trigger based on what you ask Claude — no slash commands required.
+
+## Skills
+
+Listed in lifecycle order — most projects use them in roughly this sequence.
+
+| Skill | Use when |
+|-------|----------|
+| `setup-pathmode-workflow` | First-time setup — capturing test commands, issue tracker, status conventions |
+| `compile-intent` | Building a structured spec for what to ship |
+| `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 |
+| `review-against-intent` | Checking code changes against the intent's outcomes and constraints |
+| `handoff-intent` | Capturing decisions and discoveries at the end of a session |
+
+## Install
+
+1. Install the MCP server (adds `@pathmode/mcp-server` to your MCP config):
+
+   ```bash
+   npx @pathmode/mcp-server@latest setup
+   ```
+
+2. Install the skills:
+
+   ```bash
+   npx @pathmode/mcp-server install-skills            # project-local (.claude/skills/)
+   npx @pathmode/mcp-server install-skills --global   # global (~/.claude/skills/)
+   ```
+
+   Pass `--force` to overwrite skills you've previously installed.
+
+3. Restart Claude Code. The skills register at session start.
+
+## What "auto-trigger" means
+
+Skills have a `description` field Claude reads at session start. When you say "help me write a spec for the checkout flow," Claude matches your request against installed skill descriptions and runs the matching skill.
+
+You don't need to remember `/compile-intent` — just talk in plain English.
+
+## Skills + MCP
+
+Each skill orchestrates calls to the @pathmode/mcp-server. The MCP server is the engine — 15+ tools, evidence handling, Socratic preamble, dependency graphs. The skills are the auto-trigger surface on top.
+
+You can also invoke the underlying MCP prompts directly via slash commands:
+
+- `/compile-intent` (also invoked by the `compile-intent` skill)
+- `/implement-intent`
+- `/review-risks`
+- `/what-next`
+
+Skills wrap these in a more discoverable form.
+
+## Modes
+
+- **Local mode** (no API key) — Reads and writes `intent.md` in the project root. Free, no signup, fully offline.
+- **Team mode** (`PATHMODE_API_KEY` set) — Syncs intents to a Pathmode workspace. Adds evidence, dependency graphs, constitution rules, and cross-agent context. Get a key from [pathmode.io](https://pathmode.io).
+
+Skills detect the mode at runtime and adapt — same skill names, more capability in team mode.
+
+## Format
+
+Each skill is a `SKILL.md` file with YAML frontmatter (`name`, `description`) and two sections:
+
+- `<what-to-do>` — the imperative the agent follows
+- `<supporting-info>` — context, examples, and rules
+
+This matches the [mattpocock/skills](https://github.com/mattpocock/skills) format so the skills are legible to engineers already familiar with that pattern.
+
+## License
+
+MIT — see [LICENSE](../LICENSE) in the package root.

package/skills/compile-intent/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: compile-intent
+description: Build a structured intent spec through Socratic conversation. 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. Compiles to intent.md in the project root and (if an API key is set) syncs to a Pathmode workspace.
+---
+
+<what-to-do>
+
+Invoke the `compile-intent` MCP prompt from the @pathmode/mcp-server. This starts a Socratic conversation that turns a vague problem into a structured intent spec.
+
+For each question you ask, propose your best-guess answer based on the conversation so far. Don't make the user generate from a blank page.
+
+When the spec is ready, call the `intent_save` MCP tool to write `intent.md` to the project root.
+
+</what-to-do>
+
+<supporting-info>
+
+## Why Socratic, not template
+
+The compile-intent prompt is interrogative on purpose. It pushes back on vague language, challenges unmeasurable outcomes, and forces concrete constraints before moving on. Specs written in one shot tend to be wishful; specs that survive grilling are agent-ready.
+
+## Output shape
+
+`intent.md` at the project root:
+
+```markdown
+---
+id: "intent_..."
+version: 1
+status: "draft"
+---
+# [Title]
+
+## Objective
+[What needs to change and for whom]
+
+## Outcomes
+- [ ] [Observable state change, testable in under 5 minutes]
+
+## Edge Cases
+- **[Scenario]**: [Expected behavior]
+
+## Constraints
+- [Hard limit — what must never happen]
+```
+
+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.
+
+## Downstream skills
+
+After compiling, these skills consume the spec:
+
+- `grill-intent` — re-enter the Socratic loop to find weaknesses before code gets written
+- `review-against-intent` — check code changes against outcomes and constraints
+- `handoff-intent` — capture decisions and discoveries back to the spec at end of session
+
+</supporting-info>

package/skills/grill-intent/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: grill-intent
+description: Adversarial review of an existing intent spec. Walk the spec field-by-field and pressure-test the weakest claims before code gets written against them. Use when an intent feels "done" but the user wants to stress-test it, or before handing it to an implementation agent.
+---
+
+<what-to-do>
+
+Load the active intent. If a `PATHMODE_API_KEY` is set, call `get_current_intent` (Pathmode MCP). Otherwise read `intent.md` from the project root.
+
+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. In team mode, call `log_implementation_note` to record the change. In local mode, write back to `intent.md`.
+
+Stop when all five dimensions below pass, or the user explicitly accepts a known weakness.
+
+</what-to-do>
+
+<supporting-info>
+
+## The five dimensions
+
+1. **Objective** — Does it name who is harmed? Is it specific enough to disqualify other interpretations?
+2. **Outcomes** — Are they observable state changes, not activities? Could someone verify this in 5 minutes without asking the spec author?
+3. **Edge cases** — Are they real edge cases, or restatements of the outcome failing?
+4. **Constraints** — What must NEVER happen? An intent with zero constraints has no teeth.
+5. **Contradictions** — Do any two fields imply opposite things?
+
+## Stop conditions
+
+- All five dimensions pass — the spec is agent-ready
+- The user explicitly accepts a known weakness — record it with `log_implementation_note` so it's visible to future agents
+- More than 6 turns without surfacing new issues — the spec is settled
+
+## Difference from compile-intent
+
+- `compile-intent` BUILDS a spec from a vague problem
+- `grill-intent` BREAKS an existing spec to find weaknesses
+
+Run grill before treating a spec as agent-ready. If you compile a spec and immediately hand it to an implementation agent, you're trusting your first draft — and first drafts are wishful.
+
+## Codebase grounding
+
+When proposing answers, look at the actual code. If the spec says "users see a spinner during payment" but the codebase has no spinner component on the payment path, that's a gap worth surfacing. The point isn't to be right — it's to be specific enough that the user can correct you.
+
+</supporting-info>

package/skills/handoff-intent/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: handoff-intent
+description: Capture context at the end of an implementation session — decisions made, blockers hit, what's left. Use before ending a session or switching to a different intent. Ensures the next session (or the next person) doesn't lose context.
+---
+
+<what-to-do>
+
+Load the active intent. If `PATHMODE_API_KEY` is set, call `get_current_intent` (Pathmode MCP). Otherwise read `intent.md` from the project root.
+
+Summarize the session in four buckets:
+
+- What outcomes are now delivered
+- What technical decisions were made (and WHY — the "why" is what matters)
+- What was discovered that wasn't in the spec (new edge case, hidden constraint, surprising interaction)
+- What's blocked, and on what
+
+For each decision and discovery, call `log_implementation_note` with a self-contained summary. Assume the next reader has none of this conversation's context.
+
+If outcomes are delivered, propose calling `update_intent_status` with `shipped`. If the spec needs amendments based on what was learned, propose them.
+
+</what-to-do>
+
+<supporting-info>
+
+## What good handoff notes look like
+
+Bad: "Fixed the timeout bug."
+
+Good: "Reduced payment timeout from 30s to 3s by switching from polling to webhook callbacks. Webhook requires Stripe whitelist for the staging IP — see ticket OPS-1234 for the IP request. Tradeoff accepted: webhooks are async, so the success page now needs to handle the pending state for ~2s while waiting for confirmation."
+
+The "why" and the "what's still implicit" are the parts that disappear if you don't capture them.
+
+## Status bumps
+
+- `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)
+
+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
+
+A commit message records what the code did.
+A handoff note records what the engineer learned and decided.
+
+Both matter. They live in different places. This skill writes to the intent layer; git keeps the code layer.
+
+## What NOT to capture
+
+Routine implementation details ("used a `for` loop instead of `map`") are not handoff material. Capture only what would surprise the next reader — non-obvious decisions, hidden constraints, accepted tradeoffs.
+
+</supporting-info>

package/skills/review-against-intent/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: review-against-intent
+description: Review code changes against the active intent's outcomes and constraints. Use after writing code meant to implement an intent, or when reviewing a PR to check it actually delivers on the spec. Anchors review to product intent, not generic code style.
+---
+
+<what-to-do>
+
+Load the active intent. If `PATHMODE_API_KEY` is set, call `get_current_intent` (Pathmode MCP). Otherwise read `intent.md` from the project root.
+
+Identify the changed files using git diff against the base branch (or staged changes if no base specified).
+
+For each outcome in the intent, check whether the changes actually deliver it — with specific file/line evidence. For each constraint, check whether the changes respect it. For each edge case, check whether it's handled.
+
+Report:
+- Outcomes delivered (with file/line evidence)
+- Outcomes not yet delivered (and what's missing)
+- 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.
+
+</what-to-do>
+
+<supporting-info>
+
+## Why anchor to intent, not generic review
+
+Most code review tools check correctness, style, or security. They cannot check whether the code does what it was MEANT to do, because they don't see the intent.
+
+This skill bridges that gap. It treats the intent spec as a contract and the code change as the proposed satisfaction of that contract. A PR can pass every other check and still fail this one — because the intent it was supposed to deliver isn't actually delivered.
+
+## What "delivers an outcome" looks like
+
+For an outcome like "Payment completes in under 3 seconds (p95)":
+
+- ✓ The payment code path has a measurable timeout under 3s
+- ✓ There's a metric or test confirming p95 behavior
+- ✓ Failure modes are handled (covers the constraint side)
+
+A code change that adds a feature without a corresponding metric does NOT deliver this outcome. Surface that gap.
+
+## Constraint violations
+
+Constraints are hard limits — "PII must not survive a logout", "checkout must not block on network calls > 500ms", etc.
+
+If a change introduces a constraint violation, treat it as a blocker. Be specific: name the constraint, name the file/line, explain how the change violates it.
+
+## Logging gaps
+
+When the review finds gaps, the user often wants to record what's not yet done so a future session can pick it up. Call `log_implementation_note` for each significant gap. Make the note self-contained — the next reader won't have this conversation's context.
+
+</supporting-info>

package/skills/setup-pathmode-workflow/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: setup-pathmode-workflow
+description: Interview the user about their development workflow and capture the answers as durable context. Use when starting a new project with Pathmode, onboarding a teammate to an existing project, or when intent specs feel disconnected from how the team actually ships. Output is workflow conventions the next agent session will read.
+---
+
+<what-to-do>
+
+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):
+
+1. **Primary agent**: Which AI coding agent does the user primarily work with? (Claude Code, Cursor, Windsurf, Copilot, mixed)
+2. **Issue tracker**: Where do tickets live? (Linear, Jira, GitHub Issues, none yet)
+3. **Test command**: What does the user run to prove code works locally? (e.g., `npm test`, `pytest`, `pnpm vitest`)
+4. **Build/typecheck command**: What does the user run to prove code compiles? (e.g., `npm run build`, `tsc --noEmit`)
+5. **PR conventions**: How does code get reviewed before merge? (draft PR + review, trunk-based, solo)
+6. **Status mapping**: What concrete event marks an intent as `shipped`? As `verified`? (merge to main, deploy to prod, metric hold for 1 week)
+7. **Implementation note convention**: Where should agent decisions get captured? (Pathmode `log_implementation_note`, ADR file, commit messages, PR descriptions)
+
+When all questions are answered, output a single self-contained block the user can paste into their `CLAUDE.md` file (or the equivalent for their agent). Format:
+
+```markdown
+## Pathmode Workflow Conventions
+
+- Primary agent: [answer]
+- Issue tracker: [answer]
+- Test: `[command]`
+- Typecheck/build: `[command]`
+- PR conventions: [answer]
+- Status mapping: shipped = [event]; verified = [event]
+- Implementation notes: [convention]
+```
+
+If `PATHMODE_API_KEY` is set, ALSO call `log_implementation_note` against a workspace-level convention record (the user's current intent if any, otherwise the first intent in the workspace) so other team members and other agents inherit the conventions.
+
+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.
+
+</what-to-do>
+
+<supporting-info>
+
+## Why these questions
+
+Each question maps to a real friction point in agent-assisted development:
+
+- **Primary agent** → tells Claude which other agents will read the same conventions (different agents have different config file conventions)
+- **Issue tracker** → tells `split-intent-to-issues` where to format output for
+- **Test command** → tells `review-against-intent` how to check that outcomes are actually delivered
+- **Build/typecheck** → same; the fastest feedback loop is usually typecheck
+- **PR conventions** → tells `handoff-intent` whether decisions go in PR descriptions or somewhere else
+- **Status mapping** → tells `handoff-intent` when to propose `update_intent_status` to `shipped` vs `verified`
+- **Implementation note convention** → tells every skill where decisions persist
+
+Without these answers, every skill has to re-ask the same questions every session. Capturing them once makes downstream skills feel native.
+
+## Inferring from the repo
+
+Before asking, look at the repo:
+
+- `package.json` `scripts` field → likely test/build/typecheck commands
+- `.github/workflows/` → likely CI commands the team trusts
+- `CONTRIBUTING.md`, `CODEOWNERS`, PR templates → PR conventions
+- `.linear/`, `.jira/`, `.github/ISSUE_TEMPLATE/` → likely issue tracker
+- Existing `CLAUDE.md`, `.cursorrules`, `.windsurfrules` → likely primary agent
+
+For each inference, propose it as the best-guess answer ("Looks like you use Linear — there's a `.linear/` directory. Is that right, or are tickets actually in [other place]?").
+
+## Mode behavior
+
+- **Local mode (no API key)** — Output goes to `CLAUDE.md` only. The user paste-edits it themselves. The skill does not write files.
+- **Team mode (`PATHMODE_API_KEY` set)** — Same `CLAUDE.md` output, PLUS a `log_implementation_note` call so the conventions are visible in the Pathmode workspace.
+
+## What this skill does NOT do
+
+- Does not write to `.pathmode/` or any repo subdirectory beyond `CLAUDE.md`
+- Does not run npm install, set up CI, or modify the repo's tooling
+- Does not connect to Linear/Jira/GitHub APIs — only captures the user's intent for which tracker they use
+
+It is an interview, not an installer.
+
+</supporting-info>

package/skills/split-intent-to-issues/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: split-intent-to-issues
+description: Break an intent spec into 3-10 paste-ready tickets for Linear, Jira, or GitHub Issues. Use when a spec is ready to be worked on but it's too big for a single change, or when handing the spec to engineers who track work in tickets rather than reading intent specs. Each ticket links back to the outcome it delivers.
+---
+
+<what-to-do>
+
+Load the active intent. If `PATHMODE_API_KEY` is set, call `get_current_intent`. Otherwise read `intent.md` from the project root.
+
+Analyze the spec. The outcomes are the natural decomposition unit — each outcome typically maps to 1-3 tickets, depending on complexity.
+
+For each outcome, propose tickets. A ticket has:
+
+- **Title** — imperative verb phrase under 70 characters (e.g., "Add payment timeout monitoring", not "We should add a thing for timeouts")
+- **Body** — 2-4 sentences: what changes, why, how to verify it works
+- **Acceptance criteria** — concrete checklist linked to the outcome it delivers (copy from the spec, don't reword)
+- **Outcome reference** — the outcome ID or text this ticket delivers
+
+Output all tickets in a single block formatted for the user's tracker. Detect the tracker from these signals (in order):
+
+1. If they ran `setup-pathmode-workflow`, use the answer captured there
+2. If `.linear/`, `.jira/`, or `.github/ISSUE_TEMPLATE/` is present, use that
+3. If `gh` CLI is available, default to GitHub Issues
+4. Otherwise ask: Linear, Jira, GitHub Issues, or plain markdown?
+
+For each tracker, output in its native format (markdown for Linear/Jira/GitHub all work; some teams have field conventions — surface them if found).
+
+After the output, offer to create the issues automatically if `gh` (GitHub), `linear-cli`, or `jira-cli` is available. Do NOT create them without explicit confirmation.
+
+</what-to-do>
+
+<supporting-info>
+
+## Why split by outcome, not by file
+
+A common anti-pattern is splitting work by file or by component ("update PaymentForm.tsx", "update PaymentService.ts"). This produces tickets that are individually meaningless — they don't deliver an outcome by themselves.
+
+Splitting by outcome means each ticket delivers something user-visible. The closing of the ticket proves an outcome moved from "draft" to "delivered." This is what makes the intent → ticket → code chain coherent.
+
+## Sizing heuristic
+
+- 1 outcome → 1 ticket if the work fits in ~1 day for one engineer
+- 1 outcome → 2-3 tickets if it splits naturally (e.g., backend work + frontend work + observability)
+- Multiple outcomes → 1 ticket only when they're trivially coupled (rare)
+
+If a single outcome would need >3 tickets, that's a sign the outcome itself is too broad. Surface this back to the user: "This outcome is decomposing into 5 tickets — would it be cleaner to split the outcome into two before ticketing?"
+
+## Output format
+
+Default to a markdown block that works in all three trackers:
+
+```markdown
+### Ticket: [Title]
+
+**Outcome:** [outcome text from spec]
+
+[Body — what changes, why, how to verify]
+
+**Acceptance:**
+- [ ] [Criterion copied from outcome]
+- [ ] [Test/check that proves the outcome]
+
+---
+```
+
+Repeat per ticket. The `---` separator makes it easy to paste a batch.
+
+## Tracker-specific notes
+
+- **Linear** — Title goes in the title field; body + acceptance go in the description. If the user has a parent-child convention, group all tickets under a parent labeled with the intent title.
+- **Jira** — Same shape. If "Epic" is the parent convention, propose a parent Epic with the intent title.
+- **GitHub Issues** — Use a tracking issue with checkbox links to child issues for visibility.
+
+## CLI shortcut (if available)
+
+If `gh` is installed and the repo is on GitHub, offer:
+
+```bash
+# After user confirms:
+gh issue create --title "[Title]" --body "[body]" --label "intent:[intent-id]"
+```
+
+If `linear-cli` or `jira-cli` is available, propose the equivalent command. Always show the command and wait for explicit confirmation before running.
+
+## What this skill does NOT do
+
+- Does not auto-create issues without confirmation
+- Does not estimate story points or set due dates (team-specific; out of scope)
+- Does not assign tickets to people
+- Does not invent acceptance criteria — they MUST come from the intent's outcomes; the chain only works if the link is preserved
+
+</supporting-info>

package/skills/verify-intent/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: verify-intent
+description: Design the executable feedback loop for an intent — fastest check, highest-confidence check, manual fallback, observable shipped signal, and what shouldn't regress. Use when an intent is drafted but its verification field is empty or just says "add tests." Turns the spec into a runnable contract instead of a document.
+---
+
+<what-to-do>
+
+Load the active intent. If `PATHMODE_API_KEY` is set, call `get_current_intent`. Otherwise read `intent.md` from the project root.
+
+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:
+
+1. **Fastest check** — What's the quickest signal that the code is broken? (typecheck, single unit test, lint rule)
+2. **Highest-confidence check** — What's the most reliable signal it actually works? (e2e test, integration test, manual flow)
+3. **Manual fallback** — If automation isn't available, what's the 30-second manual check? (curl command, screen recording flow, console query)
+4. **Observable shipped signal** — Once deployed, what tells you it's working in production? (metric, log pattern, user behavior change)
+5. **What must not regress** — What existing behavior would a fix here accidentally break? (named cases the user worries about)
+
+For each answer, capture it. In team mode, call `log_implementation_note` with the dimension and answer (e.g., `verification:fastest_check: npm run typecheck`). In local mode, append to the `## Verification` section of `intent.md`.
+
+When all five are answered, summarize the loop:
+
+```
+Verification loop for this intent:
+- Fastest: [command/check]
+- Highest-confidence: [command/check]
+- Manual fallback: [steps]
+- Shipped signal: [metric/log]
+- Must not regress: [named cases]
+```
+
+</what-to-do>
+
+<supporting-info>
+
+## Why five dimensions, not "tests"
+
+A `verification` field that says "add tests" is a document, not a contract. It doesn't tell an implementation agent what to actually run, and it doesn't tell a reviewer what to check.
+
+The five-dimension breakdown turns verification into something runnable:
+
+- The agent knows the **fastest check** to run after every change → tight feedback loop
+- The agent knows the **highest-confidence check** to run before declaring done → catches issues
+- The user has a **manual fallback** when CI is broken or the test framework is mid-migration
+- The team has a **shipped signal** to watch in production → closes the deploy-to-verify gap
+- Everyone knows what **must not regress** → prevents the "fix that broke unrelated thing" pattern
+
+## Concrete example
+
+Intent: "Payment completes in under 3 seconds (p95)"
+
+Bad verification: "Add a test for the payment timeout."
+
+Good verification (five dimensions):
+
+- Fastest check: `pnpm vitest run payment-timeout.test.ts` — 2s, runs locally on save
+- Highest-confidence: `pnpm playwright test payment-flow.spec.ts` — 30s, hits the actual payment provider sandbox
+- Manual fallback: Open `/checkout`, add a $1 item, complete payment, time the wall clock from "pay" click to confirmation screen
+- Shipped signal: Datadog metric `checkout.payment.duration.p95` < 3000ms over 24h after deploy
+- Must not regress: Refund flow (uses the same payment service); guest checkout (different code path that calls the same client)
+
+The first version is a wish. The second version is a contract.
+
+## Mode behavior
+
+- **Team mode** — Each answer becomes a `log_implementation_note` keyed by dimension. When the verification schema lands in the spec model (planned), these notes will migrate to a structured `verification` field. Until then, notes are the durable store.
+- **Local mode** — Answers append to `## Verification` in `intent.md` as a markdown section. Simple, no schema dependency.
+
+## Pairing with other skills
+
+- After `compile-intent` produces a spec, run `verify-intent` before treating the spec as agent-ready. A spec without a verification loop is not agent-ready.
+- Before `handoff-intent`, check that the verification loop ran — if outcomes are claimed delivered but verification was never designed, that's a gap to surface.
+- `review-against-intent` consumes the verification field to know what "delivered" means.
+
+</supporting-info>