# HVE Core: Microsoft's Opinionated Agentic SDLC Framework for GitHub Copilot > HVE Core packages agents, prompts, instructions and skills into a repeatable GitHub Copilot workflow, but Microsoft itself warns against treating it as a stable platform. Here is what it actually installs, how the RPI loop works, and where it breaks. **microsoft/hve-core** — A refined collection of Hypervelocity Engineering components (instructions, prompts, agents, and skills) to start your project off right, or upgrade your existing projects to get the most out of GitHub Copilot. - Repository: https://github.com/microsoft/hve-core - Stars: 1,478 · Forks: 314 - Language: PowerShell - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-hve-core ## What HVE Core Solves, and Who It Is Actually For Most teams using GitHub Copilot converge on the same problem: every developer writes their own prompts, gets different output quality, and none of it is reviewable. HVE Core is Microsoft's attempt to turn that ad hoc usage into a structured workflow system. It describes itself as a collection of Hypervelocity Engineering components, split into four artifact types: agents for specialized tasks such as research, planning, implementation and review; prompts as repeatable workflow entry points; instructions that apply coding standards automatically; and skills that add reusable tool capabilities. The intended audience is not individual hobbyists. The README points team leads at a Team Adoption Guide for rolling out standards and onboarding, which tells you the design assumption is a group of developers who need the same conventions applied consistently. The repository is primarily PowerShell, and the root contains a justfile, a package.json with Pester test scripts, markdownlint and cspell configuration, and a docs directory. That layout is a repository built by people who maintain documentation and validation pipelines, not a single prompt file dropped in a gist. The README carries an unusual caution block for a Microsoft project. It calls HVE Core a highly opinionated, rapidly evolving agentic SDLC framework, and says it is best treated as a source of patterns and learning rather than a stable platform, foundation, or production dependency. It goes further: workflows, interfaces, architecture and recommended practices may change substantially, including in ways that are not backward compatible. Take that at face value. This is a reference implementation you are invited to copy, not a library you depend on. ## The RPI Loop and the Four Artifact Types The core methodology is RPI: Research, Plan, Implement, Review. The README links a dedicated guide at docs/rpi/README.md, and the entry point is the RPI Agent, invoked either from the agent picker or with the /rpi slash command. The shape of the workflow matters more than any single prompt: you describe a task, and the agent moves through four phases rather than producing code immediately. Research and Plan come before Implement, and Review comes after. That ordering is the whole argument. It is a deliberate brake on the generate-and-paste loop that most Copilot usage falls into. The four artifact types map onto that loop. Agents are the specialized workers. Prompts are the entry points that trigger a workflow. Instructions are the rules that apply to code regardless of which agent is running, which is how coding standards get enforced without a human restating them each session. Skills add tool capabilities that agents can call. A separate architecture document, docs/architecture/ai-artifacts.md, describes the prompt engineering framework and artifact types in more depth than the README attempts. The repository also ships an evals directory and an activation harness. The package.json exposes test:activation, which runs Pester tests against scripts/tests/agents/activation-harness/, and test:activation:baseline, which updates an agent activation baseline through Update-AgentActivationBaseline.ps1, with a :check variant that runs in DryRun mode. That is a meaningful signal about how the project treats agents: as artifacts with expected activation behavior that can regress, not as prose that either works or does not. It is the most interesting engineering decision visible in the repository layout. ## Installing the HVE Core Extension and Running Your First Workflow The README gives a three-step path for VS Code. Install the HVE Core extension from the VS Code Marketplace, open any project, launch GitHub Copilot Chat with Ctrl+Alt+I, then select RPI Agent from the agent picker or run /rpi and describe the task. The extension is published under the identifier ise-hve-essentials.hve-core. If you use GitHub Copilot CLI instead, the README documents a plugin marketplace flow. You register a marketplace source and then install the plugin. The source you pick determines how much the code can move under you. ```bash copilot plugin marketplace add microsoft/hve-core copilot plugin install hve-core@hve-core ``` The README lists several source forms with different stability characteristics. microsoft/hve-core tracks the current main branch with no ref. microsoft/hve-core#release/prerelease and microsoft/hve-core#release/stable are moving reviewed channels. For immutable pinning, microsoft/hve-core#prerelease-v and microsoft/hve-core#v target exact releases. The README states that reviewed source moves from main to release/prerelease to release/stable. It also notes, honestly, that behavior when switching or duplicating same-name marketplace registrations has not been observed, and points to docs/getting-started/methods/cli-plugins.md for details. For contributors working on the repository itself rather than consuming it, the justfile exposes three documentation commands. docs-dev runs the Docusaurus site locally, docs-build produces it, and docs-serve serves the built output. Those are the only recipes in the file. ```bash just docs-dev just docs-build just docs-serve ``` ## Pre-Release Everywhere: What the Release Channels Tell You The three most recent releases are all marked pre-release: hve-core-v3.3.101 on 2026-04-25, hve-core-v3.3.41 on 2026-04-02, and hve-core-v3.3.27 on 2026-03-30. The version numbers jump from 3.3.27 to 3.3.41 to 3.3.101 in under a month, which is consistent with the README's own description of a rapidly evolving framework. The last push to the repository was on 2026-04-25. This is the single most consequential fact for anyone evaluating adoption. A release labelled pre-release is not a promise of interface stability, and the README explicitly declines to make that promise anyway. If your team pins an exact release through microsoft/hve-core#v, you get reproducibility but you inherit whatever behavior that snapshot had, including any bugs fixed in later pre-releases. If you track main, you get fixes but you also get the churn the caution block warns about. There is no third option in the documented material. The repository also ships a package-migration guide at docs/getting-started/package-migration.md, described as moving from retired distribution identities, and a packages document covering distribution channels and lifecycle disclosure. The existence of a migration guide for retired identities is itself evidence that the distribution surface has already changed at least once. Plan for that to happen again. ## Where HVE Core Is the Wrong Tool The most direct limitation is stated by the project itself. If you need a dependency with a stable interface, backward compatibility guarantees, and a support contract, HVE Core is not it, and Microsoft says so in the README rather than burying it. Treating it as a production foundation contradicts the project's own documentation. There is a second, less obvious mismatch. HVE Core is deeply tied to GitHub Copilot. The agents, prompts and skills are consumed through Copilot Chat or the Copilot CLI plugin system. If your organization standardizes on a different assistant, or if you are not using Copilot at all, the components do not transfer. The patterns might inform you, but the artifacts themselves are inert. A third case: teams that want a small, single-purpose prompt. HVE Core's value comes from the system, and adopting the system means adopting a directory structure, a set of instructions that apply automatically to your code, and a workflow that inserts Research and Plan phases before implementation. If your work is a one-line fix, the overhead is real. The README's own framing supports this. It offers the HVE Builder skill, invoked with /hve-builder, specifically so you can adapt or copy relevant patterns into an agentic SDLC that you own and maintain independently. That is an admission that the full framework may be more than a given team needs. Finally, the CLI plugin documentation has a known gap. The README states plainly that behavior when switching or duplicating same-name marketplace registrations has not been observed. If your workflow involves registering the same marketplace name twice, you are outside documented territory. ## HVE Core Versus Writing Your Own Copilot Instructions The realistic alternative is not another framework. It is the .github/copilot-instructions.md file and a handful of custom agents that most Copilot users assemble themselves. That approach costs almost nothing to start and nothing to maintain, because you wrote it and you know exactly what is in it. Its weakness is that it does not scale past one team's memory. Instructions drift, nobody reviews prompt changes, and there is no test that tells you an agent stopped activating the way it used to. HVE Core's difference is process and validation. It ships an activation harness with baselines, a frontmatter validator invoked through lint:frontmatter with schema validation and warnings-as-errors, a plugin manifest sync check, and a documentation set that includes ADR consistency linting. Those are the mechanics of treating prompts and agents as reviewed artifacts. The repository also has a governance file, a code of conduct, a security policy, and a transparency note, which is what you would expect from a Microsoft open source project of this shape. The trade-off is that you inherit someone else's opinions along with the tooling. The README calls the framework highly opinionated, and the RPI phases are not optional decoration. If your team already has a working review process and a prompt library that fits it, HVE Core asks you to either adopt its conventions or spend effort extracting the parts you want. The /hve-builder skill exists precisely for that extraction path, and for many teams it is the more sensible entry point than a full install. ## Licence, Maintenance and Upgrade Cost HVE Core is MIT licensed, and the repository root contains the LICENSE file along with THIRD-PARTY-NOTICES. MIT is permissive, so copying patterns into your own agentic SDLC, which the README explicitly invites, is consistent with the licence. That said, the third-party notices file exists for a reason: if you vendor components, check what those components carry. Nothing here is legal advice, and a fork that redistributes bundled material should be reviewed by whoever handles licensing at your organization. The repository is not archived, and the last push was on 2026-04-25. The README is dated 2026-08-13, which is later than the last code push, so documentation has moved ahead of the code at least once. Read that as a signal about where maintainer attention has been. Upgrade cost is the part most teams underestimate. The README warns that changes may be substantial and not backward compatible. The project ships release-please configuration for both stable and pre-release manifests, and the package-migration guide covers retired distribution identities, so the tooling to manage version transitions exists. But the cost lands on you: every upgrade is a chance that an agent's activation behavior, a prompt's interface, or an instruction's scope has shifted. The activation baseline check in package.json is the mechanism the project uses to catch that internally. If you fork, you own building the equivalent for your fork, because the baseline is tied to this repository's agents. ## Conclusion Adopt HVE Core if you want to read and copy working patterns for Copilot agents, prompts and instructions, and you accept that the project calls itself a rapidly evolving framework rather than a platform. Do not adopt it as a production dependency, and do not pin it if you cannot absorb interface changes. Before committing, read docs/customization/forking.md, check whether the version you install is a pre-release or a stable channel, and confirm that the RPI Agent appears in the Copilot Chat agent picker after install. ## FAQ ### What is HVE Core? HVE Core is a Microsoft collection of Hypervelocity Engineering components for GitHub Copilot: agents, prompts, instructions and skills organized into a workflow system. The README describes it as a highly opinionated, rapidly evolving agentic SDLC framework intended as a source of patterns rather than a stable platform. ### What is HVE Core from Microsoft? It is an MIT-licensed repository that packages specialized agents for research, planning, implementation and review, reusable prompts, coding instructions that apply standards automatically, and skills that add tool capabilities. It is distributed as a VS Code extension and as a GitHub Copilot CLI plugin. ### How do I install the HVE Core extension? Install the HVE Core extension from the VS Code Marketplace, then open any project and launch GitHub Copilot Chat with Ctrl+Alt+I. Select RPI Agent from the agent picker or run /rpi and describe the task you want to complete. ### What is the RPI Agent in HVE Core? RPI stands for Research, Plan, Implement, Review, and the RPI Agent is the main workflow entry point. The README says you select it from the agent picker or run /rpi, and the repository links a deeper guide at docs/rpi/README.md. ### Can I install HVE Core through the GitHub Copilot CLI? Yes. The README gives copilot plugin marketplace add microsoft/hve-core followed by copilot plugin install hve-core@hve-core, and documents ref-less, moving reviewed, and immutable exact-release marketplace sources. It notes that behavior when switching or duplicating same-name marketplace registrations has not been observed. ### Is HVE Core stable enough for production use? The README explicitly says it is best treated as a source of patterns and learning rather than a stable platform, foundation, or production dependency, and warns that changes may not be backward compatible. The most recent releases are also marked pre-release. ## Sources - [Official README](https://github.com/microsoft/hve-core#readme) - [Project repository](https://github.com/microsoft/hve-core) - [Release notes](https://github.com/microsoft/hve-core/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-hve-core