Architectural Integration Proposal: Design-Thinking Artifacts into HVE Core #485

WilliamBerryiii · 2026-02-12T04:56:24Z

WilliamBerryiii
Feb 12, 2026
Maintainer

Executive Summary

The hve-core repository (67 AI artifacts spanning agents, prompts, instructions, and skills) and the design-thinking-for-hve-capabilities repository (62 AI artifacts spanning chatmodes, prompts, guidance documents, and an M365 agent) present complementary profiles with near-zero functional overlap. hve-core provides software engineering workflows: code generation, Azure DevOps integration, Git operations, and the Research-Plan-Implement (RPI) methodology. The design-thinking repository delivers a complete design thinking methodology: 9 sequential methods across problem, solution, and implementation spaces, orchestrated through a coach + hat chatmode model with progressive coaching hints. Together these repositories encompass 129 artifacts that span both engineering execution and design methodology.

The recommended approach integrates the design-thinking repository's 32 prompt files into hve-core as Phase 1 of a three-phase approach. Prompt integration represents the lowest-risk, highest-value starting point because the existing build system already supports it without modification. Prepare-Extension.ps1 discovers prompts recursively through Get-DiscoveredPrompts, and Package-Extension.ps1 copies the entire .github/ directory into the extension package. Adding 32 prompts under a new .github/prompts/design-thinking/ subdirectory requires zero build system code changes, zero CI/CD pipeline modifications, and zero schema updates.

Before migration, a conformance remediation effort brings the design-thinking prompts from approximately 12% conformance with prompt-builder authoring standards to full compliance. The remediation follows a four-tier workflow: extend prompt-builder standards to recognize template-style prompts and the [Internal AI Context] pattern (Tier 4), add YAML frontmatter to all 32 prompts (Tier 1), restructure protocols into the Required Steps format (Tier 2), and correct writing style to remove bold-titled lists and command-style language (Tier 3). Frontmatter addition is mechanical and automatable. Protocol restructuring and writing style corrections require human judgment but follow established patterns.

The remaining artifact types follow in subsequent phases. Phase 2 converts the 20 chatmode files (implementing the coach + hat model) into agents and subagents, leveraging the existing agent infrastructure that replaced chatmodes after PR #210. The coach chatmode becomes a primary design-thinking agent, and the 19 hat chatmodes become specialized subagents. Phase 3 addresses guidance documents (9 files), which lack any supporting infrastructure. Seven open questions for community discussion shape decisions on persona granularity, ownership models, template recognition, guidance classification, hat registration strategies, maturity promotion criteria, and the independent extension alternative.

Current State

hve-core Artifact Ecosystem

The hve-core repository contains 67 AI artifacts organized across four artifact types:

22 agents providing conversational and autonomous workflows for code generation, ADO integration, Git operations, and RPI methodology
26 prompts delivering single-session workflows for research, planning, implementation, and review tasks
18 instructions files with auto-applied guidance based on file patterns covering markdown, PowerShell, C#, Python, Terraform, Bicep, and bash
1 skill package (video-to-gif) bundling documentation with executable scripts

PR #439 introduces persona-based distribution through an AI Artifacts Registry with collection manifests and maturity gating. This PR spans 131 files with +8054/-885 lines of changes, targeting milestone v2.5.0 as part of Epic #431 (6 of 8 phases complete). The registry introduces simpleArtifactEntry and agentEntry types with maturity enum values (stable, preview, experimental, deprecated) and 6 personas: hve-core-all, developer, tpm, devops, architect, and technical-writer.

The build pipeline relies on two primary scripts. Prepare-Extension.ps1 discovers artifacts using Get-DiscoveredAgents (non-recursive), Get-DiscoveredPrompts (recursive), and Get-DiscoveredInstructions (recursive), with maturity filtering for stable versus pre-release channels. Package-Extension.ps1 copies the entire .github/ directory into the VSIX package. Three extension workflows handle packaging, stable publishing, and pre-release publishing. The CI/CD pipeline runs 12+ validation checks including frontmatter validation with warnings-as-errors: true, markdown linting, spell checking, and link validation.

The extension publishes under ise-hve-essentials at version 2.2.0 with VS Code engine compatibility ^1.106.1.

design-thinking-for-hve-capabilities Artifact Ecosystem

The design-thinking repository contains 62 AI artifacts across four categories:

20 chatmodes implementing a coach + hat interaction model (1 coach chatmode routes to 19 specialized hat chatmodes)
32 prompts providing design-thinking method templates and asset creation utilities
9 guidance documents serving as runtime knowledge assets consumed by chatmodes
1 M365 agent targeting the Microsoft 365 Copilot runtime

The repository implements the Think/Speak/Empower coaching philosophy with 4-level progressive hints, where the coach chatmode orchestrates specialized hats that provide expertise in specific design-thinking activities. The 9 sequential design-thinking methods span three spaces:

Problem Space: 01 Scope Conversations, 02 Design Research, 03 Input Synthesis
Solution Space: 04 Brainstorming, 05 User Concepts, 06 Lo-Fi Prototypes
Implementation Space: 07 Hi-Fi Prototypes, 08 User Testing, 09 Iteration at Scale

The HVE Pyramid framework (Context, Guidance, Instructions, Docs) structures knowledge delivery, with the manufacturing floor serving as the canonical example domain throughout the methodology.

Complementary Profiles

Dimension	hve-core	design-thinking
Domain	Software engineering workflows	Design thinking methodology
Agents	22	0
Prompts	26	32
Instructions	18	0
Skills	1	0
Chatmodes	0	20 (convert to agents)
Guidance	0	9
M365 Agents	0	1
Prompt taxonomy	ADO/Git/GitHub/code gen/RPI	Method-specific templates + asset creation utilities
Total	67	62

hve-core provides agents, instructions, and skills that are entirely absent from the design-thinking repository. The design-thinking repository provides chatmodes and guidance documents that are entirely absent from hve-core. Since PR #210 migrated chatmodes to agents and deprecated the chatmode schema, the 20 design-thinking chatmodes convert to agents and subagents during integration rather than retaining their chatmode format. Both repositories contain prompts, but in completely different domains with zero functional overlap: hve-core prompts target software engineering tasks while design-thinking prompts target methodology execution. Together, the combined 129 artifacts would span both software engineering and design thinking methodology in a single distribution.

Artifact Selection

In Scope: 32 Design-Thinking Prompts

The 32 design-thinking prompts divide into two categories: method-specific prompts that provide templates for each of the 9 design-thinking methods, and utility prompts that create supporting assets.

Method-specific prompts (26 files):

Method	Space	Count	Examples
01 Scope Conversations	Problem	3	scope-conversation-starter, stakeholder-mapping, frozen-vs-fluid-assessment
02 Design Research	Problem	3	research-plan-creator, research-data-synthesis
03 Input Synthesis	Problem	3	synthesis-validation
04 Brainstorming	Solution	3	brainstorm-facilitator
05 User Concepts	Solution	3	concept development prompts
06 Lo-Fi Prototypes	Solution	2-3	rapid-prototyping
07 Hi-Fi Prototypes	Implementation	2-3	lo-fi-to-hi-fi
08 User Testing	Implementation	2-3	ai-persona-testing
09 Iteration at Scale	Implementation	2-3	scale iteration prompts

Utility and creation prompts (6 files):

Prompt	Purpose
create-hve-capability	Creates HVE capability artifacts
create-method-guidance	Creates method guidance documents
create-instruction-asset	Creates instruction assets
create-problem-phase-context	Creates problem phase context
port-to-pyramid	Ports content to HVE Pyramid format

All 32 prompts are in scope for Phase 1 integration. Method prompts provide the complete design-thinking methodology workflow, guiding users through each of the 9 methods from scope conversations through iteration at scale. Utility prompts provide DT-specific asset creation tooling. Even utility prompts are domain-specific (HVE Pyramid conversion, method guidance creation) and belong alongside the method prompts rather than in a separate location.

Deferred: Chatmode-to-Agent Conversion (Phase 2)

Twenty chatmode files implement the coach + hat interaction model. PR #210 deprecated the chatmode schema and migrated chatmodes to agents, so these files convert to agents and subagents during integration. Agent infrastructure already exists (Get-DiscoveredAgents, agent frontmatter schema, agent contributes key), but four conversion challenges prevent immediate integration:

Zero of 4 sampled chatmodes conform to prompt-builder standards; zero have maturity frontmatter. Each file requires restructuring from chatmode format to agent format.
The coach + hat routing pattern (1 coach delegating to 19 hats) has no direct equivalent in hve-core's agent architecture. Expressing this as a primary agent with subagent references requires defining a delegation protocol.
Progressive hints and boundary enforcement are interaction patterns that hve-core agents do not currently implement. Converting these coaching behaviors to agent instructions requires architectural design work.
The coach agent depends on prompts, guidance documents, and all 19 hat subagents. Cross-artifact dependency resolution at this scale requires registry support from PR feat(extension): implement collection-based plugin distribution system #439.

Despite these challenges, the chatmode content carries significant value. The coach chatmode is the primary interaction model for design thinking in VS Code. Without it, prompts function as standalone templates without orchestration. Converting the coach to a primary agent and each hat to a specialized subagent preserves the expertise-switching pattern that enables contextual coaching.

Deferred: Guidance Documents (Phase 3)

Zero infrastructure exists for guidance documents in hve-core: no frontmatter schema, no discovery function, no contributes key, no file type classification in the validation pipeline. Guidance files serve as runtime knowledge assets consumed by agents through read_file tool invocations. Without the converted agents that consume them (Phase 2), guidance documents have limited standalone value.

One alternative: repurposing guidance files as .instructions.md with applyTo patterns targeting design-thinking prompt files and agents. This would leverage existing infrastructure but changes the original semantics from "knowledge consumed on demand" to "auto-applied conventions."

Out of Scope: M365 Agent

The M365 agent targets the Microsoft 365 Copilot runtime, a fundamentally different execution environment from VS Code. No hve-core infrastructure supports M365 agent packaging or distribution. This agent remains with the design-thinking repository.

Selection Rationale

Complementary profiles minimize risk: hve-core contains zero design-methodology prompts; the design-thinking repository contains zero software-engineering prompts. Zero functional overlap means zero duplication risk and no conflict resolution during migration.
Prompts integrate with the existing build system: Prepare-Extension.ps1 discovers prompts recursively through Get-DiscoveredPrompts. Package-Extension.ps1 copies the entire .github/ directory. Adding prompts in a subdirectory requires no code changes to either script.
Chatmode-to-agent conversion and guidance require design work: chatmode-to-agent architectural mapping, delegation protocol design, progressive hints conversion, and cross-artifact dependency resolution represent significant engineering effort that should not block prompt integration.
Conformance is tractable for prompts: prompt-builder authoring standards already define requirements for the prompt artifact type. Frontmatter addition is mechanical. Protocol restructuring follows established Required Steps patterns with documented examples.
Value is immediate for prompts, phased for agents: users gain 32 design-thinking prompt templates immediately upon Phase 1 completion. The converted coach agent and hat subagents follow in Phase 2 once the delegation protocol and progressive hints pattern are designed.

Integration Architecture

Directory Structure

The proposed directory layout groups design-thinking prompts under a dedicated subdirectory, preserving the source repository's numeric prefix scheme that maps to the 9 sequential methods:

.github/prompts/
├── design-thinking/
│   ├── methods/
│   │   ├── 01-scope-conversation-starter.prompt.md
│   │   ├── 01-stakeholder-mapping.prompt.md
│   │   ├── 01-frozen-vs-fluid-assessment.prompt.md
│   │   ├── 02-research-plan-creator.prompt.md
│   │   ├── 02-research-data-synthesis.prompt.md
│   │   ├── ...
│   │   └── 09-*.prompt.md
│   └── utilities/
│       ├── create-hve-capability.prompt.md
│       ├── create-method-guidance.prompt.md
│       ├── create-instruction-asset.prompt.md
│       ├── create-problem-phase-context.prompt.md
│       └── port-to-pyramid.prompt.md
├── rpi.prompt.md
├── task-research.prompt.md
└── ...existing hve-core prompts

Mixing 32 new prompts alongside 26 existing prompts at the root level would create navigation difficulty. The design-thinking/ subdirectory with methods/ and utilities/ sub-groups mirrors the source repository's organizational structure. The numeric prefix scheme (01 through 09) communicates the methodology's sequential flow and helps users locate prompts for specific methods.

Important

Prompt filenames must be globally unique across all subdirectories. The build system derives each prompt's slash command name from the filename only (not the path), so methods/foo.prompt.md and utilities/foo.prompt.md would both register as /foo. The proposed naming convention avoids collisions through numeric method prefixes and verb-based utility prefixes, but contributors adding new prompts must verify filename uniqueness across sibling subdirectories.

Registry and Collection Design

Each design-thinking prompt registers as a simpleArtifactEntry in the AI Artifacts Registry with preview maturity. Preview maturity includes the prompt in pre-release channels while excluding it from stable distributions until promoted.

Registry entry example:

"design-thinking/methods/01-scope-conversation-starter": {
    "maturity": "preview",
    "personas": ["hve-core-all", "design-thinker"],
    "tags": ["design-thinking", "method-01", "scope", "stakeholder"]
}

A dedicated collection manifest groups all design-thinking prompts for opt-in installation:

{
    "id": "design-thinker",
    "name": "hve-design-thinking",
    "displayName": "HVE Design Thinking",
    "description": "Design thinking methodology prompts for the HVE Pyramid",
    "personas": ["design-thinker"],
    "maturity": "preview"
}

The tag taxonomy provides multi-dimensional filtering:

Tag	Applied To	Purpose
design-thinking	All 32 prompts	Domain identifier
method-01 to method-09	Method prompts by number	Method-level grouping
scope	Method 01 prompts	Activity-level grouping
research	Method 02 prompts	Activity-level grouping
synthesis	Method 03 prompts	Activity-level grouping
brainstorm	Method 04 prompts	Activity-level grouping
prototype	Method 06-07 prompts	Activity-level grouping
test	Method 08 prompts	Activity-level grouping
scale	Method 09 prompts	Activity-level grouping
utility	6 utility prompts	Category identifier

Important

Registry and collection features depend on PR #439 merge. Conformance remediation and file migration can proceed independently of the registry work.

Persona Taxonomy Extension

The current persona taxonomy defines six personas: hve-core-all, developer, tpm, devops, architect, and technical-writer. The integration adds design-thinker for users working with design thinking methodology. Whether design-thinking prompts should also carry the hve-core-all tag (making them available to all users) or remain design-thinker only (opt-in distribution) is an open question for community discussion.

Build System Impact

Prompt-only integration requires zero build system code changes. Every component in the build pipeline already handles subdirectory structures through recursive scanning or directory-level copying.

Component impact analysis:

Component	Impact	Changes Required
`Prepare-Extension.ps1` (`Get-DiscoveredPrompts`)	Discovers DT prompts automatically via recursive scan	None
`Package-Extension.ps1`	Copies `.github/` including DT subdirectory	None
`prompt-frontmatter.schema.json`	Validates DT prompt frontmatter (`additionalProperties: true`)	None
`schema-mapping.json`	Pattern `.github/*/.prompt.md` matches subdirectories	None
`Validate-MarkdownFrontmatter.ps1`	Classifies and validates DT prompts	None
Extension workflows	Package and publish include DT prompts	None

CI/CD pipeline impact:

CI/CD Check	Impact on DT Prompts	Prerequisite
frontmatter-validation	Validates DT prompt frontmatter	Tier 1 remediation complete
markdown-lint	Validates markdown formatting	Writing style compliance
spell-check	May flag DT-specific terminology	Add DT terms to cspell dictionary
copyright-headers	AI artifacts are exempt	None
link-lang-check	Validates internal links	Verify no broken links

Name Collision Constraint

Get-DiscoveredPrompts derives each prompt's name property from the filename alone using $promptFile.BaseName -replace '\.prompt$', ''. The directory path is not included in name derivation. This means design-thinking/methods/foo.prompt.md and design-thinking/utilities/foo.prompt.md would both resolve to the slash command /foo, creating a collision that VS Code cannot resolve. Filenames must be globally unique across all subdirectories under .github/prompts/.

The proposed naming scheme already mitigates this risk. Method prompts use numeric prefixes (01-scope-conversation-starter, 02-research-plan-creator) and utility prompts use the create- or port- prefix convention. No filename collisions exist between the methods/ and utilities/ inventories as proposed. The constraint becomes relevant when future contributors add prompts without awareness of existing filenames in sibling subdirectories.

Build-time collision detection does not exist today. Adding a validation step to Prepare-Extension.ps1 that checks for duplicate prompt names after discovery would catch collisions before they reach the VSIX package. This validation is a recommended prerequisite for the migration PR and should be tracked as a separate work item.

Contributing Documentation Update

The current contributing guide at docs/contributing/prompts.md states that all prompt files MUST be placed directly in .github/prompts/ with no subdirectory nesting. This contradicts the proposed design-thinking/ subdirectory structure. Updating the contributing documentation to permit subdirectory organization is a prerequisite for the migration PR. The update should document the filename uniqueness constraint alongside the subdirectory allowance.

Precedent exists for subdirectory use in other artifact types: instruction files already organize into subdirectories (bash/, csharp/, terraform/, bicep/, hve-core/) under .github/instructions/. The prompt subdirectory pattern follows this established convention.

Standards and Conformance

Current Conformance State

A conformance audit of 15 sampled design-thinking artifacts against prompt-builder authoring standards found approximately 12% overall conformance. The audit identified 8 categories of findings:

F1: Missing frontmatter. Zero of 9 sampled prompts include description frontmatter; zero include maturity. Four of 9 have no frontmatter block at all, while 5 have partial frontmatter missing required fields.
F2: Protocol non-conformant. Zero of 9 sampled prompts use the Required Steps protocol structure. Only 1 of 9 includes an activation line.
F3: Bold-titled lists appear in 100% of sampled files, violating prompt-builder guidance against the **Title** - text pattern.
F4: Command-style language. ALL CAPS directives and imperative "You must" patterns appear in multiple files.
F5: Chatmodes have no conformance standards target in their current format. After conversion to agents, the agent frontmatter schema provides the conformance baseline.
F6: Guidance documents have no artifact type classification. The 9 guidance files have no standards framework.
F7: Embedded YAML configuration blocks appear in prompts, mixing configuration with prompt instructions.
F8: The [Internal AI Context] pattern is used consistently across DT prompts but is undefined in prompt-builder standards.

Conformance matrix across sampled artifacts:

Criterion	Prompts (9)	Chatmodes (4)	Guidance (2)
`description` frontmatter	0%	25%	0%
`maturity` frontmatter	0%	0%	0%
Required Steps protocol	0%	N/A	N/A
Activation line	11%	N/A	N/A
No bold-titled lists	0%	0%	0%
Guidance-style language	22%	25%	100%
No ALL CAPS directives	100%	75%	100%
Valid mode/tools fields	56%	50%	N/A

Standards Extensions Required

Phase 1 requires two extensions to prompt-builder authoring standards:

Template-style prompt sub-type: several design-thinking prompts use fill-in-the-blank templates with [INSERT] placeholders rather than step-based protocols. Recognizing template-style as a valid prompt sub-type allows these prompts to conform without forced restructuring into a protocol format that contradicts their purpose.
[Internal AI Context] pattern: design-thinking prompts use inline annotations marked with [Internal AI Context] for AI consumption. Adding this as a recognized pattern with formatting guidelines formalizes a useful convention.

Phase 2 requires two additional extensions for planning:

Agent delegation protocol: a standardized pattern for expressing coach-to-subagent routing within agent frontmatter and instructions, including the progressive hints model and boundary enforcement behaviors.
Guidance document classification: determine whether guidance becomes its own artifact type with a dedicated schema, adapts as .instructions.md files, or remains documentation.

Four-Tier Remediation Plan

Remediation follows a specific sequencing where each tier builds on the previous:

Tier 4 (prerequisite, hve-core): Extend prompt-builder standards to recognize template-style prompts and the [Internal AI Context] pattern. This is a small-scope change to the standards file itself, approximately 1 PR against hve-core.

Tier 1 (mechanical, DT prompts): Add or complete YAML frontmatter on all 32 prompts. Every prompt receives description and maturity: preview fields at minimum. This tier is automatable through scripting and produces approximately 1 PR.

Tier 2 (moderate, DT prompts): Restructure protocol sections. Reformat approximately 20 protocol-style prompts into the Required Steps format with proper ### Step N: Summary headings and activation lines. Apply template-style guidelines from Tier 4 to approximately 12 template-style prompts. Approximately 2-3 PRs.

Tier 3 (intensive, DT prompts): Writing style corrections. Replace bold-titled lists with plain lists or headings. Soften command-style language from imperative to guidance tone. Remove ALL CAPS directives where they appear. This tier has the highest per-file effort but the boldtitle replacement is amenable to find-and-replace automation. Approximately 2-3 PRs.

Sequencing:

Tier 4 (Standards) → Tier 1 (Frontmatter) → Tier 2 (Protocol) → Tier 3 (Style)
    hve-core              DT prompts            DT prompts          DT prompts
    ~1 PR                 ~1 PR                 ~2-3 PRs            ~2-3 PRs

Tier 1 before and after example:

# Before: no frontmatter
# Scope Conversation Starter

Use this prompt to begin...

# After: frontmatter added
---
description: "Facilitates initial scope conversations for design thinking Method 01"
maturity: preview
---

# Scope Conversation Starter

Use this prompt to begin...

Tier 2 before and after example:

# Before: non-conformant protocol
**Step 1 - Identify Stakeholders**

First, review the project context...

# After: conformant protocol
## Required Steps

### Step 1: Identify stakeholders

Review the project context...

Tier 3 before and after example:

# Before: bold-titled list
* **Key Stakeholders** - The people who...
* **Decision Makers** - Those with authority to...

# After: plain list
* Key stakeholders: the people who...
* Decision makers: those with authority to...

Automation opportunities: Tier 1 frontmatter insertion is fully scriptable. Tier 3 bold-title replacement is amenable to regex-based find-and-replace. Tiers 2 and 4 require human judgment for protocol restructuring and standards authoring respectively.

Conformance Validation

Validation runs through the existing CI/CD pipeline using npm run lint:frontmatter for frontmatter validation, npm run lint:md for markdown linting, and npm run lint:all for the complete validation suite. The warnings-as-errors: true setting in the CI/CD configuration means all design-thinking prompts must pass validation before any migration PR can merge. This enforcement ensures conformance is not deferred or forgotten.

Phased Integration Roadmap

Phase 1: Prompt Integration

Workstream	Description	Dependency
Standards extension	Add template-style prompts and `[Internal AI Context]` to prompt-builder	None
Conformance remediation	Frontmatter, protocol, and writing style across 32 prompts	Standards extension
Directory setup	Create `.github/prompts/design-thinking/{methods,utilities}/`	None
File migration	Copy 32 remediated prompts from DT to hve-core	Remediation complete
Registry entries	Add 32 `simpleArtifactEntry` records with `preview` maturity	PR #439 merged
Collection manifest	Create `design-thinker.collection.json`	PR #439 merged
Documentation	Update `docs/architecture/ai-artifacts.md` with design-thinking section	File migration complete
Contributing update	Update `docs/contributing/prompts.md` to permit subdirectory organization with filename uniqueness constraint	None
Collision detection	Add build-time prompt name collision validation to `Prepare-Extension.ps1`	None
Persona addition	Add `design-thinker` to persona taxonomy	PR #439 merged

Target: the next milestone following PR #439 merge.

Phase 2: Chatmode-to-Agent Conversion

Workstream	Description	Dependency
Delegation protocol	Design coach-to-subagent routing pattern within agent instructions	None
Progressive hints design	Map 4-level progressive hints and boundary enforcement to agent instruction patterns	None
Conformance remediation	Convert 20 chatmode files to agent format with frontmatter and writing style fixes	Delegation protocol
Coach agent creation	Convert coach chatmode to primary `design-thinking.agent.md` with subagent references	Conformance
Hat subagent creation	Convert 19 hat chatmodes to specialized `.agent.md` subagents	Conformance
Registry entries	Add 20 `agentEntry` records with `preview` maturity	PR #439 merged
File migration	Place converted agents in hve-core under `.github/agents/design-thinking/`	All above
Architecture docs	Update agent hierarchy documentation to include design-thinking agents	File migration

Proposed agent directory structure:

.github/agents/
├── design-thinking/
│   ├── design-thinking.agent.md
│   └── hats/
│       ├── 00-repository-navigator.agent.md
│       ├── 00-design-thinking-learning-tutor.agent.md
│       ├── 01-scope-collaborator.agent.md
│       ├── 01-stakeholder-discovery-facilitator.agent.md
│       ├── ...
│       └── 09-scale-collaborator.agent.md
├── task-implementor.agent.md
├── task-planner.agent.md
└── ...existing hve-core agents

The coach agent and its hat subagent dependencies require a requires block in the registry to express cross-artifact dependencies:

{
    "agents": {
        "design-thinking/design-thinking": {
            "maturity": "preview",
            "personas": ["design-thinker"],
            "tags": ["coaching", "design-thinking"],
            "requires": {
                "agents": ["design-thinking/hats/00-repository-navigator", "design-thinking/hats/00-design-thinking-learning-tutor"],
                "prompts": ["design-thinking/methods/01-scope-conversation-starter"],
                "guidance": ["01-scope-conversations"]
            }
        }
    }
}

Note

Get-DiscoveredAgents in Prepare-Extension.ps1 currently uses non-recursive scanning. If hat subagents reside in .github/agents/design-thinking/hats/, the discovery function needs an update to scan recursively or the hats directory needs explicit registration. Alternatively, all agents could reside at the same level within .github/agents/design-thinking/.

Hat subagent registration presents a design decision: register each of the 19 hats as individual agentEntry records (providing granular reuse and independent maturity tracking) or register only the coach agent and bundle hats implicitly through the requires block (providing a simpler registry with fewer entries). Both approaches have merits and the community's input on this trade-off would be valuable.

Phase 3: Guidance Integration

Workstream	Description	Dependency
Classification decision	Determine if guidance is own artifact type, instructions, or docs	Phase 2 agent conversion
Schema creation	Create guidance frontmatter schema (if own type)	Classification
Discovery function	Add `Get-DiscoveredGuidance` to `Prepare-Extension.ps1` (if own type)	Classification
File migration	Copy 9 guidance docs from DT to hve-core	Schema and discovery
Registry entries	Add guidance entries (if own type)	PR #439 and schema

Milestone Targets and Dependencies

The dependency graph shows two parallel tracks that converge at the migration PR:

PR #439 merge ──→ Registry entries ──→ Collection manifest
                                   ──→ Persona addition

Tier 4 (Standards) ──→ Tier 1 (Frontmatter) ──→ Tier 2 (Protocol) ──→ Tier 3 (Style)
                                                                              │
(Both tracks converge) ──────────────────────────────────────────────────→ Migration PR
                                                                              │
                                                                        Phase 1 Complete
                                                                              │
Delegation Protocol Design ──→ Chatmode-to-Agent Conversion ──→ Phase 2 Start

Risk Analysis

Risk	Impact	Mitigation
PR #439 not merged	High	Prompt conformance remediation proceeds independently; file migration waits for merge
DT prompt drift after migration	Medium	Establish ownership model where DT team owns prompts in hve-core and submits PRs for updates
Conformance remediation changes behavior	Medium	Tier sequencing minimizes risk (frontmatter first, style last); test prompts after each tier
VS Code API unavailable for chatmodes	High	Chatmodes convert to agents, eliminating the VS Code chatmode API dependency entirely. Agent infrastructure is proven and stable.
Discovery UX overwhelm (32 new prompts)	Medium	Subdirectory structure plus persona collection provides filtering and organization
CI/CD rejects DT prompts on first PR	High	Complete all conformance tiers before submitting migration PR to avoid repeated CI failures
Prompt name collision from duplicate filenames	High	Filenames must be globally unique across all subdirectories. Add build-time collision detection to `Prepare-Extension.ps1` before the migration PR. The proposed naming scheme (numeric prefixes for methods, verb prefixes for utilities) avoids current collisions but provides no automated enforcement.
Contributing docs prohibit subdirectories	Medium	Update `docs/contributing/prompts.md` to permit subdirectory organization with the filename uniqueness constraint documented. This update should precede or accompany the migration PR.

Hard dependencies that gate progress:

PR feat(extension): implement collection-based plugin distribution system #439 merge: required for registry, collection, and persona features
Conformance Tier 4 (standards extension): prerequisite for all DT-side remediation tiers
Conformance Tiers 1-3 complete: prerequisite for the migration PR passing CI/CD validation
Delegation protocol design: prerequisite for Phase 2 chatmode-to-agent conversion

Open Questions for Discussion

1. Persona Granularity

Design-thinking prompts need persona assignment for the registry. The granularity decision affects who sees these prompts by default.

Option A: Include in hve-core-all collection, making prompts available to all users immediately upon installation
Option B: design-thinker persona only, requiring users to opt into the design-thinking collection
Option C: Both hve-core-all and design-thinker, providing broad availability with filtering capability

Broader availability increases adoption but risks overwhelming users who have no interest in design thinking. Opt-in distribution respects user attention but requires explicit action. Starting with Option B during the preview maturity phase and promoting to Option C after community validation balances these concerns.

2. Prompt Ownership Model

Once design-thinking prompts reside in hve-core, ongoing maintenance responsibility needs a clear model.

Option A: DT team submits PRs to hve-core for all changes, retaining domain expertise while hve-core team reviews for standards compliance
Option B: hve-core team adopts and maintains DT prompts, gaining full ownership but potentially losing design-thinking domain nuance
Option C: Shared ownership with a CODEOWNERS entry designating the DT team as required reviewers for the design-thinking/ subdirectory

The trade-off centers on domain expertise versus code ownership centralization. The DT team understands the methodology deeply; the hve-core team understands the build system and standards.

3. Template-Style Prompt Recognition

Design-thinking prompts include [INSERT] template-style prompts that differ from prompt-builder's step-based Required Steps protocol.

Option A: Add template-style as a formal sub-type in prompt-builder standards, allowing DT template prompts to conform without structural changes
Option B: Restructure DT templates into the standard Required Steps protocol format, maintaining standards consistency

The trade-off involves standards flexibility (recognizing that different prompt purposes benefit from different structures) versus strict consistency (every prompt follows the same protocol pattern regardless of purpose).

4. Guidance File Classification

Nine guidance files exist in the design-thinking repository but have no corresponding artifact type in hve-core.

Option A: Create a new .guidance.md artifact type with its own frontmatter schema, discovery function, and registry classification
Option B: Adapt guidance as .instructions.md files with applyTo patterns targeting design-thinking prompt files and agents
Option C: Classify guidance as documentation under docs/design-thinking/ rather than as a first-class artifact type

The trade-off balances fidelity to original purpose (runtime knowledge assets for AI consumption) against infrastructure cost (new schemas, discovery functions, and contributes keys for a new artifact type).

5. Hat Subagent Registration Granularity

The 20 chatmodes convert to 1 coach agent and 19 specialized hat subagents. Registry registration can work at different granularities.

Option A: Register each hat subagent individually as 20 separate agentEntry records, enabling independent maturity tracking, granular reuse, and flexible persona assignment
Option B: Register only the coach agent with hat subagents bundled implicitly through the requires block, providing a simpler registry with 1 entry

Individual registration enables scenarios where a hat subagent might be useful outside the coach context. Bundled registration keeps the registry focused and treats the coach + hat system as a single unit.

6. Maturity Promotion Criteria

Design-thinking prompts enter the registry with preview maturity. Criteria for promoting to stable need community alignment.

Possible approaches include usage data thresholds, community feedback periods, time-based promotion after a fixed duration, or author certification that the prompt meets quality standards. The promotion criteria should balance accessibility (not blocking useful prompts behind excessive gates) with quality assurance (not promoting prompts that produce inconsistent results).

7. Independent Extension Alternative

The landscape research recommended "Independent Extensions with Shared Standards" as the integration approach, where the design-thinking repository publishes its own VS Code extension using shared schemas and conventions.

Option A: Integrate into hve-core (the approach presented here), leveraging the shared build system, unified distribution, and single extension for users to install
Option B: DT publishes independently using shared schemas, maintaining independent release cadence and repository ownership

Centralized distribution reduces user friction (one extension covers both domains) and eliminates build system duplication. Independent publishing preserves repository autonomy and allows the DT team to release on their own schedule. What factors would change this decision for the community?

Appendices

Appendix A: Complete DT Prompt Inventory

#	Filename	Method	Category	Description
1	scope-conversation-starter	01	Method	Facilitates initial scope conversations
2	stakeholder-mapping	01	Method	Maps stakeholder relationships
3	frozen-vs-fluid-assessment	01	Method	Assesses frozen vs. fluid elements
4	research-plan-creator	02	Method	Creates design research plans
5	research-data-synthesis	02	Method	Synthesizes research data
6	(02 third prompt)	02	Method	Design research support
7	synthesis-validation	03	Method	Validates synthesis outputs
8	(03 second prompt)	03	Method	Input synthesis support
9	(03 third prompt)	03	Method	Input synthesis support
10	brainstorm-facilitator	04	Method	Facilitates brainstorming sessions
11	(04 second prompt)	04	Method	Brainstorming support
12	(04 third prompt)	04	Method	Brainstorming support
13	(05 first prompt)	05	Method	User concept development
14	(05 second prompt)	05	Method	User concept development
15	(05 third prompt)	05	Method	User concept development
16	rapid-prototyping	06	Method	Lo-fi rapid prototyping
17	(06 second prompt)	06	Method	Lo-fi prototyping support
18	(06 third prompt)	06	Method	Lo-fi prototyping support
19	lo-fi-to-hi-fi	07	Method	Transitions lo-fi to hi-fi prototypes
20	(07 second prompt)	07	Method	Hi-fi prototyping support
21	(07 third prompt)	07	Method	Hi-fi prototyping support
22	ai-persona-testing	08	Method	AI-assisted persona testing
23	(08 second prompt)	08	Method	User testing support
24	(08 third prompt)	08	Method	User testing support
25	(09 first prompt)	09	Method	Scale iteration support
26	(09 second prompt)	09	Method	Scale iteration support
27	create-hve-capability	N/A	Utility	Creates HVE capability artifacts
28	create-method-guidance	N/A	Utility	Creates method guidance documents
29	create-instruction-asset	N/A	Utility	Creates instruction assets
30	create-problem-phase-context	N/A	Utility	Creates problem phase context
31	port-to-pyramid	N/A	Utility	Ports content to HVE Pyramid format
32	(6th utility)	N/A	Utility	Utility prompt

Note

Entries with parenthetical names indicate prompts where exact filenames require verification from the design-thinking repository during implementation.

Appendix B: Conformance Audit Summary

Conformance matrix (reproduced from the Standards and Conformance section for reference):

Criterion	Prompts (9)	Chatmodes (4)	Guidance (2)
`description` frontmatter	0%	25%	0%
`maturity` frontmatter	0%	0%	0%
Required Steps protocol	0%	N/A	N/A
Activation line	11%	N/A	N/A
No bold-titled lists	0%	0%	0%
Guidance-style language	22%	25%	100%
No ALL CAPS directives	100%	75%	100%
Valid mode/tools fields	56%	50%	N/A

Remediation effort summary:

Tier	Scope	Target Files	Effort	PRs
Tier 4	Extend prompt-builder standards	1 (hve-core)	Small	~1
Tier 1	Add frontmatter	32 (DT)	Mechanical/automatable	~1
Tier 2	Protocol restructuring	32 (DT)	Moderate	~2-3
Tier 3	Writing style corrections	32 (DT)	Intensive	~2-3

Appendix C: Build System Analysis Summary

Component	Purpose	DT Prompt Impact	Changes Required
`Prepare-Extension.ps1`	Discovers artifacts	Auto-discovers via recursive scan	None
`Package-Extension.ps1`	Packages VSIX	Copies `.github/` directory	None
`prompt-frontmatter.schema.json`	Validates frontmatter	Allows `additionalProperties`	None
`schema-mapping.json`	Maps file patterns to schemas	Glob matches subdirectories	None
`Validate-MarkdownFrontmatter.ps1`	Runs validation pipeline	Classifies DT as prompts	None
Extension workflows (3)	Package and publish	Include DT prompts	None
`ai-artifacts-registry.json`	Tracks artifact metadata	Needs 32 new entries	PR #439 dependency
Collection manifests	Groups by persona	New `design-thinker` collection	PR #439 dependency

Appendix D: Related PRs and Issues

PR feat(extension): implement collection-based plugin distribution system #439: Persona-based distribution with AI Artifacts Registry. 131 files, +8054/-885 lines. Milestone v2.5.0. Part of Epic feat: Persona-Based Extension Distribution #431 (6 of 8 phases complete). Introduces registry schema, collection manifests, persona taxonomy, and maturity gating. Registry and collection steps depend on PR feat(extension): implement collection-based plugin distribution system #439 merge.
PR refactor: migrate chatmodes to agents architecture #210: Migrated chatmodes to agents, deprecated chatmode-frontmatter.schema.json. Establishes the agent infrastructure that Phase 2 builds on for chatmode-to-agent conversion.
Epic feat: Persona-Based Extension Distribution #431: AI Artifacts Registry epic. 6 of 8 phases complete. Phase 6 (tooling) not started, Phase 7 (documentation) partial. Progress on this epic directly affects the timeline for registry and collection features.

🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.

WilliamBerryiii · 2026-02-12T05:13:00Z

WilliamBerryiii
Feb 12, 2026
Maintainer Author

Tagging @mahomedalid, @leighatami, @agreaves-ms, @katriendg, @auyidi1, @bindsi, @nguyena2, @mayurpatel312, and @amcc-engineering for perspectives.

0 replies

katriendg · 2026-02-12T11:03:02Z

katriendg
Feb 12, 2026
Maintainer

Great, very extensive proposal — and great approach with phased approach, and conformance remediation plan.
A few things worth flagging that may hit barriers, which I analyzed and rephrased with some AI help:

Extension-Based Distribution: Subdirectories Work

For extension-based distribution, organizing prompts into subdirectories like .github/prompts/design-thinking/methods/ and .github/prompts/design-thinking/utilities/ is a fine approach. The build system already handles this correctly:

Get-DiscoveredPrompts in Prepare-Extension.ps1 uses -Recurse, so prompt files in any subfolder depth are discovered and registered in package.json automatically.
Get-DiscoveredInstructions also uses -Recurse, so instruction subdirectories (bash/, csharp/, terraform/, bicep/) work the same way.
Package-Extension.ps1 copies the entire .github/ tree, and the extension's contributes.chatPromptFiles explicitly registers each prompt by path.

One build system gap to address: Get-DiscoveredAgents does not use -Recurse. If Phase 2 introduces agent subdirectories (e.g., .github/agents/design-thinking/hats/), the build system needs updating to scan recursively, matching the pattern already used for prompts and instructions. This is a straightforward fix — adding -Recurse to the Get-ChildItem call and computing relative paths the same way Get-DiscoveredPrompts does. Added this

Non-Extension Methods: Explicit Path Enumeration Required

For clone-based installation methods (peer-clone, multi-root, submodule, git-ignored, mounted, codespaces) and for working directly within this repo, subdirectory-based organization creates a discovery problem. chat.promptFilesLocations does not support recursive scanning — it only resolves *.prompt.md files that a specified folder immediately contains. This was confirmed by @legomushroom in microsoft/vscode-copilot-release#6183 (closed as not planned).

I have manually tested in the current version of code-insiders, and any prompt within a subdirectory of the registered path is ignored.

Additionally, VS Code now warns that glob patterns in chat.instructionsFilesLocations are deprecated and will be removed in future versions. This means the subdirectory pattern that currently works for instructions via globs is on borrowed time. Going forward, all three location settings (chat.instructionsFilesLocations, chat.promptFilesLocations, chat.agentFilesLocations) will require explicit per-directory entries.

For future plugin-based distribution (the model supported by Copilot CLI and Claude Code), instructions are not carried as an artifact type and prompts become commands instead. Skills may absorb some of the content currently in instructions. These shifts in the artifact landscape are worth factoring into how much investment goes into subdirectory structure for non-extension methods.

Installer as the Solution for Non-Extension Setup

Given that non-extension methods need every subdirectory explicitly listed, the hve-core-installer becomes the critical piece. It would need to enumerate all persona-based subdirectories from the registry and generate the complete chat.promptFilesLocations, chat.instructionsFilesLocations, and chat.agentFilesLocations entries automatically. For example:

"chat.promptFilesLocations": {
  ".github/prompts": true,
  ".github/prompts/design-thinking/methods": true,
  ".github/prompts/design-thinking/utilities": true
}

This couples the installer to directory structure knowledge, but that coupling is manageable since the registry already tracks all artifacts and their paths. The installer should be robust enough to handle any persona collection's subfolder layout without manual maintenance.

Connection to Persona Research

Our internal persona-based distribution research (PR #439) already evaluated a directory-reorganization approach (Scenario 4 in the research) and recommended against it in favor of registry-based filtering, precisely because of the settings enumeration burden. The hybrid approach (Scenario 5) uses a centralized registry with flat directory structures, filtering via metadata rather than directory hierarchy. The design-thinking integration might benefit from the same pattern — registry tags for domain grouping rather than physical subdirectories.

Recommend Splitting This Discussion

The subdirectory organization challenge applies to all AI artifact types across all persona collections, not just design-thinking prompts. Questions like how to handle glob deprecation, whether to flatten directories, how the installer enumerates subfolders, and the Get-DiscoveredAgents recursive scanning gap are cross-cutting concerns that affect the entire project.

I suggest moving the broader "AI artifacts subfolder organization and discovery" discussion to a separate issue or thread. This design-thinking discussion can then focus on the core content work (profiles, methods, utilities, phasing) and adopt whatever subfolder strategy is decided in that parallel discussion.

Wdyt?

0 replies

mahomedalid · 2026-02-12T17:21:57Z

mahomedalid
Feb 12, 2026
Collaborator

Hi all, replicating my comments from a chat in some dark corner of Teams.

First thanks a lot for this.

I don't want to stop or slow down the migration progress, but I do have a small ick. Also, apologies if my understanding of HVE-Core is not fully up to date, I may be missing something or saying something slightly off.

HVE-Core is fantastic for generating fully fleshed, production-grade, engineering-fundamentals projects. I've seen (and feel in our projects)how impressive it is. DT4HVE, as you all know, is focused on solving the right problem in the right way, which usually means spending a large portion of the time exploring and framing the problem, and then iterating heavily during solutioning with user conversations and feedback.

One of my favorite parts of this approach is the use of high-fidelity prototypes. By definition, these should remain prototypes, not production-ready systems. Ideally not cloud-backed services, and even better if the UI visibly signals “this is a prototype, I am ugly AF” so customer conversations stay focused on the problem space rather than locking too early into a specific solution.

I can clearly see this becoming new prompts or chat modes in HVE-Core (for example, “generate a high-fidelity prototype”), and that part makes sense. I am actually excited for that. But, my question/concern is: how will users be guided toward problem exploration? What guardrails or guidance will exist for that?

(I am already having that issue in a customer project where hve-core generated a very nice prototype/project-repo, maybe too nice, and I am not sure how to go back and focus in the exploration of the right problem. )

Also regarding context and documentation: I see some overlap with prompts that generate documentation artifacts (aka the context for dt coach), how would that integrate with HVE-Core?

1 reply

mayurpatel312 Feb 12, 2026
Maintainer

These are great points and I agree with you. I feel as though we could through documentation better guide the user on what to use and when. Much of the DT chatmodes are best used for early conversations and thus by nature can be "prototypey".

Where I see a benefit is a seamless transition from quick and dirty POCs and exploration, to the RPI model as we move along in customer journeys.

mayurpatel312 · 2026-02-12T18:44:30Z

mayurpatel312
Feb 12, 2026
Maintainer

All of this makes sense to me, however I would challenge us to have Phase 2 be the intial release. It makes sense to me that we first want to move over the chatmodes and then cover to agents, however you no longer have uniformity within the released repo which could confuse users. To me it makes more sense to delay the release until Phase 2 is complete. My 2c

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Architectural Integration Proposal: Design-Thinking Artifacts into HVE Core #485

Uh oh!

{{title}}

Uh oh!

Replies: 4 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Architectural Integration Proposal: Design-Thinking Artifacts into HVE Core #485

Uh oh!

WilliamBerryiii Feb 12, 2026 Maintainer

Executive Summary

Current State

hve-core Artifact Ecosystem

design-thinking-for-hve-capabilities Artifact Ecosystem

Complementary Profiles

Artifact Selection

In Scope: 32 Design-Thinking Prompts

Deferred: Chatmode-to-Agent Conversion (Phase 2)

Deferred: Guidance Documents (Phase 3)

Out of Scope: M365 Agent

Selection Rationale

Integration Architecture

Directory Structure

Registry and Collection Design

Persona Taxonomy Extension

Build System Impact

Name Collision Constraint

Contributing Documentation Update

Standards and Conformance

Current Conformance State

Standards Extensions Required

Four-Tier Remediation Plan

Conformance Validation

Phased Integration Roadmap

Phase 1: Prompt Integration

Phase 2: Chatmode-to-Agent Conversion

Phase 3: Guidance Integration

Milestone Targets and Dependencies

Risk Analysis

Open Questions for Discussion

1. Persona Granularity

2. Prompt Ownership Model

3. Template-Style Prompt Recognition

4. Guidance File Classification

5. Hat Subagent Registration Granularity

6. Maturity Promotion Criteria

7. Independent Extension Alternative

Appendices

Appendix A: Complete DT Prompt Inventory

Appendix B: Conformance Audit Summary

Appendix C: Build System Analysis Summary

Appendix D: Related PRs and Issues

Replies: 4 comments · 1 reply

Uh oh!

WilliamBerryiii Feb 12, 2026 Maintainer Author

Uh oh!

katriendg Feb 12, 2026 Maintainer

Extension-Based Distribution: Subdirectories Work

Non-Extension Methods: Explicit Path Enumeration Required

Installer as the Solution for Non-Extension Setup

Connection to Persona Research

Recommend Splitting This Discussion

Uh oh!

Uh oh!

mahomedalid Feb 12, 2026 Collaborator

Uh oh!

mayurpatel312 Feb 12, 2026 Maintainer

Uh oh!

mayurpatel312 Feb 12, 2026 Maintainer

WilliamBerryiii
Feb 12, 2026
Maintainer

Replies: 4 comments 1 reply

WilliamBerryiii
Feb 12, 2026
Maintainer Author

katriendg
Feb 12, 2026
Maintainer

mahomedalid
Feb 12, 2026
Collaborator

mayurpatel312 Feb 12, 2026
Maintainer

mayurpatel312
Feb 12, 2026
Maintainer