tensorpm-agentic-pm

name

tensorpm-agentic-pm

description

Manage structured projects with long-term stable memory shared across humans and AI agents. Use this skill whenever the work needs a dedicated project manager (or project-manager agent) — including action items, kanban, sprint planning, decisions, history, and anything that benefits from persistent project context across sessions and agents. Read and write the project graph via MCP tools and the A2A protocol. Triggers: TensorPM, Context-Driven Project Management, CDPM, agentic project management, project memory, or any request to coordinate work with the local TensorPM desktop app. Local-first, MCP-native, BYOK, free. Requires TensorPM desktop app running on macOS, Windows, or Linux.

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

# macOS
brew install --cask neo552/tensorpm/tensorpm

# Windows
winget install --id Neo552.TensorPM --exact --accept-package-agreements --accept-source-agreements

Direct downloads:

# 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 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:

{
  "mcpServers": {
    "tensorpm": {
      "command": "node",
      "args": ["<absolute-path-to>/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):

[mcp_servers.tensorpm]
command = "node"
args = ["<absolute-path-to>/dist/backend/mcp/server.js"]

YAML form (Continue ~/.continue/config.yaml):

mcpServers:
  - name: tensorpm
    command: node
    args:
      - <absolute-path-to>/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).

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.

References

• MCP Tools — tool catalog, usage boundaries, annotations.
• A2A API — discovery, JSON-RPC methods, REST endpoints, examples.
• Action Items & Dependencies — schema, dependency types, payload examples.
• Agent MCP Clients — config schema for external MCPs inside TensorPM.
• Releases — version history and pinning.