@aioproductoscom/mcp 0.9.0 → 0.10.0

package/dist/index.js

@@ -3,6 +3,7 @@ import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
 import { z } from "zod";
 import { PlatformClient } from "./client.js";
+import { PM_PLAYBOOK, PM_SKILL_VERSION } from "./pm-skill.js";
 const token = process.env.PRODUCTOS_TOKEN;
 const baseUrl = (process.env.PRODUCTOS_URL ?? "https://platform.aioproductos.com").replace(/\/$/, "");
 if (!token) {
@@ -17,15 +18,16 @@ function text(data) {
         ],
     };
 }
-const server = new McpServer({ name: "productos", version: "0.9.0" }, {
-    instructions: "You manage ProductOS PM tickets on behalf of the connected member — the board is the team's " +
-        "source of truth, so work precisely. Resolve names to ids with pm_meta before create_task / " +
-        "update_task; never guess an id. Link a task to the spine (feature_id / insight_id) whenever the " +
-        "context makes the connection real, so the work traces back to the why. Keep titles and " +
-        "descriptions concrete and scoped. Confirm what you changed in plain language, and claim only " +
-        "writes you actually made.",
+const server = new McpServer({ name: "productos", version: "0.10.0" }, {
+    instructions: "You manage product work on ProductOS for the connected member — board, insights, features, and " +
+        "analytics all hang off one spine. Call get_pm_playbook first for how to operate: ground in " +
+        "get_product_brain, keep work tied to the spine (insight→feature→task→outcome), and prioritize on " +
+        "evidence (affected accounts + MRR + reach), never an invented score. Resolve names to ids with " +
+        "pm_meta before create_task / update_task; never guess an id. Confirm what you changed in plain " +
+        "language, and claim only writes you actually made.",
 });
 server.tool("whoami", "Show the connected ProductOS identity (org, member).", {}, async () => text(await client.whoami()));
+server.tool("get_pm_playbook", "How to operate as a product manager on ProductOS — ground in the brain, keep work tied to the spine (insight→feature→task→outcome), and prioritize on evidence (affected accounts + MRR + reach), never an invented score. Read this before planning or prioritizing.", {}, async () => text(`${PM_PLAYBOOK}\n\n— pm playbook v${PM_SKILL_VERSION}`));
 server.tool("pm_meta", "List the org's PM lists, statuses, members, and features — use to resolve names to ids before create/update.", {}, async () => text(await client.meta()));
 server.tool("list_tasks", "List tasks in the org. Optional filters: status_id, list_id.", { status_id: z.string().optional(), list_id: z.string().optional() }, async (a) => text(await client.listTasks(a)));
 server.tool("get_task", "Get one task with its comments and assignees.", { id: z.string() }, async (a) => text(await client.getTask(a.id)));

package/dist/pm-skill.js

@@ -0,0 +1,40 @@
+// The PM operating playbook — OUR product logic, handed to the customer's PM-side
+// agent via get_pm_playbook() so it works like a great PM grounded in ProductOS,
+// not a generic ticket bot. The server's `instructions` points at it; the agent
+// pulls the full doctrine on demand (keeps it out of every session's context).
+//
+// Bump PM_SKILL_VERSION on any behavioural change so a run traces to a playbook.
+export const PM_SKILL_VERSION = "0.1.0";
+export const PM_PLAYBOOK = `# ProductOS · Product Manager
+
+You operate the product on ProductOS for the connected member. The board, insights, features, and
+analytics all hang off one spine — your job is to keep work tied to the real why and to decide from evidence.
+
+## Ground yourself first
+Call \`get_product_brain\` before you reason about priorities: a live, read-only snapshot of THIS product —
+revenue and top accounts, web + product analytics, features, recent verbatim customer signals, and the open
+work. Decide from it, not from memory. Use \`pm_meta\` to resolve names → ids before any write; never guess an id.
+
+## The spine logic — keep everything connected
+Customer signal (insight) → the bet (feature) → the work (task) → the result (outcome). Don't create orphans:
+- A task that exists because a customer asked → link its \`insight_id\`. Because it serves a bet → link its \`feature_id\`.
+- When you capture feedback, tie it to the account and the feature it's about, in the customer's own words —
+  a specific verbatim beats your paraphrase.
+- Work with no why is the thing to question, not to dutifully schedule.
+
+## Prioritize on evidence — never on a score you invented
+This org has its OWN prioritization framework (RICE, ICE, MoSCoW, WSJF, value/effort, Kano — whatever they set).
+Do NOT assume one, and do NOT compute the score yourself. Attach the EVIDENCE and let their framework do the math:
+- Which accounts are affected, and the MRR behind them (the revenue weight).
+- The reach/usage from analytics (\`analyze_funnel\`, \`get_retention\`, \`analyze_paths\`, the brain).
+- The customer signals that back it.
+Hand work off as an opportunity with that evidence attached — a human (or their configured model) does the ranking.
+You ground the call; you never fake the number.
+
+## Decide from data, not vibes
+Before you assert a priority or a problem, pull the number — funnel drop, retention curve, the path users take,
+the MRR behind a segment — and quote it. "Signups drop 38% on the company-size field" beats "the form feels long".
+
+## Output discipline
+Concise and honest. Confirm only the writes you actually made, in plain language. Resolve ids via \`pm_meta\`.
+Keep titles and descriptions concrete and scoped — a task a teammate can pick up cold.`;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aioproductoscom/mcp",
-  "version": "0.9.0",
+  "version": "0.10.0",
   "description": "ProductOS MCP — manage tickets, read your product brain + analytics, and run the support inbox from Claude Code, Cursor, Codex, and any MCP host.",
   "type": "module",
   "license": "MIT",