| title | Forking and Extending HVE Core | ||||
|---|---|---|---|---|---|
| description | Fork HVE Core to create a fully customized prompt engineering framework with upstream sync and Copilot-assisted adaptation | ||||
| author | Microsoft | ||||
| ms.date | 2026-08-19 | ||||
| ms.topic | tutorial | ||||
| keywords |
|
||||
| estimated_reading_time | 10 |
Forking creates an independent copy of HVE Core that you fully control. Consider forking when in-place customization (adding instructions, adding package-scoped artifacts, extending validation) is insufficient for your needs.
- Replace core workflow agents with organization-specific versions
- Modify plugin membership, extension packaging, or the build system
- Enforce custom governance policies that require structural changes
- Maintain a private distribution channel with proprietary artifacts
- Integrate with internal systems that require changes to core scripts
- Add new agents, prompts, or instructions without modifying existing ones
- Add organization-specific artifacts under your own package-scoped namespaces
- Extend validation with custom linting scripts
- Configure existing tools through their settings files
Important
Forking introduces ongoing maintenance cost. Every upstream release requires evaluation, merge, and potential conflict resolution. Choose forking only when in-place customization cannot achieve your goals.
Fork the repository through GitHub's fork mechanism. Choose whether to fork into a personal account or an organization.
gh repo fork microsoft/hve-core --org your-org --clone
cd hve-coregit remote add upstream https://github.com/microsoft/hve-core.git
git fetch upstreamnpm ciIf your network blocks public package registries, see Install behind a restricted network. Set the registry override in your environment rather than in a fork file, so the fork stays restorable for everyone who clones it.
Update these files to reflect your organization:
package.json: Change thename,description, andrepositoryfieldsREADME.md: Update branding, installation instructions, and support linksCONTRIBUTING.md: Adjust contribution guidelines for your teamSECURITY.md: Point to your organization's security reporting process
npm run validate:local
npm run plugin:sync
npm run plugin:validateAfter forking, these areas provide the highest-value customization opportunities.
The extension/ directory contains packaging configuration for distributing the HVE Core component set as one VS Code extension. Modify extension/templates/ to customize the extension manifest,
README, and marketplace presentation. See the
VS Code Extension API for extension packaging details.
Agent and prompt files live under .github/agents/ and .github/prompts/. Restructure
these directories to match your organization's team topology or domain boundaries. Run
npm run plugin:sync to reflect eligible .github paths in root plugin.json.
If your workflows depend on MCP (Model Context Protocol) servers, configure server
definitions in .vscode/mcp.json or workspace settings. Fork-level changes let you
add organization-specific MCP servers that all relevant agents and skills can reference.
Add, modify, or remove npm scripts in package.json to match your build and validation
needs. Common additions include organization-specific linting rules, custom deployment
scripts, and integration test runners.
Customize .markdownlint.json to enforce your organization's documentation standards.
Add custom rules or adjust limits (such as line length) to match existing style guides.
Modify release-please-config.json to align with your release cadence and changelog
format. Adjust version bumping strategy and changelog sections for your workflow.
GitHub Actions workflows in .github/workflows/ define CI/CD behavior. Adjust workflow
permissions, add organization-specific validation jobs, or integrate with internal CI
systems.
Periodically pull upstream changes to receive new features, bug fixes, and security patches.
git fetch upstream
git log --oneline upstream/main..HEAD
git log --oneline HEAD..upstream/maingit checkout main
git merge upstream/mainConflicts typically occur in files you have customized. Common conflict points:
package.json(script modifications).markdownlint.json(rule adjustments)- Root
plugin.jsonmembership after artifacts are added or removed - Workflow files (permission or job changes)
For each conflict, evaluate whether to keep your change, accept the upstream change, or combine both. Validate after resolution:
npm run validate:local
npm run plugin:sync
npm run plugin:validate| Sync (accept upstream) | Skip (keep your version) |
|---|---|
Core scripts in scripts/ |
package.json (your custom fields) |
Schema files in scripts/linting/schemas/ |
README.md (your branding) |
| Agent and prompt templates | .github/workflows/ (your CI config) |
| Shared instructions | CONTRIBUTING.md (your guidelines) |
Documentation in docs/ |
Custom plugin membership and branding |
Use Copilot to accelerate upstream integration and fork maintenance. These prompts help you analyze and adapt changes efficiently.
Analyze the upstream changes between our fork and upstream/main.
Summarize what changed, identify which files conflict with our
customizations, and recommend a merge strategy for each conflict.
Review the new instruction files added in the upstream merge.
Adapt them to use our organization's terminology, coding standards,
and tool chain. Preserve the original intent while aligning with
our conventions in .github/instructions/.
Compare our fork against upstream/main. Identify files that have
diverged significantly, check for deprecated patterns we still use,
and list any new upstream features we have not adopted. Produce a
prioritized maintenance backlog.
Establish a regular maintenance cadence to keep your fork healthy.
Sync with upstream at least once per release cycle. More frequent syncs (weekly or biweekly) reduce the size of each merge and lower conflict risk.
Maintain your own version scheme in package.json that reflects your release cadence.
Track the upstream version you last synced from in a comment or separate tracking file
so you can identify the delta on each sync.
When upstream deprecates an artifact, evaluate whether to:
- Remove it from your fork immediately
- Move it under
.github/deprecated/for a documented transition period - Replace it with an organization-specific alternative
Run the full validation suite after every sync:
npm run validate:local
npm run plugin:sync
npm run plugin:validateFabrikam's platform team forks HVE Core to establish org-wide Copilot governance. They replace the default RPI workflow agents with versions that enforce Fabrikam's code review policies, add custom MCP server configurations for internal APIs, and distribute the fork as a private VS Code extension to all engineering teams. A biweekly upstream sync ensures they receive new skills and security patches without disrupting their customizations.
Woodgrove Bank's compliance team forks HVE Core to add financial regulation instructions and audit trail requirements. They customize the build system to include compliance validation scripts that check every agent and prompt for required disclaimer sections. The compliance team maintains a strict monthly sync cadence, reviewing each upstream change against regulatory requirements before merging.
- VS Code Extension API for extension packaging and distribution
- docs/contributing/ for artifact syntax and contribution guidelines
- Validation Commands and CI-Owned Lanes for local-safe defaults and separate CI lanes
🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.