Product Graphby vibeLevel.ai
User guide

Product Feature Graph

AI-agent-readable product knowledge graph platform. Agents propose graph updates via MCP, humans review and approve via web UI. The review queue keeps the graph from rotting.

Getting started

  1. 1

    Create a workspace

    Go to My workspaces and click New workspace. A personal workspace is also auto-created on first login. Each workspace holds one or more product graphs.

  2. 2

    Generate a Personal Access Token (PAT)

    Go to Account settings Tokens and create a PAT. Tokens are user-scoped and work across all your workspaces. Copy it immediately — it's only shown once. HMAC-SHA256 hashed at rest.

  3. 3

    Connect your agent via MCP

    Add the MCP server config to your agent (Claude Code, Cursor, VS Code Copilot, etc.):

    {
      "mcpServers": {
        "product-graph": {
          "type": "http",
          "url": "https://graphapi.vibelevel.ai/mcp?workspace=<your-workspace>",
          "headers": { "Authorization": "Bearer <your-pat>" }
        }
      }
    }

    Compatible with Claude Code · Cursor · Windsurf · VS Code Copilot · any MCP HTTP client.

  4. 4

    Seed your graph — run from your product repo

    Open your product repo in your coding agent (with the MCP server connected above). The agent needs to be inside the codebase to scan it properly. Then ask:

    "I'm in the [product-name] codebase. Scan this project and create a product graph for workspace <your-workspace>. Identify the main product, its key features, any reusable agent skills or patterns, and standards the project follows. Namespace product-specific node ids under the product (e.g. [product].[feature]); use bare ids only for shared nodes."

    The agent will scan your code, propose nodes and edges, and submit them for your review.

  5. 5

    Keep it updated — at the end of each coding session

    After adding features, enhancements, or new patterns in a session, ask your agent to sync:

    "Based on the changes we implemented in this session, update the product graph in workspace <your-workspace>. Add any new features, update existing ones, and if we introduced any reusable patterns, standards, or agent skills, add those too."

    Run this from inside your repo so the agent has full context of what changed.

  6. 6

    Review and approve proposals

    Agent-proposed changes land in the Pending tab of your workspace admin. Each proposal shows a structured diff — new and updated nodes grouped by type. Review, then one-click approve or reject. Only approved changes become live.

Workspaces

A workspace is your team's shared graph. It can hold several products, and that's the point: agent skills, standards, and personas defined once in the workspace apply across all of its products — define a coding standard or reusable skill and every product (and every agent) inherits it via MCP. Cross-product relationships (e.g. one product integrates with another) live in the same graph. Each workspace has a unique slug, its own members and settings, and can be public or private.

Why one graph per team, not per product: a workspace spans your products so shared standards & skills are enforced enterprise-wide and cross-product references stay in one place. Namespace product-specific node ids under their product (hiring.dashboard); reserve bare ids (capability.auth) for nodes genuinely shared across products.

Personal workspace

Auto-created on first login with your email-derived slug. Great for personal projects or experimenting.

Org workspace

Create additional workspaces for teams or products via My workspaces → New workspace.

Visibility

Public workspaces appear in the catalog. Private workspaces are only accessible to members and agents with a valid PAT.

Members

Add collaborators from Admin → Settings → Members. Members can review proposals. Admins can change workspace settings.

Read vs. write: making a workspace public grants read access only — anyone can browse the graph on the web and any agent can read it with a PAT. Proposing changes always requires membership(or owning a personal workspace), and members approve every proposal in the Pending queue. Going public never lets outsiders edit your graph.

Common setups

Solo / personal project

Use your auto-created personal workspace. Only you can read and update it. Keep it private, or make it public if you want to share the graph publicly.

Small team — shared private workspace

Create an org workspace, keep it private, and add your teammates as members (Admin → Settings → Members). Everyone on the team can propose and approve changes; nobody outside can see it.

Public product — readable by your users

Make the workspace public so anyone can browse your product graph on the web, and any AI agent can read it via MCP to build on or integrate with your product. Only members propose changes, and members approve them — so publishing never exposes editing to outsiders.

Open source / community contributions

Publish publicly so the community can consume your graph. To accept outside contributions, add trusted contributors as members so they can propose changes via MCP. Maintainers still review and approve every proposal in the Pending queue — nothing goes live unreviewed.

Graph concepts

A product graph is a structured knowledge map of your product — its features, personas, agent skills, standards, and the relationships between them. It's readable by both humans and AI agents via MCP. Schema version: v1.8 (13 node types, 14 edge relationships).

Node types

📦

Product

Root node — the whole product or platform. Everything in the graph belongs to a product.

🗂️

Product line

Major sub-product or platform division (e.g. "Hiring", "Campus", "API").

Feature

A user-facing capability — structured, named, and owned. Direct children of a product or product line.

Sub-feature

A finer-grained part of a feature when it has meaningful sub-divisions.

👁️

View mode

A distinct presentation of a feature for a specific context or user role.

Section

A UI block within a feature or view mode — useful for large, multi-panel features.

👤

Persona

A user role the product serves (Developer, Maintainer, Visitor, etc.).

💪

Capability

A cross-cutting internal capability: auth, review queue, MCP transport, etc.

🔧

Tech component

An internal infrastructure unit — Next.js, FastAPI, Postgres, Redis.

🔌

External system

A third-party system the product integrates with: Stripe, OpenAI, GitHub, etc.

🏷️

Release

A product release or version with lifecycle metadata and changelog links.

🤖

Agent skill

A reusable, versioned agent instruction. Agents follow these automatically via MCP — no copy-paste, no drift.

📝

Standard

An enforced rule or convention. Features that follow it carry that guarantee to every agent.

Edge relationships

🧩
part_ofNode belongs to a parent product, product line, or feature.
🎯
servesFeature or skill serves a persona or another feature.
🔧
usesFeature uses a capability or external system.
triggersOne feature triggers another.
📤
producesFeature produces an output node.
👁️
showsFeature shows a section or view mode.
🔗
depends_onHard dependency on another node.
🔌
integrates_withIntegration with an external system.
🌟
introduced_inNode was introduced in this release.
🔄
changed_inNode changed in this release.
⚠️
deprecated_inNode was deprecated in this release.
removed_inNode was removed in this release.
📋
followsAn agent_skill follows this standard — it obeys the rule.
📌
applies_toA standard applies to this node — the rule governs it.

Graph viewer

The interactive graph viewer (vis-network) shows each item type in a distinct color and symbol. Open it from any workspace via Graph in the nav. The left panel controls which items appear; the Display panel (top-right) hides categories. The four main controls are numbered ①–④ to match the in-app Graph Viewer Guide.

① Focus on

Pick a category (product, persona, …) and tick the items you care about. The graph narrows to them plus what they connect to. Your picks appear as chips above the graph — remove one with ✕, or "Clear all".

② Expand

How many steps out from your focused items to show. 1 = only what's directly connected; higher numbers reach further (and show more).

③ Connection types

Which kinds of links to show and follow (part_of, serves, uses, …). Untick one to hide those links and stop following them when you focus.

④ Display (top-right)

Show or hide whole item types from view. This is purely visual — it doesn't change what you've focused on. Collapsible; expanded by default.

Click an item

Opens a detail panel with its description, status, connections, and — if the node has one — a "View spec" button to read its full spec on demand.

Double-click an item

Re-focuses the graph on that item.

Pan & zoom

Scroll to zoom in/out. Drag the background to pan. Drag items to reposition them.

Graph Viewer Guide

Top-right of the graph header. Opens a numbered reference whose ①–④ badges match the controls on screen.

Large graphs

Above ~100 visible items a slowness hint appears — focus to a smaller area to speed things up. The viewer also auto-tunes physics and edges for big graphs.

Admin area

Accessible at /p/[workspace]/admin. Workspace members see a sidebar with Home, Pending, Graph, Audit, and Settings.

Home — dashboard overview

Shows product cards with node counts, pending proposal count, member count, and the Get started guide for empty workspaces.

Pending — proposal review queue

Lists all agent-proposed changes awaiting review. Click any proposal to see the full diff — nodes grouped by type with new/updated badges from simulation. One-click approve or reject. This queue is what keeps the graph accurate — without it, auto-generated graphs rot.

Audit log

Full provenance trail of every change: who proposed it (agent id or human), when, and who approved it. Expandable entries show the same diff view as the pending queue.

Settings

Rename the workspace, toggle public/private visibility, update the linked GitHub repo URL. Workspace visibility controls whether the graph appears in the public catalog.

Settings → Members

Add collaborators by email. Members can review proposals. Admins can manage workspace settings and delete the workspace.

Account → Tokens

Create and revoke Personal Access Tokens. Tokens are user-scoped and work across all workspaces. After creation, the full MCP config snippet is shown with your real token. Revoke any token instantly.

MCP connection

The MCP HTTP transport is the agent interface — 12 tools: 10 read + 2 write (propose_graph_diff, set_workspace_settings). A valid PAT is required for all access. Usage is tracked per-token per-day.

MCP config snippet

{
  "mcpServers": {
    "product-graph": {
      "type": "http",
      "url": "https://graphapi.vibelevel.ai/mcp?workspace=<your-workspace>",
      "headers": { "Authorization": "Bearer <your-pat>" }
    }
  }
}

Replace <your-workspace> with your workspace slug and <your-pat> with the token from Account → Tokens.

Compatible clients

Claude CodeCursorWindsurfVS Code CopilotAny MCP HTTP client

PAT required

All MCP access requires a Personal Access Token — including reading public graphs. Anonymous MCP reads are deprecated. Web browsing of public graphs is still available without login.

Example prompts

Run all of these from inside your product repo so your agent has full codebase context. Use with Claude Code, Cursor, VS Code Copilot, or any MCP-connected agent.

Seed a new product graph

Use this the first time, from your product repo:

"I'm in the [product-name] codebase. Scan this project and create a product graph for workspace [your-workspace]. Identify the main product, its key features, any reusable agent skills or patterns, and standards the project follows. Namespace product-specific node ids under the product (e.g. [product].[feature]); use bare ids only for shared nodes."

Update after a coding session

Run at the end of any session where you shipped features or changes:

"Based on the changes we implemented in this session, update the product graph in workspace [your-workspace]. Add any new features, update existing ones, and if we introduced any reusable patterns, standards, or agent skills, add those too."

Add a specific feature

"I just added [feature name] to [product-name]. Update the product graph in workspace [your-workspace] to include this new feature, its relationships to existing nodes, and any new agent skills or standards it introduces."

Add a reusable agent skill

When you've established a pattern your agent should always follow:

"We've established a consistent pattern for [pattern name] in this codebase. Add it as a reusable agent_skill node to workspace [your-workspace] with instructions so any agent working on this repo can follow the same pattern."

Add a coding standard

When you have a rule every agent must follow:

"Add a standard node to workspace [your-workspace] for [standard name] — this is a rule all agents working on this codebase must follow. Include rationale, examples of correct usage, and anti-examples."

Query the graph (read-only)

Ask your agent to use the graph as context while coding:

"Before we start, use the product graph for workspace [your-workspace] to understand the existing features and agent skills. Then implement [new feature] consistently with the patterns already in the graph."