[Proposal]: Add PromptyDumpty Package Manager Support

[dasiths]

Issue Description

Add PromptyDumpty package manager support to HVE Core, enabling users to easily install chatmodes, prompts, instructions, and scripts into their projects with a single command.

Currently, users must use Git subtrees or submodules to integrate HVE Core into their projects, or manually clone and configure a multi-root workspace. This approach works but has inherent limitations around versioning, selective installation, and maintenance overhead.

Proposed Solution

Introduce a dumpty.package.yaml manifest file that defines all HVE Core artifacts as a PromptyDumpty package. This provides a modern package management experience alongside the existing Git-based integration methods.

Package Structure

The manifest will organize 61 artifacts into 8 categories:

Artifacts by Type

• 14 Chatmodes - Task planning, research, ADR creation, data science, PR review, etc.
• 10 Prompts - Git workflows, ADO automation, issue management
• 17 Instructions - Language-specific and workflow-specific coding guidelines
• 20 Scripts - Linting, security validation, and development tools

Categories

• ado - Azure DevOps workflows and automation
• git - Git workflows and automation
• development - Development workflows and task management
• documentation - Documentation generation and management
• testing - Testing and quality assurance
• security - Security scanning and validation
• linting - Code quality and linting tools
• data-science - Data science and analytics workflows

Comparison: Git Subtree vs PromptyDumpty

Git Subtree Approach (Current)

How it works:

# Add HVE Core as a subtree
git subtree add --prefix .hve-core https://github.com/dasiths/hve-core main --squash

# Update to latest
git subtree pull --prefix .hve-core https://github.com/dasiths/hve-core main --squash

Pros:

• ✅ Native Git integration - No additional tools required

Cons:

• ❌ All-or-nothing - No selective installation by category
• ❌ Local modifications drift - Customizing artifacts would required upstream push

PromptyDumpty Approach (Proposed)

How it works:

# Install all categories
pip install prompty-dumpty
dumpty install https://github.com/dasiths/hve-core

# Or install specific categories only
dumpty install https://github.com/dasiths/hve-core --categories data-science,git

Pros:

• ✅ Selective installation - Install only needed categories (e.g., just data-science or git)
• ✅ Version locking - Lockfile tracks exact commit SHA for reproducibility
• ✅ Supports multiple accelerators - Can use the package manager to install multiple hve-core type accelerators.

Cons:

• ❌ Additional tool dependency - Requires Python/pip and PromptyDumpty

Additional Context

After implementation, users can install like this:

# Install everything
pip install prompty-dumpty
dumpty install https://github.com/microsoft/hve-core

# update
dumpty update hve-core

# Install specific categories only
dumpty install https://github.com/microsoft/hve-core --categories development,git

# Install for data science workflows
dumpty install https://github.com/microsoft/hve-core --categories data-science,development

[bindsi]

@martinpeck can you move your comment from the PR here too?

@dasiths I find this very interesting but still wondering how it works...does it mean when I now add the repo via git subtree to my repo it will not install any of the categories configured in the dumpty.package.yaml by default, rather wenn I particularly install the prompty-dumpty package via, e. g. dumpty install https://github.com/microsoft/hve-core --categories development,git

[bindsi]

@WilliamBerryiii maybe a new discussion is more suitable here than an issue

[dasiths]

@bindsi The installation process does not require you clone the hve-core repo at all. All you need to ensure is that your git credential manager has access configured to hve-core (or any repo your installing assets from).

Dumpty CLI handles the rest.

You can just do.

dumpty install https://github.com/microsoft/hve-core

The tool will go look at the repo, find the dumpty manifest and then present you with the option of what assets to install. You can find out a bit more here as well. https://dumpty.dev/

Does that answer your question?

[martinpeck]

The following repeats most of the comments I made on the PR...

PromptyDumpty itself looks interesting. My question is "how do we want/expect hve-core to be installed by users?".

The current guidance (and, I assume, testing) assumes that hve-core is cloned beside the project you're working on. That has some benefits:

• the hve-core files do not pollute the project
• the hve-core files can easily be updated if improvements are made (by git pull)

However, the current guidance also has downsides:

• if the user modifies the hve-core files for their own purposes, those look like changes in git

The PromptyDumpty approach is different. Instead of using git it grabs copies of the files needed. These files are then detached from their origin, and are added into the target project repo as "regular files"

Personally, I like the PromptyDumpty approach. It's much clearer that these hve-core files become the users's files, and there there is no expectation that these files will be updated with back-compat in mind. Project-specific changes to these files can be committed along with the project.

However, I worry that having 2 very different approaches confuses the user. Which do they pick, and why? My suggestion is that hve-core has one "opinionated" view of how it is used, and how it is installed, and that it should avoid having multiple options. If PromptyDumpty is that approach then great.

If you want to have two approaches then both need to be tested, and both need to be explained in a way that helps users know which to choose and why.

[BTW, I have no skin in this game at all. I just want to make sure that hve-core doesn't scare first-time users off by presenting a matrix of options and approaches, or give itself problems in terms of testing/supporting/documenting the differences in those approaches]

[martinpeck]

To summarise my comments above, I like the fact that dumpty just grabs files from a source location, and drops them into the user's repo. It's clean, easy to understand. "Here are some files...they're yours now". It might also allow coding agents outside of VS Code to make use of the files.

I also like the way that hve-core currently works. The repo is copied (cloned) to your machine, separate from the user's repo. It acts as a tool, and as such isn't checked in with the code that it works upon.

There are pros and cons to both. But...I'd suggest you pick just one approach, based upon those pros and cons. I'm not sure hve-core is mature or established enough to need two approaches, and as you add options you add support and cognitive overhead.

Perhaps it's worth listing the pros and cons, and assessing this proposal based upon these lists, but the hve-core current approach has one very big advantage here....it's the current approach :)

[bindsi]

thanks both...now, I fully got it --> really like this, tbh.
As Martin states above, either approach is quite good enough to integrate the repo and use it as a tool to support your actual working trunk...
but I really like the idea of installing it like a package and only use the stuff you want. You will have copies of the files as well when using the git approach...with git you should also think to use submodule if you want to contribute back to the origin or subtree if you want to go with your own version...depending on the use-case.
IMHO, since hve-core will grow for sure in that massively evolving AI space the prompty-dumpty approach is a fantastic tool to quickly enable the desired "categories" and bring value for users 👍

[WilliamBerryiii]

Given that PromptyDumpty would be the core installer for this library (and therefore it's only operational dependency), the solution should be moved to a MSFT owned organization (requiring executive sponsorship) to minimize risk to this project and for those adopting it. That work will require the implementation of a full build and linting system (with particular focus on pip audit and automated reporting to advisory CVE databases), dependabot integration, codeql integration, worflow dependency sha pinning, and an ongoing maintenance commitment. I'd also suggest as part of this that the project pick up a name that fits the HVE ecosystem and branding aligned with this repo and the other HVE/customer-0 assets.

[dasiths]

Given that PromptyDumpty would be the core installer for this library (and therefore it's only operational dependency), the solution should be moved to a MSFT owned organization (requiring executive sponsorship) to minimize risk to this project and for those adopting it. That work will require the implementation of a full build and linting system (with particular focus on pip audit and automated reporting to advisory CVE databases), dependabot integration, codeql integration, worflow dependency sha pinning, and an ongoing maintenance commitment. I'd also suggest as part of this that the project pick up a name that fits the HVE ecosystem and branding aligned with this repo and the other HVE/customer-0 assets.

Thank you for having a look Bill. How do we proceed from here? Is there some guidance I can follow to make those things happen?

[martinpeck]

I think the first thing to do is to work out if hve-core wants to change the approach for installation first, and then pick a tool (or implement something) that delivers that approach.

Right now, the approach hve-core uses today is git clone, and it installs outside of the project repo.

The dumpty proposal changes that approach to one of "copy files and add them to the target project".

Other approaches exist (pip install, npm install).

As said, there are pros/cons to each. I don't enumerate them here.

So, the first question is what approach does hve-core want to take, and partly that's guided by where we want hve-core files to land, and if we consider them static artefacts (i.e unchanging, much like pip install will installs packages that you don't expect anyone to then edit locally), or that the end-user will own (files explicitly in the project repo that are either templates or starting points, but are ultimately owned by the user), or that are universal tools on the machine (the current approach treats hve-core like a tool that is outside of, and not part of the user's project).

Once an approach has been picked, only then pick the tooling to deliver that approach.

On tooling, I think dumpty has one very big disadvantage; no one knows what it is or has it installed on their machine.

When you ask people to give hve-core a go, you want the friction to be as small as possible. Almost everyone will have git installed, so git clone is easy. Many people working on AI/agents will have Python installed, so pip is also a good choice. No one will have dumpty installed, and so when presented with hve-core those users will be thinking...

"I'm taking a bet on hve-core being something useful, but to install it I have to take another bet on a dumpty which I've never heard of"

Dumpty is, itself, installed via pip so you will end up with dumpty as a dependency in your project, or you end up with it in your global pip cache. Honesty, after worrying about this stuff for a bit, I'll probably not bother with dumpty or hve-core.

If hve-core is in a mode where it's trying to gain users, gain following, and be as easy/frictionless as possible, it would be wise to stick to an approach everyone understands, and install mechanisms that most users will already have.

Moving dumpty into a the microsoft org on GitHub might help a little, but not much.

So, as I say, my suggestion is to consider the approach first, tooling second.

I think this proposal is really interesting because it opens up this discussion. I also think dumpty has a good approach. If the approach that dumpty supports is appealing, and if hve-core decides to take dumpty as a dependency, then at least be aware that this might add install friction until/unless dumpty gets it's own following.

Unless, of course, hve-core wants to help dumpty get that following by being one of its first adopters.

[dasiths]

Sorry for the late response but here are some thoughts.

So, as I say, my suggestion is to consider the approach first, tooling second.

I concur.

I think the first thing to do is to work out if hve-core wants to change the approach for installation first, and then pick a tool (or implement something) that delivers that approach.

We need to decide if the purpose of hve-core is to function as an accelerator that you pull once from and mutate to fit your use case, or a tool that you keep alongside your code?

We have been having this conversation within the ANZ studio recently and @jakkaj had some opinions around it too. I think these agent assets should be allowed to be part of the end-user solution and evolve over time with the solution itself. Versioning and updating these assets at origin should be allowed but "re-integration" of them to the target repo (cherry picking) must be handled as a first class concept.

On tooling, I think dumpty has one very big disadvantage; no one knows what it is or has it installed on their machine.

Yes but you can achieve the same "experience" with uvx via git. PromptyDumpty is just one way to achieve the same outcome.

If hve-core is in a mode where it's trying to gain users, gain following, and be as easy/frictionless as possible, it would be wise to stick to an approach everyone understands, and install mechanisms that most users will already have.

I think it is important to define the role of hve-core clearly and then pick an approach that fulfils this purpose in a way that has less friction. IMHO we should strive for understandability but not at the cost of core functionality or purpose.

@WilliamBerryiii I know VSCode might soon have some opinions around this too but we need to really carefully think about the lifecycle of these assets and not just the initial distribution problem.