Proposal for HoloViz AI Packaging and Repository Structure

[philippjfr]

Goals

• keep the AI-related tooling coherent
• make skills reusable across the ecosystem
• avoid forcing MCP, ChromaDB, or other heavy dependencies onto downstream libraries
• create a clean migration path without over-optimizing too early

Current Situation

Today there are three closely related pieces:

holoviz-mcp

An MCP server for the HoloViz ecosystem. It provides AI assistants with access to Panel, hvPlot, Lumen, Datashader, and related libraries. It currently also contains the skills and an embedded documentation retrieval setup.

panel-live-server

A local Panel web server and MCP server that executes Python snippets and renders the results as live interactive pages.

Skills

The reusable knowledge and instruction layer that helps AI systems work effectively with HoloViz libraries. These are valuable beyond holoviz-mcp, but today they live inside that repository.

The main issue is that the skills are broadly reusable, while their current home ties them to a heavier MCP-specific package and dependency stack.

---

Proposed Way Forward

1. Migrate holoviz-mcp repo to holoviz-dev

Move the existing holoviz-mcp repository into the holoviz-dev org.

This reflects its current role well:

• it is infrastructure-heavy
• it is likely to evolve quickly
• it is more experimental than foundational ecosystem packages

This keeps the project visible and official, but places it in the part of the organization better suited to fast iteration.

---

2. Set up separate publishing for holoviz-skills

In the short term, keep holoviz-mcp as the source of truth for the skills, but publish them as a separate package: holoviz-skills.

That package should:

• contain only the skills and minimal loading utilities
• avoid MCP-specific logic
• avoid ChromaDB and other heavy dependencies
• be small and dependency-free, or as close to that as possible

This gives downstream libraries a clean way to consume the skills without pulling in the full MCP stack.

In practice, this means one repository produces two packages:

holoviz-mcp

• MCP server implementation
• retrieval/indexing integrations
• protocol-specific tooling
• heavier optional dependencies

holoviz-skills

• skill definitions
• metadata and templates
• lightweight APIs for listing and loading skills

This is the fastest path to making the skills reusable across the HoloViz ecosystem.

---

3. Split out holoviz-skills into its own repo

Once the package shape and release process have stabilized, extract holoviz-skills into its own repository.

This should become the long-term home for the reusable skill layer because it has a different role from holoviz-mcp:

• it is more foundational
• it should remain lightweight
• it should be usable by multiple projects, not just MCP servers
• it benefits from having independent ownership, versioning, and governance

At that point:

• holoviz-skills can move into the holoviz org as a core ecosystem package
• holoviz-mcp can depend on it like any other consumer
• other projects such as Panel, Lumen, or future AI tooling can reuse it directly

---

Recommended Package Roles

holoviz-skills

A lightweight, reusable package containing:

• skill definitions
• prompt/configuration metadata
• minimal loading helpers

This should be usable by any HoloViz library or AI-facing integration.

holoviz-mcp

An MCP-facing integration package containing:

• MCP server implementation
• retrieval/indexing layers
• adapters that consume holoviz-skills

panel-live-server

Remain separate and focused on code execution and rendering. It can optionally consume holoviz-skills, but it should not become the home for them.

[philippjfr]

@MarcSkovMadsen for your review

[ahuang11]

For holoviz-skills, I propose a split between HoloViz user-facing developer and package-developer facing directories as well, e.g. refactoring & testing.

Related:
#168
#170

[ahuang11]

On second thought, maybe for the package-developer directories, we could have a AGENTS.md / CLAUDE.md in each package repo...