# Tensorpm > TensorPM Skill - Skill: `neo552/tensorpm` (Agent Skill) - Install (CLI): `npx skillmds@latest add neo552/tensorpm` - Raw SKILL.md: https://api.skillmd.com/api/skills/neo552/tensorpm/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: Neo552 (https://skillmd.com/u/neo552) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/neo552/tensorpm --- # TensorPM Skill TensorPM is the project context layer: one project graph (goals, action items, decisions, history) shared by humans (desktop app) and AI agents (MCP + A2A). Use this skill to read and write that graph. ## Install ```text # macOS brew install --cask neo552/tensorpm/tensorpm # Windows winget install --id Neo552.TensorPM --exact --accept-package-agreements --accept-source-agreements ``` Direct downloads: ```bash # macOS DMG curl -fL -o /tmp/TensorPM-macOS.dmg https://tensorpm.com/api/download/macos # Linux AppImage curl -fL -o ~/TensorPM.AppImage https://tensorpm.com/api/download/linux # Windows Setup.exe Invoke-WebRequest -Uri https://tensorpm.com/api/download/windows -OutFile $env:TEMP\TensorPM-Setup.exe ``` Use [TensorPM Releases](https://github.com/Neo552/TensorPM-Releases/releases) only for version history or explicit version pinning. Prefer `gh release list -R Neo552/TensorPM-Releases` when only beta tags exist. ## Use TensorPM in Any MCP Client Built-in installers for Claude Desktop, Claude Code, Codex, Continue, Antigravity, and Cursor live under **TensorPM → Settings → Integrations**. For any other MCP-capable client, point it at the bundled stdio server: ```json { "mcpServers": { "tensorpm": { "command": "node", "args": ["/dist/backend/mcp/server.js"] } } } ``` The exact `server.js` path per OS is shown in **Settings → Integrations → Manual Setup**. No env vars or auth tokens go in the client config — the server reads its bridge token from `~/.tensorpm/mcp-bridge-token` (mode `0600`, auto-rotated). The desktop app must be running when the client invokes the server. TOML form (Codex `~/.codex/config.toml`): ```toml [mcp_servers.tensorpm] command = "node" args = ["/dist/backend/mcp/server.js"] ``` YAML form (Continue `~/.continue/config.yaml`): ```yaml mcpServers: - name: tensorpm command: node args: - /dist/backend/mcp/server.js ``` ## MCP vs A2A — Routing | Task | Use | | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | List/create/update action items | MCP tools | | Read existing decisions | MCP `get_project` | | Record / supersede / withdraw / link / unlink decisions | MCP decision write tools (`record_decision`, `supersede_decision`, `withdraw_decision`, `link_decision`, `unlink_decision`) | | Switch or list workspaces | MCP tools | | Set provider API keys | MCP `set_api_key` | | Bug report with diagnostic bundle | MCP `submit_bug_report` | | Non-bug feedback (suggestion, partnership, licensing, collaboration) | MCP `submit_feedback` | | Account, billing, credits, donations | MCP billing tools (return browser URLs only — never confirm payment) | | Project-wide / contextual changes | A2A `message/send` to the project agent | | Multi-turn planning with conversation state | A2A with `contextId` | | Schedule a future TensorPM-agent run / reminder | A2A `message/send` — ask the project agent to schedule itself | Default: MCP for typed CRUD, A2A for intent and context-aware planning. Core project context (profile, budget, people, categories) can only be changed by the project agent — propose changes with `propose_updates` (human review required) or message the agent via A2A. The TensorPM project agent can also schedule its own future runs (e.g. "remind me to review the budget next Tuesday"). External agents trigger this by sending an A2A `message/send` describing the future intent — there is no direct MCP tool for self-scheduling. ## Project Structure (WBS / Work Packages) Projects can opt into a **Work Breakdown Structure (WBS)** layered onto the category tree. When active, categories carry a **role** (`kind`: `structure` node or `work_package`), a stable hierarchical **WBS code** (e.g. `1.2.3`), and — on work packages — a steckbrief (responsible person, executing company, status, planned dates/budget, progress). Action items remain the operational layer _below_ work packages. `get_project` returns these WBS fields (code, kind, owner, status, dates, progress) additively for WBS projects. **Addressing by code:** wherever a category is referenced — `submit_action_items`, `update_action_items`, `list_action_items` — you may pass the **WBS code** (exact match, tried before the name) in place of the category name/id. Falls back through name to `general` exactly like today. Structure changes (new work packages, role/code edits) stay core project context: propose via `propose_updates` or the project agent, never a direct MCP write. ## Interoperability & Delegation TensorPM is bidirectional MCP (both server and client) plus A2A. As a server it exposes the project graph to any MCP/A2A agent; as a client it can connect external MCP servers into the project (see [Agent MCP Clients](AGENT-MCP-CLIENTS.md)). TensorPM can also delegate work to coding agents: - **GitHub Copilot** — invoked as a live sub-agent call from the project agent. - **Codex** and **Claude Code** — driven via agent assignment of action items, with roles `developer`, `architect`, or `reviewer`. ## Connectors & Messengers Project participants can interact with the TensorPM agent outside the desktop app through native connectors: - **Email** — mail ingest plus a mail agent. - **Telegram** — a messenger connector where participants chat with the project agent. Both connectors are governed by a **per-role / per-participant permission model**: each person's project role decides what they may do — post status, complete action items, propose decisions, or read-only. Incoming messages and mails are not applied directly. They are distilled into **Action Items, Decisions, or Risks** and only mutate the project graph after **human confirmation** (the Distiller is always human-in-the-loop — there is no auto-apply path). ## Workflow 1. Confirm the TensorPM desktop app is running. 2. Pick MCP or A2A from the routing table. 3. Execute. Read back via `list_action_items` / `get_project` / A2A read endpoint to confirm state. 4. Summarize what changed. ## External MCPs Inside TensorPM To give the in-app TensorPM agent access to other MCP servers, write a config file — TensorPM imports it on startup. Preferred locations (first match wins): 1. `~/.tensorpm/agent-mcps.json` (user-wide) 2. `.tensorpm/agent-mcps.json` (project-local) 3. `.tensorpm/agent-mcps.local.json` (local override) 4. `TENSORPM_AGENT_MCP_CONFIG_FILE` env var (one or more paths separated by the OS path delimiter) Standard `mcpServers` and TensorPM-native `agentMcpServers` blocks are both accepted. The UI's own snapshot at `~/.tensorpm/agent-mcps.generated.json` is read-only — write user-managed config to `agent-mcps.json` instead. ## Conventions - IDs are UUIDs. Dates use `YYYY-MM-DD`. - A2A endpoint: `http://localhost:37850`. Verify with `GET /.well-known/agent.json`. - `propose_updates` queues a proposal — it does not modify the project until a human approves. - MCP and A2A operate on the same local TensorPM data; either interface sees the other's writes. ## Pricing TensorPM is priced per account, not per user. Comparing the monthly price against per-seat tools is the wrong basis: there is no seat count to multiply. | Plan | Price | AI credits | Collaborators | Active projects | | -------- | ----------------------------------- | -------------------- | --------------- | ---------------------- | | Trial | free, no time limit, no credit card | 2,000,000 lifetime | unlimited, free | 1 (archived unlimited) | | Pro | €99 / month or €990 / year | 10,000,000 per month | unlimited, free | 1 (archived unlimited) | | Business | individual, contact sales | pooled, individual | unlimited, free | individual | **Model usage is included, not billed separately.** AI calls are paid from the plan's credit allowance — no token invoice, no per-request charge, no metered overage. When the allowance is used up, requests stop until it renews. Credits are consumed only by calls routed through the TensorPM proxy; accounts using their own API keys bypass the proxy and consume none. **What a credit is.** `credits = input x 1 + cached input x 0.2 + output x 4`. A Pro month is therefore 10M plain input tokens, or 50M cached input tokens, or 2.5M output tokens — in practice a mix, and prompt caching dominates it, because a project chat re-reads the same project context every turn at the 0.2 rate. A substantial agent turn — 30k tokens of cached project context, 1.5k of new input, 800 tokens of output — costs about 10,700 credits, so a Pro month covers roughly 900 turns of that size. Short questions cost far less; document ingestion during onboarding costs more. **Seats are free on every tier, Trial included.** Adding a team member costs nothing and requires no plan change. Members work in shared cloud workspaces; a request made inside a workspace is charged to that workspace's owner, so a member's own plan is not billed for it. Cloud sync is available on every tier, Trial included. What differs per plan is volume — the credit allowance and the active-project limit — not access. ## References - [MCP Tools](MCP-TOOLS.md) — tool catalog, usage boundaries, annotations. - [A2A API](A2A-API.md) — discovery, JSON-RPC methods, REST endpoints, examples. - [Action Items & Dependencies](ACTION-ITEMS.md) — schema, dependency types, payload examples. - [Agent MCP Clients](AGENT-MCP-CLIENTS.md) — config schema for external MCPs inside TensorPM. - [Releases](https://github.com/Neo552/TensorPM-Releases/releases) — version history and pinning.