diff --git a/.github/agents/design-thinking/dt-coach.agent.md b/.github/agents/design-thinking/dt-coach.agent.md index 9ac6a08f2f..e4c832dfa1 100644 --- a/.github/agents/design-thinking/dt-coach.agent.md +++ b/.github/agents/design-thinking/dt-coach.agent.md @@ -96,6 +96,7 @@ Coaching knowledge is packaged as Design Thinking skills that you load explicitl 2. Method: Load `.github/skills/design-thinking/dt-methods/SKILL.md` when focusing on a specific method, then read the reference matching the active method in coaching state. 3. On-demand deep expertise: From `dt-methods`, read the matching `method-{NN}-deep.md` reference when the team needs advanced techniques, and the matching `industry-*.md` reference when an industry context applies. 4. RPI handoff: Load `.github/skills/design-thinking/dt-rpi-integration/SKILL.md` at handoff points where coaching graduates into the RPI workflow. +5. AI Discovery Cards: Load `ai-discovery-cards` during Method 4 when a team wants AI-focused ideation. Recommend AI Discovery Cards only after the problem and stakeholder need are grounded, and direct designers and facilitators to the AI Discovery Cards Workshop Facilitation Guide for workshop details and AI capabilities. ### Foundation Skill References diff --git a/.github/agents/design-thinking/dt-learning-tutor.agent.md b/.github/agents/design-thinking/dt-learning-tutor.agent.md index 32aa8cae95..4ea485103d 100644 --- a/.github/agents/design-thinking/dt-learning-tutor.agent.md +++ b/.github/agents/design-thinking/dt-learning-tutor.agent.md @@ -76,6 +76,7 @@ Curriculum content is packaged as the `dt-curriculum` skill that you load explic * At session start, read `.github/skills/design-thinking/dt-curriculum/SKILL.md` to ground the curriculum structure and map each module to its reference file. * Before delivering a module in Phase 2, read the curriculum reference matching the active module under `.github/skills/design-thinking/dt-curriculum/references/`. * For practice exercises, read `.github/skills/design-thinking/dt-curriculum/references/curriculum-scenario-manufacturing.md` as the shared reference scenario. +* Load `ai-discovery-cards` for a recommended Module 4 ideation exercise or when a learner asks how AI capabilities can inspire ideas. Recommend AI Discovery Cards after problem framing, and direct the learner to the AI Discovery Cards Workshop Facilitation Guide for workshop details and AI capabilities. ## Required Phases diff --git a/.github/prompts/design-thinking/dt-handoff-solution-space.prompt.md b/.github/prompts/design-thinking/dt-handoff-solution-space.prompt.md index 1b8b6bebdc..32ee9f2c95 100644 --- a/.github/prompts/design-thinking/dt-handoff-solution-space.prompt.md +++ b/.github/prompts/design-thinking/dt-handoff-solution-space.prompt.md @@ -46,6 +46,10 @@ Read all Method 4-6 artifacts listed in the coaching state `artifacts` section a * Theme clusters (divergent ideas grouped by affinity). * Selected themes for concept development. * Session plan and brainstorming notes. +* AI Discovery Cards workshop notes and idea inventory, when used. +* Agentic workflow outlines, including triggers, participants, bounded AI + responsibilities, potential tools and information, human decision points, + expected outcomes, and unresolved assumptions. #### Method 5: User Concepts @@ -108,6 +112,10 @@ Include these sections: * Assumptions: each assumption with description, confidence, validation status (validated/invalidated/untested), and impact rating (high/medium/low). * Validated Patterns: user behavior patterns observed during testing with supporting evidence. * Technical Unknowns: items tagged `assumed`, `unknown`, or `conflicting` requiring further investigation. +* Agentic Workflow Context: for each advanced agentic workflow concept, summarize + its trigger, participants, bounded AI responsibilities, potential tools and + information, human decision points, expected outcome, and unresolved + assumptions. Omit this section when no agentic workflow concept advanced. Inline all content directly rather than referencing artifact paths. The document stands alone as complete context for handoff and audit trail. @@ -129,13 +137,14 @@ Include YAML frontmatter with `description` set to a summary of the handoff cont Transform DT artifacts into research-topic context using these mappings: -| DT Artifact | Research Topic Context | Notes | -|-----------------------------------|---------------------------|-------------------------------------------------| -| Validated concepts (Method 5) | Research scope definition | Concepts frame what `rpi-research` investigates | -| Constraint discoveries (Method 6) | Known constraints | Group by category, flag blockers | -| User behavior patterns (Method 6) | Observed context | Include observation evidence | -| Invalidated assumptions | Investigation priorities | Document what testing disproved | -| Technical unknowns | Primary research targets | Items marked assumed/unknown/conflicting | +| DT Artifact | Research Topic Context | Notes | +|-----------------------------------|---------------------------|----------------------------------------------------------| +| Validated concepts (Method 5) | Research scope definition | Concepts frame what `rpi-research` investigates | +| Constraint discoveries (Method 6) | Known constraints | Group by category, flag blockers | +| User behavior patterns (Method 6) | Observed context | Include observation evidence | +| Invalidated assumptions | Investigation priorities | Document what testing disproved | +| Technical unknowns | Primary research targets | Items marked assumed/unknown/conflicting | +| Agentic workflow outlines | Workflow research context | Validate orchestration, tools, oversight, and boundaries | Structure the document with these sections: @@ -143,6 +152,9 @@ Structure the document with these sections: * Known Constraints: constraints organized by category (Physical/Environmental/Workflow) with severity markers. The RPI research phase treats these as established boundaries. * Observed Context: user behavior patterns and environmental observations from prototype testing that provide context for research. * Investigation Priorities: items tagged `assumed`, `unknown`, or `conflicting` requiring investigation during `rpi-research`. Prioritize blockers and high-impact unknowns. +* Agentic Workflow Context: when applicable, describe the proposed workflow and + frame orchestration, tool access, human oversight, and responsibility boundaries + as research questions rather than implementation requirements. * DT Artifact Paths: list all `.copilot-tracking/dt/{project-slug}/` artifact paths so `rpi-research` can read original DT evidence directly. ## Optional UX Structure Route diff --git a/.github/skills/design-thinking/ai-discovery-cards/SKILL.md b/.github/skills/design-thinking/ai-discovery-cards/SKILL.md new file mode 100644 index 0000000000..3957c42923 --- /dev/null +++ b/.github/skills/design-thinking/ai-discovery-cards/SKILL.md @@ -0,0 +1,61 @@ +--- +name: ai-discovery-cards +description: AI Discovery Cards workshop guidance for Design Thinking for AI Agents ideation after problem framing. +user-invocable: false +metadata: + authors: "microsoft/hve-core" + last_updated: "2026-08-11" +--- + +# AI Discovery Cards + +## Goal + +Broaden solution exploration with AI Discovery Cards while preserving human-led +problem framing and Design Thinking method boundaries. + +## Use the catalog + +Read [card-catalog.md](references/card-catalog.md) when a team or learner needs +AI-specific prompts during brainstorming, concept development, or a related +practice exercise. Select a small, varied set of cards whose capabilities connect +to the validated problem, stakeholder needs, or How Might We question. + +For each selected card: + +1. Name its card ID, title, and category. +2. Explain the connection to the current problem evidence. +3. Turn the capability into an open ideation prompt. +4. Invite the humans involved to adapt, combine, reject, or replace it. + +## Success criteria + +* AI Discovery Cards expand the range of ideas instead of selecting a solution. +* Every capability explored traces to a validated need, constraint, or learning + goal. +* The team retains authorship and decides which directions continue. +* AI capabilities are presented as prompts, not product claims. +* Agentic ideas identify human decision points and unresolved + assumptions before technical planning. + +## Constraints + +* Use AI Discovery Cards after problem framing. Do not use them to manufacture a + need for AI. +* During divergent brainstorming, defer feasibility, desirability, viability, and + responsible AI evaluation until the applicable convergence or concept phase. +* Do not imply that AI Discovery Cards prove AI is suitable, accurate, safe, or + available. +* Do not treat a sequence of AI capabilities as proof that an autonomous or + multi-agent workflow is needed. +* Use the AI Discovery Cards Workshop Facilitation Guide as the authoritative + source for workshop details and AI capabilities. +* Do not reproduce or infer card content when the facilitation guide is unavailable. + +## Stop rules + +Do not recommend AI Discovery Cards when the problem, stakeholder, or desired +outcome is still unclear. Return to the active Design Thinking method and +strengthen that evidence first. When a proposed capability could materially affect +rights, safety, privacy, accessibility, or employment, identify the concern and +route it to appropriate human and Responsible AI review before implementation. diff --git a/README.md b/README.md index 5ec03e46a1..b6bbf49257 100644 --- a/README.md +++ b/README.md @@ -6,154 +6,63 @@ ms.date: 2026-08-13 ms.topic: overview keywords: - hypervelocity engineering - - prompt engineering - github copilot - ai workflows - - custom agents - - copilot instructions - - rpi methodology -estimated_reading_time: 3 + - prompt library +estimated_reading_time: 5 --- -## Hypervelocity Engineering (HVE) Core +HVE Core is a curated library of reusable prompts, agents, instructions, and skills that help teams build dependable, reviewable AI-assisted development workflows. - -[![CI Status](https://github.com/microsoft/hve-core/actions/workflows/release-stable.yml/badge.svg)](https://github.com/microsoft/hve-core/actions/workflows/release-stable.yml) -[![CodeQL](https://github.com/microsoft/hve-core/actions/workflows/codeql-analysis.yml/badge.svg)](https://github.com/microsoft/hve-core/actions/workflows/codeql-analysis.yml) -[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/microsoft/hve-core/badge)](https://scorecard.dev/viewer/?uri=github.com/microsoft/hve-core) -[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/11795/badge)](https://www.bestpractices.dev/projects/11795) -[![License](https://img.shields.io/github/license/microsoft/hve-core)](./LICENSE) -[![Documentation](https://img.shields.io/badge/docs-microsoft.github.io%2Fhve--core-blue)](https://microsoft.github.io/hve-core/) - - -HVE Core helps teams ship faster with GitHub Copilot by combining specialized agents, reusable prompts, coding instructions, and validated skills into one workflow system. +Use HVE Core when you want AI-assisted work to be repeatable, standards-aligned, and grounded in validated artifacts. -Use HVE Core when you want AI-assisted work to be repeatable, standards-aligned, and scalable across individuals and teams. HVE Core provides structured AI workflow building blocks: +## Why Use HVE Core -* Agents for specialized tasks such as research, planning, implementation, and review -* Prompts for repeatable workflow entry points -* Instructions that apply coding standards automatically +* Reusable prompts and agents for common engineering tasks +* Clear conventions for AI-assisted research, planning, implementation, and review * Skills that add reusable tool capabilities > [!CAUTION] -> HVE Core is a highly opinionated, rapidly evolving agentic SDLC framework. It is best treated as a source of patterns and learning rather than a stable platform, foundation, or production dependency. -> Workflows, interfaces, architecture, and recommended practices may change substantially, including in ways that are not backward compatible, as the technology landscape evolves. Evaluate all materials for your own requirements and risk tolerance. +> HVE Core is a rapidly evolving agentic SDLC framework. It is a source of patterns and learning. You would need to develop further enhancements to deploy for production. +> +> As the technology landscape evolves, workflows, interfaces, architecture, and recommended practices may change substantially, including in ways that are not backward compatible. Evaluate all materials for your own requirements and risk tolerance. +> > The HVE Builder skill (use with `/hve-builder`) and GitHub Copilot can help you adapt or copy relevant patterns into an agentic SDLC that you own and maintain independently. +> > To build an independent implementation, start with [Forking and Extending HVE Core](docs/customization/forking.md) and review the [HVE Core documentation](docs/README.md) before adopting any component. -## Where to Start +## Quick Start [![Install HVE Core](https://img.shields.io/badge/VS%20Code-Install%20HVE%20Core-007ACC?logo=visualstudiocode&logoColor=white)](https://marketplace.visualstudio.com/items?itemName=ise-hve-essentials.hve-core) - - -1. Install the [HVE Core extension](https://marketplace.visualstudio.com/items?itemName=ise-hve-essentials.hve-core) from the VS Code Marketplace. -2. Open any project and launch GitHub Copilot Chat (`Ctrl+Alt+I`). -3. Select **RPI Agent** from the agent picker or run `/rpi`, then describe the task you want to complete. + -> [!TIP] -> Using GitHub Copilot CLI? Choose a marketplace source: -> -> * Ref-less current `main`: `microsoft/hve-core` -> * Moving reviewed channels: `microsoft/hve-core#release/prerelease` and `microsoft/hve-core#release/stable` -> * Immutable exact releases: `microsoft/hve-core#prerelease-v` and `microsoft/hve-core#v` -> -> For example, register the development tip and install the HVE Core plugin: -> -> ```bash -> copilot plugin marketplace add microsoft/hve-core -> copilot plugin install hve-core@hve-core -> ``` -> -> Reviewed source moves from `main` to `release/prerelease` to `release/stable`. -> Behavior when switching or duplicating same-name marketplace registrations -> has not been observed. See [CLI Plugins](docs/getting-started/methods/cli-plugins.md) -> for details. +1. Install [Visual Studio Code](https://code.visualstudio.com/) and [GitHub Copilot](https://github.com/features/copilot). +2. Install the [HVE Core extension](https://marketplace.visualstudio.com/items?itemName=ise-hve-essentials.hve-core). +3. Open any project and launch GitHub Copilot Chat (`Ctrl+Alt+I`). +4. Select **RPI Agent** from the agent picker or run `/rpi`, then describe the task you want to complete. ## Choose Your Path * New to HVE-Core: Start with [Start Here](docs/getting-started/README.md) to complete your first workflow quickly. +* Microsoft Partner Workshop: Follow the [Getting Started with HVE Partner Workshop](docs/getting-started/README.md) for workshop-specific onboarding. * Leading a team: Use the [Team Adoption Guide](docs/customization/team-adoption.md) to roll out standards and onboarding. * Contributing to this repo: Follow the [Contributing Guide](CONTRIBUTING.md) to add or improve agents, prompts, instructions, and skills. ## Navigate This Repository -| Goal | Go here | -|------------------------------|--------------------------------------------------------------------| -| Getting Started | [docs/getting-started/README.md](docs/getting-started/README.md) | -| Understand all setup options | [docs/getting-started/install.md](docs/getting-started/install.md) | -| Learn the core methodology | [docs/rpi/README.md](docs/rpi/README.md) | -| Browse docs by topic | [docs/README.md](docs/README.md) | -| Explore agents | [.github/CUSTOM-AGENTS.md](.github/CUSTOM-AGENTS.md) | -| Explore instructions | [.github/instructions/README.md](.github/instructions/README.md) | -| Explore prompts | [.github/prompts/README.md](.github/prompts/README.md) | -| Explore skills | [.github/skills/](.github/skills/) | - -## Documentation - -Full documentation is available at ****. - -| Guide | Description | -|------------------------------------------------------------------|--------------------------------------------------| -| [Getting Started](docs/getting-started/README.md) | Setup and first workflow tutorial | -| [HVE Core Identity](docs/getting-started/packages.md) | Distribution channels and lifecycle disclosure | -| [Plugin Inventory](docs/plugins/hve-core.md) | One-plugin identity and included capabilities | -| [Package Migration](docs/getting-started/package-migration.md) | Move from retired distribution identities | -| [RPI Workflow](docs/rpi/README.md) | Deep dive into Research, Plan, Implement, Review | -| [Contributing](docs/contributing/README.md) | Create custom agents, instructions, and prompts | -| [Agents Reference](.github/CUSTOM-AGENTS.md) | All available agents | -| [Instructions Reference](.github/instructions/README.md) | All coding instructions | -| [AI Artifacts Architecture](docs/architecture/ai-artifacts.md) | Prompt engineering framework and artifact types | -| [Validation Standards](docs/contributing/ai-artifacts-common.md) | CI/CD validation pipeline and quality gates | - -## Label Management - -Repository labels are declared in [`.github/labels.yml`](.github/labels.yml) and synced automatically by the [Label Sync](.github/workflows/label-sync.yml) workflow on push to `main` or via manual `workflow_dispatch`. - -| Task | How | -|--------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **Add a label** | Add an entry with `name`, `color` (bare hex, no `#`), and `description` to `.github/labels.yml`, then push to `main` | -| **Update a label** | Edit the existing entry's `color` or `description` | -| **Rename a label** | Add an `aliases` array under the new canonical name listing the old name; the sync migrates existing assignments automatically | -| **Delete a label** | Remove it manually in the [GitHub Labels UI](https://github.com/microsoft/hve-core/labels). Deleting an entry from the file does **not** delete it from GitHub (the workflow runs in additive mode) | - -## Contributing - -We appreciate contributions! Whether you're fixing typos or adding new components: - -1. Read our [Contributing Guide](CONTRIBUTING.md). -2. Check out [open issues](https://github.com/microsoft/hve-core/issues). -3. Join the [discussion](https://github.com/microsoft/hve-core/discussions). +| Goal | Go here | +|---------------------------------|------------------------------------------------------------------| +| Start with the partner workshop | [docs/getting-started/README.md](docs/getting-started/README.md) | +| Learn the core workflow | [docs/rpi/README.md](docs/rpi/) | +| Find reusable assets | [docs/reference/README.md](docs/reference/README.md) | +| Customize HVE Core | [docs/customization/README.md](docs/customization/README.md) | +| Contribute changes | [CONTRIBUTING.md](CONTRIBUTING.md) | ## Responsible AI Microsoft encourages customers to review its Responsible AI Standard when developing AI-enabled systems to ensure ethical, safe, and inclusive AI practices. Learn more at [Microsoft's Responsible AI](https://www.microsoft.com/ai/responsible-ai). -## Legal - -This project is licensed under the [MIT License](./LICENSE). - -### Licensing - -Most content in this repository is covered by the MIT License. Certain skill content -derived from OWASP Foundation publications is licensed under -[CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). Each affected -skill identifies its license in frontmatter and includes a Third-Party Attribution -section. See [THIRD-PARTY-NOTICES](./THIRD-PARTY-NOTICES) for full details. - -See [SECURITY.md](./SECURITY.md) for the security policy and vulnerability reporting. - -See [GOVERNANCE.md](./GOVERNANCE.md) for the project governance model. - -See [TRANSPARENCY-NOTE.md](./TRANSPARENCY-NOTE.md) for the Responsible AI Transparency Note covering intended uses, limitations, and the responsibility boundary between HVE Core and the host platform. - -## Trademark Notice - -> This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft -> trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in -> modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or -> logos are subject to those third-party's policies. - --- diff --git a/docs/design-thinking/dt-coach.md b/docs/design-thinking/dt-coach.md index 330ccf3e18..c5a6929c55 100644 --- a/docs/design-thinking/dt-coach.md +++ b/docs/design-thinking/dt-coach.md @@ -3,7 +3,7 @@ title: Using the DT Coach description: Guide to using the dt-coach agent for AI-assisted Design Thinking sessions sidebar_position: 3 author: Microsoft -ms.date: 2026-08-06 +ms.date: 2026-08-11 ms.topic: tutorial keywords: - dt-coach @@ -125,6 +125,7 @@ Session state persists in `.copilot-tracking/dt/{project-slug}/coaching-state.md * Start broad, narrow later. Resist the urge to jump to solutions in early methods. The Problem Space exists to ensure you solve the right problem. * Trust the exit signals. Each method has specific criteria that indicate when you have enough evidence to advance. The coach tracks these for you. * Keep artifacts rough. In the Problem and Solution spaces, polished output actually hurts. Scrappy artifacts invite honest feedback from stakeholders. +* Use AI Discovery Cards for AI-focused ideation during Method 4 after the problem and stakeholder needs are validated. Refer to the AI Discovery Cards Workshop Facilitation Guide for workshop details and AI capabilities. * Use industry context. If your domain is manufacturing, healthcare, or energy, mention it early. The coach adjusts vocabulary and stakeholder archetypes accordingly. ## Common Pitfalls diff --git a/docs/design-thinking/dt-learning-tutor.md b/docs/design-thinking/dt-learning-tutor.md index 66592e6f25..29558f26a5 100644 --- a/docs/design-thinking/dt-learning-tutor.md +++ b/docs/design-thinking/dt-learning-tutor.md @@ -3,7 +3,7 @@ title: Using the DT Learning Tutor description: Guide to using the dt-learning-tutor agent for self-paced Design Thinking education sidebar_position: 4 author: Microsoft -ms.date: 2026-08-06 +ms.date: 2026-08-11 ms.topic: tutorial keywords: - dt-learning-tutor @@ -92,17 +92,17 @@ The tutor responds by classifying you as beginner-to-intermediate, then launches ## Curriculum Overview -| Module | Method | Space | Topics | -|--------|--------------------------|----------------|--------------------------------------------------------------------------| -| 1 | Scope Conversations | Problem | Frozen vs fluid requests, stakeholder mapping, constraint discovery | -| 2 | Design Research | Problem | Contextual inquiry, environmental observation, discovery questions | -| 3 | Input Synthesis | Problem | Affinity clustering, theme development, HMW questions | -| 4 | Brainstorming | Solution | Divergent ideation, convergent clustering, constraint-bounded creativity | -| 5 | User Concepts | Solution | Concept articulation, D/F/V analysis, stakeholder alignment | -| 6 | Low-Fidelity Prototypes | Solution | Paper prototyping, scrappy enforcement, feedback planning | -| 7 | High-Fidelity Prototypes | Implementation | Technical translation, functional prototypes, specifications | -| 8 | User Testing | Implementation | Test protocols, evidence-based evaluation, severity classification | -| 9 | Iteration at Scale | Implementation | Change management, scaling patterns, telemetry-driven optimization | +| Module | Method | Space | Topics | +|--------|--------------------------|----------------|---------------------------------------------------------------------| +| 1 | Scope Conversations | Problem | Frozen vs fluid requests, stakeholder mapping, constraint discovery | +| 2 | Design Research | Problem | Contextual inquiry, environmental observation, discovery questions | +| 3 | Input Synthesis | Problem | Affinity clustering, theme development, HMW questions | +| 4 | Brainstorming | Solution | Divergent ideation, convergent clustering, AI Discovery Cards | +| 5 | User Concepts | Solution | Concept articulation, D/F/V analysis, stakeholder alignment | +| 6 | Low-Fidelity Prototypes | Solution | Paper prototyping, scrappy enforcement, feedback planning | +| 7 | High-Fidelity Prototypes | Implementation | Technical translation, functional prototypes, specifications | +| 8 | User Testing | Implementation | Test protocols, evidence-based evaluation, severity classification | +| 9 | Iteration at Scale | Implementation | Change management, scaling patterns, telemetry-driven optimization | The three spaces represent the natural progression of Design Thinking: diff --git a/docs/design-thinking/dt-rpi-integration.md b/docs/design-thinking/dt-rpi-integration.md index 0fbc451797..cd2cff2e16 100644 --- a/docs/design-thinking/dt-rpi-integration.md +++ b/docs/design-thinking/dt-rpi-integration.md @@ -3,7 +3,7 @@ title: DT to RPI Integration description: How Design Thinking outputs feed into the RPI workflow sidebar_position: 14 author: Microsoft -ms.date: 2026-08-06 +ms.date: 2026-08-11 ms.topic: how-to keywords: - design thinking @@ -92,6 +92,33 @@ After Brainstorming, User Concepts, and Low-Fidelity Prototypes, the team has a * Assess feasibility of tested concepts across stakeholder perspectives * Investigate integration and scaling concerns before planning begins +#### Integrate AI Discovery Cards workshop results + +AI Discovery Cards workshop results enter HVE as Design Thinking evidence, not as +implementation requirements. Add promising workshop ideas to the Method 4 idea +inventory and trace each one to a validated need, stakeholder, outcome, and +constraint. For agentic workflow ideas, capture the trigger, participants, bounded +AI responsibilities, potential tools and information, human decision points, +expected outcome, and unresolved assumptions. + +Carry selected themes through the remaining Solution Space methods: + +1. Use Method 5 to turn a selected theme into a User Concept and evaluate its + desirability, feasibility, and viability. +2. Use Method 6 to prototype the workflow, including handoffs, exception paths, + and human oversight points. +3. Mark claims as `validated`, `assumed`, `unknown`, or `conflicting` based on the + resulting evidence. +4. At the Solution Space exit, include the Method 4 workshop notes and idea + inventory, Method 5 concepts, Method 6 prototype findings, constraints, and + technical unknowns in the handoff artifact. +5. Route the handoff to `rpi-research`. Research determines whether the proposed + capabilities and agentic workflow are technically appropriate before + `rpi-plan` defines implementation work. + +This sequence keeps workshop inspiration connected to HVE while preventing an AI +capability prompt from becoming an untested architecture decision. + ### Implementation Spec Ready (Methods 7-9 to rpi-research) After High-Fidelity Prototypes and User Testing, the team has functionally validated specifications. `rpi-research` receives the richest artifact set to: diff --git a/docs/design-thinking/method-04-brainstorming.md b/docs/design-thinking/method-04-brainstorming.md index 579b494975..d237c1348b 100644 --- a/docs/design-thinking/method-04-brainstorming.md +++ b/docs/design-thinking/method-04-brainstorming.md @@ -3,9 +3,9 @@ title: "Method 4: Brainstorming" description: "Generate diverse solution ideas through structured divergent thinking and converge on promising directions through evidence-informed clustering." sidebar_position: 8 author: Microsoft -ms.date: 2026-06-28 +ms.date: 2026-08-11 ms.topic: tutorial -keywords: [design thinking, method-04, brainstorming] +keywords: [design thinking, method-04, brainstorming, AI Discovery Cards, Agentic workflows] estimated_reading_time: 5 --- @@ -34,6 +34,7 @@ Method 4 is the **entry point to the Solution Space**. The Solution Space spans * Divergent ideation: Generate a high volume of ideas without evaluation. Target 15 or more ideas across 4 to 6 categories. Quantity and variety matter more than polish at this stage. * Constraint-informed generation: Use frozen constraints from Method 1 as creative boundaries that shape ideas rather than block them. Fluid constraints can be challenged or redesigned as part of the solution. * AI collaboration: Use AI as a brainstorming partner through three patterns: Prep and Synthesis (AI prepares stimulus material and organizes outputs), Backup Generator (AI generates additional ideas when team momentum stalls), and Silent Observer (AI captures and categorizes ideas during team sessions). +* AI Discovery Cards: For AI-focused ideation, including ideas for Agentic workflows, use AI Discovery Cards after validating the problem and stakeholder needs. Designers and facilitators should use the AI Discovery Cards Workshop Facilitation Guide for workshop details and AI capabilities. * Philosophy-based clustering: Group ideas not by surface similarity but by their underlying approach or philosophy. Ideas that look different but share the same theory of change belong together. * Convergent evaluation: Assess clusters against the problem statement, validated constraints, and stakeholder needs. Identify 3 to 5 themes that represent distinct solution directions worth developing further. @@ -56,6 +57,28 @@ During brainstorming: * Use constraints as creative prompts, not filters * Document every idea, even ones that seem impractical +### Capture AI Discovery Cards results + +Record workshop results in the Method 4 idea inventory. For every promising idea, +capture the validated user need, affected stakeholders, desired outcome, +constraints, and the AI capabilities that inspired the idea. Record the source as +the AI Discovery Cards workshop without reproducing workshop materials. + +For an agentic workflow idea, also capture: + +* The event or user action that starts the workflow +* The people, systems, and agents that participate +* The bounded responsibilities proposed for AI +* The tools and information the workflow may require +* The decisions or exceptions that require human involvement +* The expected outcome and evidence that would show it helps users +* Assumptions, risks, and technical questions that remain unresolved + +Cluster these ideas with the rest of the Method 4 inventory. Advance selected +themes to Method 5 as User Concepts, then test the workflow and human oversight +points with Method 6 Low-Fidelity Prototypes. Do not treat the workshop output as +a validated workflow or technical architecture. + ## Expected Outputs * Idea inventory with 15 or more ideas across 4 to 6 categories @@ -63,6 +86,8 @@ During brainstorming: * 3 to 5 converged themes representing distinct solution directions * Constraint analysis showing which ideas work within frozen constraints and which challenge fluid constraints * Evaluation notes connecting promising clusters to validated user needs from Method 3 +* For agentic workflow themes, a workflow outline covering triggers, + participants, AI responsibilities, tools, human decision points, and unknowns ## Quality Checks diff --git a/docs/getting-started/README.md b/docs/getting-started/README.md index 8b194091c2..ad9e4c3688 100644 --- a/docs/getting-started/README.md +++ b/docs/getting-started/README.md @@ -1,9 +1,9 @@ --- -title: Getting Started with HVE Core -description: Quick setup guide for using HVE Core Copilot customizations in your projects +title: Get Started with the HVE Partner Workshop +description: Start with the HVE partner workshop, then use the supporting setup, workflow, and role references sidebar_position: 1 author: Microsoft -ms.date: 2026-08-13 +ms.date: 2026-08-19 ms.topic: tutorial keywords: - github copilot @@ -13,64 +13,80 @@ keywords: estimated_reading_time: 5 --- -You've installed HVE Core. What now? - -The honest answer: you can start using agents immediately, and some of them -will produce good results right away. But the real power of HVE Core is a -methodology called RPI (Research, Plan, Implement, Review) that changes how you -collaborate with AI. Instead of asking AI to "write the code," you ask it to -research first, plan second, implement third, and review last. The constraint -changes everything. - -This guide walks you through four steps, each building on the last: - -| Step | What You Do | Time | -|-----------------------------------------------------------|---------------------------------------------------------|---------| -| [First Interaction](first-interaction.md) | Talk to an agent, see it respond | 1 min | -| [First Research](first-research.md) | Use /rpi-research on your own codebase | 5 min | -| [First Full Workflow](first-workflow.md) | Run a complete Research, Plan, Implement cycle | 15 min | -| [Growing with HVE](../hve-guide/roles/new-contributor.md) | Progress through four milestones toward independent use | Ongoing | - -> [!TIP] -> Already comfortable with AI-assisted development? Skip to -> [First Full Workflow](first-workflow.md) or select -> [RPI Agent](https://github.com/microsoft/hve-core/blob/main/.github/CUSTOM-AGENTS.md#rpi-agent) -> for a coordinated lifecycle. Use `/rpi` for the same full lifecycle from a -> prompt, or `/rpi-research`, `/rpi-plan`, `/rpi-implement`, and `/rpi-review` -> for direct phase work. - -Need installation help? See the [Installation Guide](install.md) for all -methods, or install the -[VS Code extension](https://marketplace.visualstudio.com/items?itemName=ise-hve-essentials.hve-core) -for the quickest path. - -Review [HVE Core Identity and Channels](packages.md) to choose a source channel or selective clone adoption. +Start with the [HVE partner workshop](partner-workshop.md). It gives partners new to HVE a shared setup path, role-based exercises, an integrated solution, and publication follow-up. + +## Workshop Goals +During the workshop, project and product managers, subject matter experts, designers, and technical participants work from one scenario to produce: + +* Grounded business, user, domain, design, and technical context +* User and solution requirements with testable acceptance criteria +* Prioritized GitHub backlog draft +* Reviewed Azure architecture diagram +* Follow-up plans for an Azure Managed Application offer and Microsoft 365 Copilot Agent Store publication + +## Workshop Prerequisites + +Before joining the workshop, each participant should have the following: + +* Mandatory: Product managers should pick a real customer scenario and log the customer opportunity in Partner Center, including the Partner Center referral ID for tracking and follow-up +* Product managers should bring a complete Marketplace Lean Canvas worksheet for the scenario they are shaping +* Product managers should have access to Microsoft Partner Center publisher settings or the appropriate publisher account needed for commercial publishing and validation +* Optional: Designers should have completed the AI Discovery Cards workshop with end users and be ready to share the prioritized use case with proposed Agentic AI capabilities +* Basic understanding that customer, production, or confidential data should not be entered into prompts or files during the workshop +* Laptop or desktop computer with a stable internet connection +* GitHub account that can access the workshop repository and has GitHub Copilot access enabled +* GitHub Copilot and GitHub Copilot Chat available in the environment, with the organization permitting the feature for users +* Access to Visual Studio Code, or the ability to use GitHub Codespaces in the browser +* Git installed locally if using a local VS Code setup +* Permission to install or use the Visual Studio Code extension for HVE Core All, or a facilitator-provided Codespace setup +* Shared GitHub repo and workspace folder such as `workshop-output` for the reviewed deliverables from each role track +* Technical participants should have a working understanding of Frontier Transformation, Microsoft IQ, Azure Databases, Fabric, Security, and GitHub Copilot +* Optional: Azure access or architecture context if the team plans to validate architecture decisions or deployment details during the later stages + +## Workshop Agenda + +| Step | Activity | Time | +|------|--------------------------------------------------------------------------------------------------|--------| +| 1 | [Workshop Overview](partner-workshop.md) | 30 min | +| 2 | [Set up Codespaces or local VS Code](partner-workshop-setup.md) | 30 min | +| 3 | [Plan, Envision, Experience, Architecture Design, Backlog](partner-workshop-role-tracks.md) | 90 min | +| 4 | [Validation & Solutioning](partner-workshop-solution.md) | 30 min | +| 5 | [Microsoft Marketplace and Copilot Agent Store readiness](partner-workshop-publishing.md) | 60 min | +| 6 | [Handoff to Implementation & Commercialization](partner-workshop-implementation.md) | 30 min | + +> [!NOTE] +> The workshop creates reviewed drafts and publication plans. Azure deployment, +> certification, tenant approval, and production implementation and publication continue after +> the session. + +## Not sure which bundle of agents you need? + +Visual Studio Marketplace packages are curated bundles of HVE capabilities that you can install into Copilot or VS Code so you get the right set of agents, prompts, instructions, and skills for your workflow. Browse the available [Visual Studio Marketplace Packages](packages.md) to compare curated HVE capabilities. + +## Supporting References + +Use the remaining Getting Started material as reference after the workshop. + +| Reference | Use It To | +|-----------------------------------------------------------|-------------------------------------------------------| +| [Installation Guide](install.md) | Compare installation methods and resolve setup issues | +| [VS Marketplace Packages](packages.md) | Choose a focused collection or HVE Core All | +| [First Interaction](first-interaction.md) | Practice a one-minute agent interaction | +| [First Research](first-research.md) | Learn the research phase on an existing codebase | +| [First Full Workflow](first-workflow.md) | Run Research, Plan, Implement, and Review | +| [Growing with HVE](../hve-guide/roles/new-contributor.md) | Progress toward independent HVE use | +| [Role Guides](../hve-guide/roles/) | Continue with role-specific workflows | +| [RPI Workflow](../rpi/) | Understand HVE's core delivery methodology | ## Troubleshooting -### Installation Issues - -#### Agent not available - -* Ensure GitHub Copilot extension is installed and active -* Reload VS Code window: `Ctrl+Shift+P` → "Developer: Reload Window" -* Check that hve-core is accessible (cloned or configured correctly) - -#### Copilot not discovering customizations - -* For Multi-Root: Ensure you opened the `.code-workspace` file, not just the folder -* Verify `chat.agentFilesLocations` points to the correct path -* Check the window title shows the workspace name - -#### Git or clone errors - * Verify Git is installed: run `git --version` in terminal * Check network connectivity to github.com * See the [installation guide](install.md) for method-specific troubleshooting ## Optional Scripts -HVE Core includes utility scripts you may want to copy into your project: +Copy the scripts you need to your project's `scripts/` directory and adjust paths, variables, or commands to fit your environment. | Script | Purpose | |----------------------------------------------------|----------------------------------------------------| @@ -80,25 +96,18 @@ HVE Core includes utility scripts you may want to copy into your project: Copy the scripts you need to your project's `scripts/` directory and adjust paths as needed. -## Next Steps - -* Start the journey: [Your First Interaction](first-interaction.md) -* Learn the [RPI Workflow](../rpi/) for complex tasks -* Browse [available agents](https://github.com/microsoft/hve-core/blob/main/.github/CUSTOM-AGENTS.md) for the full catalog - -## Design Thinking Path +## Design Thinking and Discovery For projects requiring user-centered requirements discovery before implementation: -* [Design Thinking Guide](../design-thinking/README.md): Start here for DT overview -* [Using the DT Coach](../design-thinking/dt-coach.md): Learn to use the dt-coach agent +* [Design Thinking Guide](../design-thinking/): Start with the DT overview +* [Using the DT Coach](../design-thinking/dt-coach.md): Learn to use the DT Coach agent * [DT to RPI Integration](../design-thinking/dt-rpi-integration.md): Transition from DT to implementation ## See Also -* [Installation Guide](install.md) - Full decision matrix for all installation methods -* [MCP Configuration](mcp-configuration.md) - Configure Model Context Protocol servers -* [Role Guides](../hve-guide/roles/) - Find your role-specific guide +* [Available agents](https://github.com/microsoft/hve-core/blob/main/.github/CUSTOM-AGENTS.md) +* [MCP Configuration](mcp-configuration.md) --- diff --git a/docs/getting-started/partner-workshop-implementation.md b/docs/getting-started/partner-workshop-implementation.md new file mode 100644 index 0000000000..90215edb2f --- /dev/null +++ b/docs/getting-started/partner-workshop-implementation.md @@ -0,0 +1,440 @@ +--- +title: Start implementing from workshop outputs +description: Turn workshop research, decisions, and backlog outputs into engineering execution using RPI agents +author: Microsoft +ms.date: 2026-08-18 +ms.topic: tutorial +keywords: + - workshop + - implementation + - rpi workflow + - research plan implement review + - new project + - existing project +estimated_reading_time: 6 +sidebar_position: 5 +--- + +# Workshop Agenda + +| Step | Activity | Time | +|------|--------------------------------------------------------------------------------------------------|--------| +| 1 | [Workshop Overview](partner-workshop.md) | 30 min | +| 2 | [Set up Codespaces or local VS Code](partner-workshop-setup.md) | 30 min | +| 3 | [Plan, Envision, Experience, Architecture Design, Backlog](partner-workshop-role-tracks.md) | 90 min | +| 4 | [Validation & Solutioning](partner-workshop-solution.md) | 30 min | +| 5 | [Microsoft Marketplace and Copilot Agent Store readiness](partner-workshop-publishing.md) | 60 min | +| 6 | [**Handoff to Implementation & Commercialization**](partner-workshop-implementation.md) | 30 min | + +With your workshop outputs, the next step is to move those outputs into implementation with the RPI workflow so engineering work stays evidence-based, traceable, and reviewable. + +Use this guide when the workshop has produced product goals, architecture direction, risks, backlog items, decisions, or design artifacts. The goal is to convert workshop output into a concrete engineering slice that can be implemented and validated without losing the original intent. + +## The execution pattern + +A workshop is usually the source of context, not the actual implementation boundary. The implementation loop should start by translating the workshop outputs into a clear engineering task, then use the RPI lifecycle to execute that task with verification. + +The practical sequence is: + +1. Confirm the workshop outputs and identify the actual engineering scope. +2. Treat the workshop as evidence, not as a substitute for current code or environment investigation. +3. Use `/rpi-research` only for demonstrated gaps. +4. Use `/rpi-plan` to convert the workshop outputs into a milestone-level implementation plan. +5. Use `/rpi-implement` to execute the approved work. +6. Use `/rpi-review` to validate the final result and route any follow-up work. + +> [!TIP] +> If you want one entry point instead of direct phase prompts, start with `/rpi` or `RPI Agent`. If you want a smaller, more focused action, use a direct phase command like `/rpi-plan`. + +## What part of the HVE repo to import + +In addition to the workshop materials, bring over the minimum HVE adoption package that helps engineers actually execute the work in the target repository. + +### Full HVE adoption package paths + +When the team is carrying the HVE setup into a new repo, the full repo-level adoption package lives under the `.github` folder and includes these paths: + +* `.github/copilot-instructions.md` +* `.github/CUSTOM-AGENTS.md` +* `.github/plugin.json` +* `.github/labels.yml` +* `.github/PULL_REQUEST_TEMPLATE.md` +* `.github/actions/` +* `.github/agents/` +* `.github/config/` +* `.github/hooks/` +* `.github/instructions/` +* `.github/ISSUE_TEMPLATE/` +* `.github/plugin/` +* `.github/policies/` +* `.github/prompts/` +* `.github/skills/` +* `.github/workflows/` + +For the minimum viable adoption set, prioritize the workflow, agent, instruction, prompt, skill, and hook configuration under `.github/agents`, `.github/instructions`, `.github/prompts`, `.github/skills`, `.github/hooks`, and `.github/workflows`. + +## Scenario 1: New project + +Use this path when the team is creating a project from scratch based on workshop results or an early solution concept. + +For a brand-new repo, the workshop is not the codebase yet. It is the source of truth for the product outcome, constraints, architecture direction, and first milestone. The engineering team’s job is to turn that workshop package into a working repo and then apply RPI so the implementation remains evidence-based from day one. + +### Step-by-step + +1. Create the project foundation + * Initialize the repo and establish the basic folder structure. + * Decide the application type, language, runtime, and CI workflow early. + * Set up the minimum developer workflow: repo, branch policy, build tool, test runner, and environment configuration. + * Keep this light at first; do not invent a large architecture before you know the first milestone. + +2. Copy the workshop package into the repo + * Store the workshop summary in a durable project artifact such as a design or requirements folder. + * Capture the agreed goals, non-goals, constraints, key decisions, dependencies, and acceptance criteria. + * Include any architecture diagrams, sketches, backlog items, and design references that explain the intended outcome. + * Keep the workshop evidence in a clearly named document so future engineers can find it without rereading the full deck. + +3. Add the HVE adoption package if the team is using this workflow in the repo + * Bring over the minimal HVE setup used to run the RPI lifecycle in the project, especially the agent, prompt, and instruction configuration under `.github`. + * Add the guidance needed for engineers to use `/rpi-research`, `/rpi-plan`, `/rpi-implement`, and `/rpi-review` consistently. + * Include the onboarding docs that explain how the workflow works for the team. + +4. Define the first milestone in plain language + * Make the first milestone small enough to finish and review quickly. + * Choose a slice such as a baseline app skeleton, service bootstrap, core workflow, API shell, or first user journey. + * Write the milestone outcome as: “When this milestone is complete, we can demonstrate X and validate Y.” + * Explicitly list what is out of scope for this first delivery. + +5. Run `/rpi-research` before implementation starts + * Use the workshop summary and repo setup as input. + * Ask the agent to identify the technical gaps, architectural choices, dependency risks, and validation paths. + * Check whether the workshop assumptions are still valid for the chosen stack and repo structure. + * Example: + +```text +/rpi-research I am starting a new project from workshop outputs. Please review the workshop goals, constraints, architecture direction, and the current repo setup, then identify the technical gaps, dependency risks, and key implementation decisions before I start coding. +``` + + * This phase is for evidence gathering. It should answer: what do we know, what is still uncertain, and what technical choices need validation? + +6. Run `/rpi-plan` for the greenfield repo + * Convert the workshop brief into a milestone-based implementation plan. + * Include phases such as repo setup, infrastructure or runtime bootstrapping, the first feature slice, validation, and review. + * Name the likely files, services, modules, and dependencies involved. + * Add expected validation steps, testing gates, and deployment or run checks. + * Example: + +```text +/rpi-plan Create an implementation plan for the first milestone of this new project using the workshop outputs and the repo setup. Keep the scope narrow, define clear phases, list the likely components and dependencies, and include validation steps and a review gate. +``` + +7. Start implementation with `/rpi-implement` + * Execute the approved milestone in small increments. + * Build the project skeleton, configuration, and first user-visible or service-visible behavior before expanding to broader functionality. + * Keep implementation tied to the workshop decisions. + * If a new decision is required, capture it and return to planning before broadening scope. + * Example: + +```text +/rpi-implement Execute the approved first milestone from the plan. Scaffold the repo, set up the required runtime and configuration, deliver the first functional slice, and validate the minimum working behavior. +``` + +8. Validate and review with `/rpi-review` + * Compare the implementation to the workshop intent and the plan. + * Check whether the first milestone satisfies the acceptance criteria and whether any risk remains open. + * Capture leftover work, deferred features, or follow-up decisions. + * Example: + +```text +/rpi-review Review the milestone implementation against the workshop requirements, the approved plan, and the repo setup. Identify any gaps, risks, or remaining follow-up work before the milestone is considered complete. +``` + +9. Prepare the next milestone based on the same evidence pack + * Use the first milestone as a foundation, not a final state. + * Keep the workshop summary and the repo artifacts together so the next team members can understand why the project was built this way. + * Each iteration should have a clear objective, acceptance criteria, and review evidence. + +### Prompt flow for a new project + +```text +/rpi-research I am starting a new project from workshop outputs. Review the workshop goals, constraints, architecture direction, and repo setup, then identify missing technical evidence, dependency risks, and implementation decisions before coding. + +/rpi-plan Create an implementation plan for the first milestone of this new project using the workshop results and the repo setup. Keep the scope narrow and define validation criteria. + +/rpi-implement Execute the approved plan for the first milestone, scaffold the repo, and deliver the minimum working slice with validation evidence. + +/rpi-review Review the implementation against the original workshop intent and the milestone criteria. Identify any remaining gaps or follow-up work. +``` + +### Checklist for new projects + +Before starting implementation, confirm the following: + +* The workshop outputs are captured in a durable project artifact +* The first milestone is identified and truly small enough to finish +* The repo structure and technology baseline are in place +* The HVE workflow setup is available in the repo if the team is using it +* Technical assumptions have been checked with `/rpi-research` +* The plan includes validation and a review gate + +### Common mistakes for new projects + +* Starting to code before capturing the workshop decisions in the repo +* Building the full roadmap instead of the first milestone +* Ignoring research gaps because the team is excited to start coding +* Skipping review because the project is “new” and feels early-stage +* Treating workshop output as final architecture without verifying repo decisions + +## Scenario 2: Existing project + +Use this path when the team is integrating workshop recommendations into an already running codebase, product, or service. + +This is the most common scenario for engineering teams. In a live repo, the workshop outputs are not the code itself; they are the decision context that helps you choose the correct implementation path. Your job is to copy the useful workshop content into the repo workflow and then let the project’s existing code and architecture drive the implementation. + +### Step-by-step + +1. Open the current repository and confirm the target scope + * Open the repo root in VS Code. + * Confirm the exact feature, service, or workflow the workshop is targeting. + * Make sure everyone agrees on what is in scope and what is not. + * If the workshop covered multiple themes, pick the first engineering milestone instead of trying to implement everything at once. + +2. Decide what to copy from the workshop + * Copy the parts that are still useful to engineering, not the entire meeting transcript. + * Keep the items that answer: what are we trying to build, what are the constraints, what are the risks, and what counts as success? + * Treat the workshop as contextual evidence, not as an instruction to rewrite the repo. + +3. What to copy over from a workshop into an existing repo + * Business outcome or user problem + * Goals and non-goals + * Key product or technical requirements + * Architecture decisions and design direction + * Dependencies and external systems + * Security, privacy, or compliance requirements + * Risks, assumptions, and unresolved questions + * Acceptance criteria and definition of done + * Backlog items or work items that are already agreed + * Screens, flows, diagrams, or reference artifacts that explain the desired behavior + +4. Create a small implementation brief before calling the agents + * Write a single paragraph describing the target outcome. + * Mention the repo path or service name you are changing. + * List the top constraints and the key acceptance criteria. + * State the first milestone clearly. + +5. Run `/rpi-research` in the existing repo + * Use the feature or service name and include the copied workshop summary. + * Ask the agent to compare the workshop direction to the actual repo structure and current implementation patterns. + * Example: + +```text +/rpi-research I am working in this existing repository. The workshop outputs say the goal is to add X, with constraints Y and Z. Please compare these workshop outputs to the current codebase, identify the relevant files and services, and tell me what implementation gaps or risks exist before coding begins. +``` + + * What to expect: the agent reviews the repo, identifies current patterns, checks existing architecture, and points out missing evidence or risky assumptions. + * This stage is not implementation. It is evidence gathering so the plan is based on reality. + +6. Run `/rpi-plan` using the repo and workshop evidence + * Ask for a milestone plan tied to the actual codebase. + * Tell the agent which service, folder, or feature is in scope. + * Ask it to reference the repo files it found in the research step. + * Example: + +```text +/rpi-plan Using the workshop outputs and the current repository evidence, create an implementation plan for the first milestone of this change. Keep the scope narrow, name the likely files and services involved, call out dependencies, and include validation steps that match this repo's existing patterns. +``` + + * The plan should define: + * objective + * in-scope work + * out-of-scope work + * affected files or services + * dependencies + * validation approach + * review gate + +7. Run `/rpi-implement` only after the plan is acceptable + * Use the approved plan and the exact scope from the plan. + * Keep implementation focused on the current feature slice. + * Example: + +```text +/rpi-implement Execute the approved first milestone from the plan. Work only in the identified service, update the necessary files, and validate the affected behavior with the repo’s existing quality gates and tests. +``` + + * If the project has strong conventions, ask the agent to follow them. + * If the repo has tests, build steps, linting, or deployment commands, include them in the validation ask. + +8. Run `/rpi-review` when the implementation is ready + * Ask the agent to compare the final code to the workshop intent and the plan. + * Make sure it checks whether the change delivered the promised outcome and whether any risks remain. + * Example: + +```text +/rpi-review Review the implementation against the workshop requirements, the approved plan, and the repository's current code patterns. Identify any gaps, risks, or follow-up work needed before marking this milestone complete. +``` + +9. Capture the final work in a small follow-up list + * Record anything left for a later milestone. + * Keep the unresolved items explicit instead of silently skipping them. + * Do not allow workshop assumptions to remain hidden inside code review. + +### Templates for GitHub Copilot + +```text +I am working in an existing repo. Here are the workshop outputs: + +- Goal: +- Constraints: +- Key decisions: +- Acceptance criteria: +- Risks: +- Relevant services or files: + +Please do the following in order: +1. /rpi-research: compare the workshop outputs to the current repo and identify implementation gaps, risks, and relevant files. +2. /rpi-plan: create a narrow first-milestone plan based on the repo and the workshop evidence. +3. /rpi-implement: execute the approved milestone and validate the changes with the repo's existing methods. +4. /rpi-review: validate that the implementation matches the workshop intent and identify any remaining follow-up work. +``` + +### Example prompt flow for an existing project + +```text +/rpi-research Compare the workshop outputs to the current repository and identify the implementation gaps, service touchpoints, and technical constraints for this feature. + +/rpi-plan Create a milestone plan for integrating the workshop recommendations into the current project without broad scope changes. Keep the plan tied to the actual files and workflows used in this repo. + +/rpi-implement Execute the approved plan for the targeted change and validate the impacted workflows using the repository's existing build or test approaches. + +/rpi-review Review the implemented change against the workshop intent, acceptance criteria, and existing repository constraints. +``` + +### Checklist + +Before asking the agents to implement, fill in this checklist: + +* What is the product outcome we want? +* What is the exact scope of the first milestone? +* Which repo areas are involved? +* What decisions from the workshop are already confirmed? +* Which assumptions still need validation? +* What would make this milestone successful? +* What is out of scope for now? + +If you can answer these questions, the repo implementation phase is much more likely to succeed. + +### Common mistakes + +* Starting code changes before comparing the workshop to the current repo +* Trying to implement the entire roadmap in one pass +* Skipping `/rpi-research` when the workshop assumptions are not yet confirmed +* Using `/rpi-implement` without a plan or review gate + +## Integrating with Microsoft/CAIRA and reusing CAF accelerators + +When the workshop is part of a customer engagement, a Microsoft-facing solution review, or a broader cloud adoption effort, use the workshop outputs as the implementation input to Microsoft/CAIRA and the Cloud Adoption Framework (CAF) program instead of treating them as a stand-alone design artifact. + +The pattern is: + +1. Use the workshop outputs as the business, user, and solution context. +2. Map that context to the relevant CAF domains and Microsoft adoption motions. +3. Reuse accelerators only where they reduce uncertainty or create a repeatable pattern. +4. Bring the accelerator decisions back into the engineering execution plan. +5. Keep the RPI workflow as the delivery engine for code, tests, and review evidence. + +### Use CAIRA as the adoption context, not as a replacement for engineering work + +CAIRA and similar Microsoft readiness processes are valuable when they help the team answer the questions that matter before implementation starts: + +* What business outcome are we trying to achieve? +* What are the target users, data, and compliance boundaries? +* What is the first tangible milestone worth delivering? +* Which decisions are already confirmed versus still uncertain? +* What would make the solution ready for broader rollout or production adoption? + +Use the workshop outputs to answer those questions in a structured way, then convert them into a milestone plan and engineering backlog. This keeps the project grounded in the customer context while still respecting the repo's actual implementation constraints. + +### Reuse CAF accelerators selectively + +CAF accelerators are most helpful when they provide a proven starting pattern rather than a broad template. Reuse them in the areas where the workshop identifies risk or unknowns: + +* landing zone and environment governance +* identity, access, and policy guardrails +* security and privacy baseline patterns +* cost optimization and scalable architecture decisions +* application modernization or migration readiness +* operational readiness, observability, and supportability + +The goal is not to copy a generic framework wholesale. The goal is to select the specific accelerator patterns that help the team move from workshop intent to a working engineering path. + +### Practical workflow for a partner team + +Use this sequence when the project includes Microsoft/CAIRA or CAF alignment: + +1. Review the workshop outputs and confirm the desired customer outcome. +2. Identify the top technical, adoption, and governance decisions that still need a pattern. +3. Match each decision to the relevant CAF domain or Microsoft accelerator path. +4. Capture the selected decisions in the project brief, architecture notes, or implementation plan. +5. Run `/rpi-research`, `/rpi-plan`, `/rpi-implement`, and `/rpi-review` in the repo to execute the agreed milestone. +6. Revisit the CAF and CAIRA considerations only when the technical implementation requires a change in scope, platform choice, or adoption model. + +### Example mapping + +| Workshop decision | CAF or Microsoft adoption lens | Engineering action | +|---|---|---| +| Need a secure environment baseline | landing zone and governance patterns | set repo and environment guardrails early | +| Need clear ownership and deployment separation | operating model and responsibility mapping | define roles, environments, and review gates | +| Need a reliable modernization path | app or platform modernization guidance | plan a phased implementation and validation gate | +| Need cost and performance discipline | Well-Architected and cost optimization guidance | size the first milestone conservatively | +| Need enterprise-grade adoption readiness | CAIRA readiness review | capture rollout, support, and adoption criteria | + +### What to bring into the repo + +When you integrate with Microsoft/CAIRA or CAF, capture the selected decisions in the project artifacts that engineers can actually use: + +* the business and user outcome +* the target milestone and first deliverable +* the environment and platform assumptions +* the security, governance, and compliance guardrails +* the deployment and support model +* the open risks and the follow-up work that remains after the milestone + +This is the bridge between enterprise adoption guidance and day-to-day engineering execution. + +## What to use when the workshop outputs are incomplete + +If workshop outputs are still vague, incomplete, or contradictory, do not jump straight into code. Treat that as a planning issue, not an implementation issue. + +Use a smaller RPI cycle first: + +1. Research the missing facts. +2. Plan the next milestone. +3. Implement only the confirmed slice. +4. Review the result and capture open questions. + +This keeps the work honest and prevents the implementation loop from hiding uncertainty behind “reasonable” code. + +## Recommended resources + +* [Getting Started Overview](README) +* [Your First Full Workflow](first-workflow) +* [Understanding the RPI Workflow](../rpi/README) +* [Why the RPI Workflow Works](../rpi/why-rpi) +* [Using RPI Together](../rpi/using-together) +* [Engineer Guide](../hve-guide/roles/engineer) +* [Stage 6: Implementation](../hve-guide/lifecycle/implementation) +* [DT to RPI Integration](../design-thinking/dt-rpi-integration) if your workshop used a Design Thinking handoff + +## Common next actions + +* Start a new implementation slice with `/rpi` or `RPI Agent`. +* Reuse the workshop artifact as the evidence source for the first plan. +* Keep the first milestone small, reviewable, and aligned to the original outcomes. +* Route follow-up items instead of letting unresolved decisions block the work. + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/partner-workshop-publishing.md b/docs/getting-started/partner-workshop-publishing.md new file mode 100644 index 0000000000..4c63e3e5eb --- /dev/null +++ b/docs/getting-started/partner-workshop-publishing.md @@ -0,0 +1,235 @@ +--- +title: Partner Workshop Publishing Follow-Up +description: Frame publication readiness for Azure Managed Application and Microsoft 365 Copilot Agent Store as a workshop handoff +sidebar_position: 11 +author: Microsoft +ms.date: 2026-08-17 +ms.topic: how-to +keywords: + - Azure Managed Applications + - Microsoft Marketplace + - Partner Center + - Microsoft 365 Copilot + - Agent Store +estimated_reading_time: 12 +--- + +## Workshop Agenda + +| Step | Activity | Time | +|------|--------------------------------------------------------------------------------------------------|--------| +| 1 | [Workshop Overview](partner-workshop.md) | 30 min | +| 2 | [Set up Codespaces or local VS Code](partner-workshop-setup.md) | 30 min | +| 3 | [Plan, Envision, Experience, Architecture Design, Backlog](partner-workshop-role-tracks.md) | 90 min | +| 4 | [Validation & Solutioning](partner-workshop-solution.md) | 30 min | +| 5 | [**Microsoft Marketplace and Copilot Agent Store readiness**](partner-workshop-publishing.md) | 60 min | +| 6 | [Handoff to Implementation & Commercialization](partner-workshop-implementation.md) | 30 min | + +Use this guide during the publication-readiness portion of the workshop. The goal is to turn the workshop outputs into a clear follow-up plan for the right publication path rather than to complete every certification step in-session. + +## Objective + +Capture the minimum work needed to make the solution reviewable and eligible for publication through Microsoft Marketplace and Microsoft 365 Copilot Agent Store. + +## Suggested workshop outcome + +By the end of the session, the team should be able to answer: + +* Which publication path is being targeted first? +* What needs to be owned by engineering, product, security, or operations? +* What remains unresolved before a real submission can happen? + +## Start with the product split + +Treat the Azure application and Microsoft 365 agent as separate products with a documented integration contract. + +1. Define what the Azure Managed Application deploys into a customer subscription. +2. Define what the Microsoft 365 agent presents to users. +3. Define the API, identity, permission, and data contract between them. +4. Define who owns configuration, support, telemetry, and upgrades. +5. Define version compatibility and failure behavior. + +## Commercial readiness and publication planning + +Before building the offer package, capture the commercial and go-to-market context that will affect Marketplace and agent-store review. + +1. Define the product brand, messaging, and primary value proposition for both the Azure offer and the Microsoft 365 agent experience. +2. Confirm the initial geographic coverage, target customer segment, and any launch limitations such as language or regional compliance constraints. +3. Define the monetization model, billing approach, and taxation expectations early so the offer plan and support model are aligned. +4. Capture a simple Lean Business Canvas summary with customer segments, problem, solution, channels, revenue, cost, partners, and differentiators. +5. For Azure IP Co-sell on Marketplace, complete a Partner Center Admin checklist that covers publisher setup, legal entity and tax readiness, offer metadata, support contacts, pricing plan, and technical package validation. +6. For a Copilot Agent Store add-on, verify the supported agent type, packaging path, tenant admin approvals, consent boundaries, and whether the agent should be listed as a standalone offer or an add-on to the Azure offer. + +> [!NOTE] +> Treat any commercial route, offer type, or add-on limitation as a verification item until current Microsoft guidance confirms the supported path. The policy matrix can change by agent type and distribution route. + +## Publication readiness checklists + +### Marketplace publishing checklist + +Use this checklist when the team is preparing an Azure Managed Application or related offer for Microsoft Marketplace. + +* [ ] Confirm the target offer type is correct for the scenario. +* [ ] Create or verify the Partner Center publisher account and ensure it is enrolled for the intended Marketplace program. +* [ ] Confirm the legal entity, tax profile, payout setup, and support contacts are complete. +* [ ] Define the offer name, short description, long description, categories, and search terms. +* [ ] Prepare product screenshots, architecture diagrams, documentation links, privacy links, and support links. +* [ ] Define the pricing model, billing plan, and any metered billing or plan-level requirements. +* [ ] Validate that the Azure deployment package is built correctly and that the package files are in the expected structure. +* [ ] Test the deployment experience in a non-production environment before submission. +* [ ] Capture the preview audience, planned launch geography, and any regional or language limitations. +* [ ] Record the owner for security, privacy, legal, support, and technical review before submission. + +### Microsoft 365 Copilot Agent Store checklist + +Use this checklist when the team is preparing a Microsoft 365 agent or Copilot experience for the Agent Store. + +* [ ] Confirm the agent type is supported for commercial publication through the current Microsoft 365 and Copilot publishing guidance. +* [ ] Verify the selected packaging path, such as Microsoft 365 Agents Toolkit or another supported packaging approach. +* [ ] Review the agent name, description, instructions, conversation starters, and approved knowledge sources. +* [ ] Verify the agent connects to the Azure service through an authenticated and least-privilege path. +* [ ] Confirm the service enforces authorization checks, not only prompt-level behavior. +* [ ] Add citations, uncertainty handling, feedback capture, and a human escalation path. +* [ ] Validate privacy, security, accessibility, and Responsible AI requirements for the experience. +* [ ] Prepare the app package, manifest, icons, screenshots, and any required support or setup documentation. +* [ ] Confirm tenant admin approvals, consent boundaries, and any required preview or pilot audience setup. +* [ ] Record the owner for validation, support, and post-launch monitoring. + +### Partner Center admin checklist + +Use this checklist for the administrative and offer-readiness review that usually happens before submission. + +* [ ] Verify the publisher identity, tenant access, and required admin roles are available. +* [ ] Confirm the legal entity, tax information, payment profile, and billing setup are complete. +* [ ] Add or verify support contacts, escalation contacts, and listing owners. +* [ ] Review the offer metadata, terms, privacy statement, and support documentation links. +* [ ] Confirm the pricing plan, plan type, and billing expectations are documented and approved. +* [ ] Ensure the technical package has been validated and uploaded successfully. +* [ ] Confirm the offer has a test or preview path with controlled users or subscriptions. +* [ ] Review dependencies, access requirements, and customer onboarding steps. +* [ ] Confirm that security, privacy, accessibility, and Responsible AI review feedback has been addressed. +* [ ] Capture the final submission owner and the date by which each remaining issue must be resolved. + +## Azure Managed Application path + +### Phase 1: Confirm publisher readiness + +1. Verify or create the publisher account in Partner Center. +2. Complete publisher verification and Marketplace enrollment. +3. Confirm the legal entity, tax, payout, support, and listing owners. +4. Confirm access to a non-production Azure subscription. +5. Register required resource providers. +6. Choose the Managed Application permission scenario. +7. Apply least privilege to publisher identities and customer operations. +8. Decide whether metered billing is required. + +### Phase 2: Build and validate the package + +1. Create a simple working folder for the package and keep the files organized before you start. +2. Define the minimum Azure resources first, such as the app service, storage account, key vault, or other required resources for the scenario. +3. Implement the deployment in Bicep if possible, because it is easier to read and maintain than raw ARM JSON. +4. Validate the Bicep locally with the Azure tooling you have available and fix any syntax or parameter issues before packaging. +5. Export or convert the validated Bicep into ARM template JSON for the Managed Application package. +6. Name the deployment template `mainTemplate.json` and keep it at the supported ARM template language version 1.0. +7. Create `createUiDefinition.json` so the portal has a guided experience for entering deployment values. +8. Map every UI field in `createUiDefinition.json` to a parameter in `mainTemplate.json` so the portal and template stay in sync. +9. Place both files at the root of `app.zip` with no extra nesting that could break the package structure. +10. Validate the ARM template and the package structure before uploading anything. +11. Test the portal experience in the CreateUiDefinition sandbox with sample values to confirm the UI behaves correctly. +12. Review secrets, vulnerabilities, RBAC, network exposure, data handling, diagnostics, quotas, and cost. +13. Deploy the package to a non-production subscription and confirm the deployment succeeds. +14. Test create, update, failure recovery, support access, and deletion from the customer experience. +15. Record any issues found during validation and fix them before the offer is submitted. + +### Phase 3: Create the Marketplace offer + +1. Sign in to [Partner Center](https://partner.microsoft.com/dashboard/home). +2. Open **Marketplace offers**. +3. Select **New offer** and then **Azure Application**. +4. Enter a permanent, unique offer ID. +5. Select the verified publisher account. +6. Complete offer setup, properties, categories, legal terms, and contracts. +7. Complete the listing content, search terms, images, support, privacy, and documentation links. +8. Add a preview audience using controlled test accounts. +9. Create a plan and choose the appropriate Azure Application plan type. +10. Upload the validated Managed Application package. +11. Save the draft and resolve validation errors. + +### Phase 4: Preview, certify, and go live + +1. Submit the offer for preview. +2. Resolve validation and certification feedback. +3. Ask preview users to deploy the offer into clean test subscriptions. +4. Verify deployment, billing, identity, telemetry, support, upgrades, and deletion from the customer perspective. +5. Obtain approval from security, privacy, accessibility, legal, support, and business owners. +6. Make the offer live once certification is complete. + +## Microsoft 365 Copilot Agent path + +### Phase 1: Offer commercialization + +1. Choose **Microsoft 365 Agents Toolkit** for a packaged declarative or custom engine agent that can target Microsoft Marketplace. + +> [!NOTE] +> Verify the current [Microsoft 365 Copilot publishing matrix](https://learn.microsoft.com/microsoft-365-copilot/extensibility/publish) before implementation because support varies by agent type and route. + +### Phase 2: Build and test the agent + +1. Create the agent in the selected tool. +2. Add the reviewed name, description, instructions, conversation starters, and approved knowledge sources. +3. Connect the Azure application through an authenticated API or supported action. +4. Apply delegated or application permissions according to least privilege. +5. Add authorization checks in the Azure service, not only in agent prompts. +6. Add citations, uncertainty behavior, feedback, and human escalation. +7. Prepare the Microsoft 365 app package, manifest, icons, and required files when using Agents Toolkit. +8. Run manifest and Responsible AI validation. +9. Side load into a test tenant with administrator approval. +10. Test expected prompts, prohibited prompts, unauthorized access, missing content, dependency failures, prompt injection, and harmful output handling. +11. Complete security, privacy, accessibility, Responsible AI, and support reviews. + +### Phase 3: Publish through Microsoft Marketplace + +1. Confirm the agent type supports commercial marketplace submission. +2. Enroll the verified Partner Center publisher in the **Microsoft 365 and Copilot** program. +3. Review Microsoft Commercial Marketplace certification policies. +4. Review Microsoft 365 Store validation guidelines for agents. +5. Complete Responsible AI validation checks. +6. Prepare customer-facing descriptions, icons, privacy policy, terms, support, setup instructions, and test credentials when required. +7. In Partner Center, create the offer type **Apps and agents for Microsoft 365 and Copilot**. +8. Upload the validated Microsoft 365 app package. +9. Submit the offer for validation and resolve certification findings. + +## Final release gate + +Do not release either product until accountable humans confirm: + +1. The customer problem is documented and validated. +2. The solution meets its business outcome and first-release criteria. +3. Technical, data, and identity boundaries are documented. +4. Accessibility checks are complete. +5. Responsible AI risks, evaluation results, and mitigations are reviewed. +6. Customer and publisher permissions follow least privilege. +7. Cost, metering, licensing, support, incident response, and service ownership are defined. +8. Preview deployments and pilot agent installations succeeded. +9. Rollback, update, monitoring, and customer communication plans exist. +10. Partner Center and tenant administrators have granted required approvals. + +## Playback and next steps + +Use this section to close the workshop with a clear handoff. + +1. Ask each role to summarize the key decision, dependency, or risk it surfaced. +2. Confirm which publication route is the first target: Azure Managed Application, Microsoft 365 Copilot agent, or both. +3. Record the primary owners for engineering, product, security, privacy, support, and publishing operations. +4. Capture the top three blockers that must be resolved before submission. +5. Assign a follow-up owner and a target date for each remaining action. +6. Keep the output as a draft until a responsible human reviewer confirms it. +7. Engineers would continue to implement the project. + +Proceed to the [implementation guide](partner-workshop-implementation.md). +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/partner-workshop-role-tracks.md b/docs/getting-started/partner-workshop-role-tracks.md new file mode 100644 index 0000000000..c3c9c5c6cf --- /dev/null +++ b/docs/getting-started/partner-workshop-role-tracks.md @@ -0,0 +1,311 @@ +--- +title: Partner Workshop Role Guide +description: Structured role-based guide for the HVE partner workshop +sidebar_position: 9 +author: Microsoft +ms.date: 2026-08-17 +ms.topic: tutorial +keywords: + - Project Manager + - Subject Matter Expert + - UX Designer + - Engineer + - HVE roles +estimated_reading_time: 10 +--- + +## Workshop Agenda + +| Step | Activity | Time | +|------|--------------------------------------------------------------------------------------------------|--------| +| 1 | [Workshop Overview](partner-workshop.md) | 30 min | +| 2 | [Set up Codespaces or local VS Code](partner-workshop-setup.md) | 30 min | +| 3 | [**Plan, Envision, Experience, Architecture Design, Backlog**](partner-workshop-role-tracks.md) | 90 min | +| 4 | [Validation & Solutioning](partner-workshop-solution.md) | 30 min | +| 5 | [Microsoft Marketplace and Copilot Agent Store readiness](partner-workshop-publishing.md) | 60 min | +| 6 | [Handoff to Implementation & Commercialization](partner-workshop-implementation.md) | 30 min | + +Use this guide during the role-exercise portion of the workshop. Participants should work from the same scenario, capture assumptions, and leave with a handoff that the next role can use. + +## Suggested role order + +A practical sequence for the workshop is: + +1. Subject Matter Expert creates the shared context pack. +2. Project Management turns the draft into requirements, priorities, and backlog structure. +3. Design translates that context into an experience draft and captures accessibility and responsible AI needs. +4. Technical frames the solution approach, architecture, and publication considerations. +5. The team reviews the handoff together during the solution integration step. + +This sequence helps each role build on the previous one without waiting for perfect information. + +## HVE vs Agile + +| Agile | HVE | +|-----------------------------------------------|-----------------------------------------------------------| +| Sprint-first and feature-first | Outcome-first and value-first | +| Backlog refinement often drives delivery | Shared context and AI-assisted planning drive delivery | +| Teams often interpret requirements separately | Humans and agents work from the same context and evidence | +| Large feature sets can be explored too early | Small outcome slices help teams learn quickly | + +## Workshop flow + +1. Review the shared scenario and workshop context. +2. Choose a role track and complete its guided steps. +3. Share your artifact with the rest of the team. +4. After the role tracks, proceed first to the [Partner Workshop solution](partner-workshop-solution.md) guide to integrate the outputs, then continue to the [Partner Workshop Publishing Follow-Up](partner-workshop-publishing.md) guide for publication readiness. + +## Track overview + +| Track | Primary objective | Suggested output | +|-----------------------|-------------------------------------------------------------------|----------------------------------------| +| Project Management | Turn context into requirements, priorities, and backlog structure | Requirements draft and backlog outline | +| Subject Matter Expert | Capture business facts, rules, constraints, and evidence | Context pack | +| Design | Express the user experience, pain points, and success criteria | Experience draft | +| Technical | Frame the solution, architecture, and deployment considerations | Architecture and publication notes | + +## HVE Agent Guide + +Use the HVE agents as lightweight helpers for your role. Start with your own draft, then ask an agent to refine or structure it. + +* **BRD Builder** or **PRD Builder** for first-draft requirements and a simple structure for business outcomes, scope, and acceptance criteria. In this workshop, the Project Management role should typically own the BRD/PRD draft, while the Subject Matter Expert provides the business context, evidence, and constraints that inform it. +* **Functional Planner** for turning a draft requirement into a lightweight epic, feature, story, and task hierarchy when the team needs a delivery handoff. +* **UX UI Designer** for user journeys, pain points, wireframe outline, and experience artifacts. +* **Design Thinking Coach** for facilitation and discovery. +* **Design Thinking Learning Tutor** for guided learning and method support. +* **Accessibility Planner** for accessibility requirements and inclusive design considerations. +* **Accessibility Reviewer** for a review pass on accessibility readiness. +* **RAI Planner** for responsible AI requirements, risks, and guardrails. +* **RAI Reviewer** for a responsible AI review pass. +* **System Architecture Reviewer** for framing a simple solution approach, tradeoffs, and architecture notes. +* **GitHub Backlog Executor** for creating or updating GitHub Issues after the backlog is reviewed. +* **Security Planner** for additional review, risk checks, and readiness considerations. + +### Getting Started Guide + +1. Start with a plain-language draft for your role instead of trying to make it perfect. +2. Pick one HVE agent that matches your role and ask for a simple first draft. +3. Review the draft, adjust it with your own notes, and keep the language concrete. +4. Save the work in the workshop output folder with clear filenames such as 01-context-pack.md, 02-Requirements.md, and 03-experience.md. +5. Share the draft with the next role so the handoff stays clear. +6. If you get stuck, choose the simplest next action: clarify the problem, add one user story, or outline one backlog item. + +Across all roles, design for publication of your solution to Microsoft Marketplace and Microsoft 365 Copilot Agent Store. Publishing solutions to the Microsoft Marketplace is one of the fastest ways to scale reach, simplify customer procurement, earn rewards, incentives and GTM benefits, and create recurring revenue opportunities. + +Keep your outputs clear enough to support packaging, discovery, and review in both destinations. + +## Subject Matter Expert track + +### Objective + +Capture the business truth before anyone designs or builds anything. + +### Steps + +1. Create a workshop-output folder and a 01-context-pack.md file. Refer to samples\FSI\01-context-pack.md or samples\Retail\01-context-pack.md. +2. Review the shared scenario and workshop context so your notes stay grounded in the brief. +3. Gather available evidence such as policy documents, SOPs, process diagrams, notes, document references, PDFs, screenshots, and images. +4. Record the problem statement, affected users, and business impact. +5. Separate facts from assumptions, decisions, and open questions. +6. Capture business rules, known failure cases, and AI guardrails. +7. If you need structure, ask **BRD Builder** or **PRD Builder** to turn your notes into a simple outline that the Project Management role can refine. Start by pasting your notes into the agent and ask it to draft a problem statement, business goals, scope, assumptions, and acceptance criteria. +8. Select the context draft and use this prompt in GitHub Copilot Chat: + +```text +"Use the following notes to draft a concise product requirements document for the solution. Create a clear problem statement, business goals, target users, scope, assumptions, constraints, success metrics, and acceptance criteria. Organize the output so it can be used by design, product, and engineering. Include any relevant business rules, known failure cases, and AI guardrails. Update 02-requirements.md." +``` + +1. When evidence is available, reference supporting documents, PDFs, screenshots, and images as supporting context. Keep the language practical. The result is a simple outline that can be refined into a full PRD. +2. Save the results in a concise context pack for the next roles, including links or references to supporting documents, PDFs, and images when available. + +### Deliverable + +1. workshop-output\01-context-pack.md: A context pack that the design and product teams can use to refine the experience and requirements. + +2. workshop-output\02-requirements.md: A requirements draft that can be reviewed by engineering and design. + +## Design Track + +### Objective + +Translate the business context into a clear user experience and shared +understanding of the problem. + +### Steps + +1. Read the context pack workshop-output\01-context-pack.md created by the SME. +2. Plan for a design thinking [**Microsoft AI Discovery Cards workshop**](https://aka.ms/AIDiscoveryCards) to brainstorm agentic AI capabilities with end users and stakeholders. +3. Select one primary user and one core job to be done. +4. Map the current journey and identify pain points. +5. Describe the future journey with the intended solution. +6. Add accessibility and responsible AI requirements. +7. If you need a first draft, ask **UX UI Designer** to turn the problem into a simple user journey and experience outline. + Select the 01-context-pack file and use this prompt in GitHub Copilot Chat: + +```text +"Turn these notes into a simple user journey, experience outline, and key pain points for this scenario in 03-experience.md." +``` + +1. If the team needs a guided conversation, ask **Design Thinking Coach** to help frame the opportunity and challenge assumptions. + +```text +"Coach me through a short design thinking session for this scenario. Help me frame the problem, identify user needs, and define a focused opportunity area for the solution." +``` + +1. If the team needs learning support or a clearer next step, ask **Design Thinking Learning Tutor** to explain the method and help transform notes into a simple design artifact. + +```text +"Act as a Design Thinking Learning Tutor. Explain the next design thinking step for this scenario and help me turn my notes into an insight, opportunity statement, or user journey outline." +``` + +1. Use Accessibility Planner and Accessibility Reviewer to surface accessibility requirements and review the draft for gaps. + Select the 03-experience.md and prompt Accessibility Planner: + +```text +"Review this experience draft and identify accessibility requirements, user needs, follow-up questions for implementation and update the draft." +``` + +1. Use RAI Planner and RAI Reviewer to capture responsible AI requirements, guardrails, and review findings. + Select the 03-experience.md and **RAI Planner** prompt: + +```text +"Review this experience draft and identify responsible AI requirements, potential harms, mitigation ideas and update the draft." +``` + +1. If your team uses Figma, include links or references to Figma files, wireframes, and design artifacts in the experience draft. Use Figma outputs as evidence for user flows, screens, and design decisions, and note how those artifacts support the workshop handoff. +2. Identify and validate the use case for publishing to Microsoft 365 Copilot Agent Store. + Select the 03-experience.md and prompt UX UI Designer: + +```text +"How would end users benefit from Microsoft 365 Copilot integrated to this scenario? What research would I need to run to validate it? Update the 03-experience.md." +``` + +1. Note how the experience should be packaged, discoverable, and reviewable for Microsoft Marketplace and Microsoft 365 Copilot Agent Store. +2. Define success criteria and unresolved questions. +3. Save the results as the 03-experience.md draft. + +### Deliverable + +workshop-output\03-experience.md: A user experience draft that captures the user path, pain points, and design constraints. + +## Project Management track + +### Objective + +Turn business context and user experience into requirements, priorities, and a backlog draft. + +### Steps + +1. Review the context pack in workshop-output/01-context-pack.md, workshop-output/02-requirements.md and workshop-output/03-experience.md. Align them to business outcomes, measurable success metrics, functional and non-functional requirements, user stories, acceptance criteria, out-of-scope items, and open assumptions. +2. Create a backlog outline only if it helps the team move from requirements to implementation. If needed, use a lightweight hierarchy such as epic, feature, story, and task for the first MVP. +3. Prioritize the first MVP with simple labels such as P0, P1, and P2 only if the team needs a sequencing signal. Keep this lightweight and outcome-focused rather than turning it into a rigid Agile process. +4. Prepare the requirements and backlog artifacts for publication readiness in Microsoft Marketplace and Microsoft 365 Copilot Agent Store. + Select the context, requirements, experience and prompt Functional Planner: + +```text +"Review the workshop requirements, context pack, and experience draft for the relationship manager scenario. Refine the backlog draft in 05-backlog.md into a more implementation-ready first-slice plan with clear epics, features, stories, and tasks. Then prioritize the first slice with simple labels such as P0, P1, and P2 only if they help the team sequence the work. Also assess whether the backlog and scope are aligned to publication readiness for Microsoft Marketplace and Microsoft 365 Copilot Agent Store, including any requirements that should be captured early for packaging, discoverability, and review readiness. Keep the output concise, outcome-focused, and useful for backlog refinement and implementation." +``` + +1. If you are targeting GitHub Issues, ask Backlog Manager to coordinate the workflow and have GitHub Backlog Executor create the first parent issue and child issues for the initial MVP. The Backlog Manager should also ensure the resulting issue links and summary are logged in the workshop output folder for traceability. + + Enable writing of GitHub issues: + + * Authenticate GitHub CLI + * Run: gh auth login --web + * Or, if needed: gh auth refresh -h github.com -s repo + * Verify authentication + * Run: gh auth status + * Confirm the target repository + * Run: gh repo set-default [your git clone url]/hve-partner-workshop + * Create GitHub Issues the backlog creation from a session that exposes GitHub write tools + * If you are using Copilot or an agent workflow, make sure the session has access to the GitHub MCP write tools. + * Refer to using [Using the GitHub MCP server from Copilot Chat](https://docs.github.com/en/copilot/how-tos/copilot-on-github/copilot-for-github-tasks/using-the-github-mcp-server-from-copilot-chat) + * Refer to [Using the GitHub MCP server in your IDE](https://docs.github.com/en/copilot/how-tos/provide-context/use-mcp-in-your-ide/use-the-github-mcp-server) + + Prompt: + +```text +"Review the approved requirements and backlog outline, confirm the target GitHub repository, create the first parent issue and child issues for this initial MVP, and log the issue links and summary in the workshop output folder for traceability. Use labels such as P0, P1, P2, epic, feature, story, and task only if they help the team’s workflow. Update the 05-backlog.md and create the backlog in GitHub Issues." +``` + +1. Review the issue list for traceability from business outcome to requirement to backlog item, then save the final backlog summary and issue links in your workshop output folder. + +### Deliverable + +workshop-output\05-backlog.md: A backlog of features, stories or tasks for translating business outcome to trackable work items. + +## Technical track + +### Objective + +Frame the solution approach, architecture, and publication considerations. + +### Steps + +1. Review the requirements, and experience draft. +2. Identify the core services, data sources, and integration points. +3. Select **System Architecture Reviewer** to help frame a simple solution approach, major tradeoffs, and architecture notes. + + * Note deployment, security, and operational considerations. + * Review the draft for well-architected design and Cloud Adoption Framework guidance. + * Capture the publication requirements for Microsoft Marketplace and Microsoft 365 Copilot Agent Store readiness, including packaging, discoverability, supportability, and integration expectations. + * Create a simple Mermaid architecture diagram for the proposed solution. + +```text +"Review the 02-requirements.md and 03-experience.md and help frame a simple solution approach, major tradeoffs, and cloud architecture notes for the first MVP. Update 04-architecture.md. Consider where Microsoft Foundry, Microsoft 365 Copilot, Microsoft Agent 365 Control Plane, Microsoft Entra ID, Microsoft Fabric, Microsoft IQ and Azure Databases fit the solution where appropriate. Review this solution for well-architected design concerns, align the approach to Microsoft Cloud Adoption Framework guidance, and identify any gaps in reliability, security, operational excellence, performance efficiency, and cost optimization for the first MVP. Identify the integration and publication requirements needed to make this solution ready for Microsoft Marketplace and Microsoft 365 Copilot Agent Store, including packaging details, metadata, support expectations, and any required user experience or technical integrations. Create a Mermaid architecture diagram for this solution that shows the main user flow, core services, data sources, and key integrations for the first MVP." +``` + +1. Use Security Planner to review readiness and surface follow-up work. + +```text +"Review this solution draft for security risks, deployment considerations, and follow-up actions needed before implementation." +``` + +1. Review the mermaid diagram and use natural language to refine it. +2. (Optional) Instead of GitHub Copilot, use Microsoft 365 Copilot to create an image. In M365 Copilot, attach 04-architecture.md, and create an architecture image from the mermaid diagram for this solution using Azure and Copilot-style icons to represent core services, data sources, user experience layers, and integrations for the first MVP. + +```text +"Create an architecture image from the mermaid diagram for this solution using Azure and Copilot-style icons to represent core services, data sources, user experience layers, and integrations for the first MVP." +``` + +1. Create the publication-readiness artifact using the same workshop output folder. + * Create a new file named `06-publication-readiness.md`. + * Start with a short summary of the solution, the target user, and the intended publication path. + * Add a section for solution summary and value proposition. + * Add a section for product branding, marketing, and positioning, including the customer story and differentiators. + * Add a section for geographic coverage and launch scope, including target regions, language needs, and any compliance or data residency constraints. + * Add a section for commercial readiness, including pricing, monetization, billing, taxation, and any Marketplace or agent-store commercial terms. + * Add a section for a simple Lean Business Canvas summary to capture customer segments, problem, solution, channels, revenue, cost, partners, and differentiators. + * Add a section for a Partner Center Admin publication checklist for Azure IP Co-sell on Marketplace, including publisher setup, offer metadata, legal terms, support contacts, and tax or billing readiness. + * Add a section for Copilot Agent Store add-on considerations, including any known limits, required tenant approvals, packaging constraints, and whether the agent should be published as a standalone offer or an add-on to an Azure offer. + * Add a section for user experience and packaging notes, including screenshots, diagrams, and any Microsoft 365 Copilot integration value. + * Add a section for technical readiness, including core services, integrations, deployment model, and prerequisites. + * Add a section for security, privacy, and governance, including access controls, data handling, and Responsible AI guardrails. + * Add a section for support and operations, including ownership, known limitations, and rollout expectations. + * Add a closing checklist for publication readiness, including the owners and follow-up items that still need attention. + + ```text + "Review the requirements, experience draft, architecture notes, and backlog outline for the relationship manager scenario. Create a concise publication-readiness document in 06-publication-readiness.md that captures the solution summary, target user, value proposition, product branding and marketing notes, geographic coverage and market scope, monetization and taxation considerations, a Lean Business Canvas summary, Partner Center Admin publication checklist for Azure IP Co-sell on Marketplace, Copilot Agent Store add-on readiness, user experience and packaging notes, technical readiness, security and privacy considerations, support and operations expectations, and a simple checklist of remaining publication work. Focus on what is needed for Microsoft Marketplace and Microsoft 365 Copilot Agent Store readiness, keep the output practical and workshop-friendly, and identify any owners or follow-up items that still need attention." + ``` + +2. Share the output with the rest of the team. + +### Deliverable + +1. workshop-output\04-architecture.md: A technical draft with architecture notes, risks, and next steps, including a reference to the architecture diagram. + +2. workshop-output\06-publication-readiness.md: A concise publication-readiness draft that captures the target route, technical readiness, governance needs, and follow-up work. + +## Working session reminder + +Keep the output concise and action-oriented. Do not wait for perfect +information. The goal is to produce a reviewed draft that the team can refine after the workshop. + +Proceed to the [solution guide](partner-workshop-solution.md). + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/partner-workshop-setup.md b/docs/getting-started/partner-workshop-setup.md new file mode 100644 index 0000000000..844799cb81 --- /dev/null +++ b/docs/getting-started/partner-workshop-setup.md @@ -0,0 +1,135 @@ +--- +title: Partner Workshop Setup +description: Shared Codespaces and local VS Code setup instructions for the HVE partner workshop +sidebar_position: 8 +author: Microsoft +ms.date: 2026-08-17 +ms.topic: tutorial +keywords: + - GitHub Codespaces + - Visual Studio Code + - macOS + - HVE Core All + - workshop setup +estimated_reading_time: 8 +--- + +## Workshop Agenda + +| Step | Activity | Time | +|------|--------------------------------------------------------------------------------------------------|--------| +| 1 | [Workshop Overview](partner-workshop.md) | 30 min | +| 2 | [**Set up Codespaces or local VS Code**](partner-workshop-setup.md) | 30 min | +| 3 | [Plan, Envision, Experience, Architecture Design, Backlog](partner-workshop-role-tracks.md) | 90 min | +| 4 | [Validation & Solutioning](partner-workshop-solution.md) | 30 min | +| 5 | [Microsoft Marketplace and Copilot Agent Store readiness](partner-workshop-publishing.md) | 60 min | +| 6 | [Handoff to Implementation & Commercialization](partner-workshop-implementation.md) | 30 min | + +> [!NOTE] +> These instructions use **Visual Studio Code**. The HVE Core extension is a VS Code extension. The full Visual Studio IDE is not the workshop host. Visual Studio users can keep the IDE installed and use VS Code or GitHub Codespaces for the workshop activities. + +## Choose Your Setup Path + +Select the setup option that fits your environment, then follow the matching steps below. + +* Use Option A if you want a browser-based VS Code experience in GitHub Codespaces. +* Use Option B if you want to run VS Code locally on Windows or macOS. + +## Shared Prerequisites + +Before you begin either option, complete these steps: + +1. Sign in to your GitHub account with GitHub Copilot access. +2. Confirm your organization permits GitHub Copilot Chat. + +## Option A: GitHub Codespaces + +1. Open the **Code** dropdown, select the **Codespaces** tab, and create a Codespace. +2. Wait for the browser-based VS Code window to finish loading. +3. Confirm GitHub Copilot and GitHub Copilot Chat are enabled in the Codespace. +4. Open the Extensions view from the Activity Bar. +5. Search for **HVE Core All**, confirm the publisher is `ISE-HVE-ESSENTIALS`, and install it in the Codespace. +6. Open the terminal in Codespaces and clone the workshop repository at [https://github.com/asiapartners/hve-partner-workshop](https://github.com/asiapartners/hve-partner-workshop) and open it in your chosen environment. +7. Create a branch for workshop activities before you start editing files. Use a name such as `workshop/`. +8. Reload the window if VS Code asks you to do so. + +## Option B: Local VS Code On Windows Or macOS + +1. Install [Git](https://git-scm.com/downloads) and [Visual Studio Code](https://code.visualstudio.com/Download). +2. Open VS Code, open the Extensions view, and install **GitHub Copilot** and **GitHub Copilot Chat**. +3. Sign in with your GitHub account that has Copilot access. +4. Install [HVE Core All](https://marketplace.visualstudio.com/items?itemName=ise-hve-essentials.hve-core-all). +5. Open the Command Palette, run **Git: Clone** on [https://github.com/asiapartners/hve-partner-workshop](https://github.com/asiapartners/hve-partner-workshop), and open it. +6. Select **Open** when cloning finishes, and select **Trust** only when you recognize the repository and facilitator. +7. Create a branch for workshop activities before you start editing files. Use a name such as `workshop/`. + +If you have Foundry local models available in your environment, prefer them for local inference. Otherwise, select `MAI-Code-1-Flash` in GitHub Copilot Chat for a more cost-effective option. + +On macOS, use the same menus and buttons. Keyboard shortcuts that use `Ctrl` on Windows often use `Command` on macOS, so this workshop favors menu navigation. + +## Verify The Environment + +Complete these steps in either environment: + +1. Open Copilot Chat from the Activity Bar. +2. Open the agent picker in the Chat view. +3. Confirm that agents such as **RPI Agent**, **BRD Builder**, **UX UI Designer**, and **System Architecture Reviewer** are visible. +4. Type `/` in Chat. +5. Confirm that RPI prompts appear. +6. Enter this prompt: + +```text +Review the repository and identify the most relevant HVE Core assets for a partner workshop scenario. Summarize the likely workflow, likely agents, and any prerequisites before the team begins the role exercises. +``` + +If the expected agents are missing: + +1. Open the Extensions view. +2. Disable **HVE Installer** if both extensions are installed. +3. Run **Developer: Reload Window** from the Command Palette. +4. Reopen Copilot Chat and check the agent picker again. +5. Use the [troubleshooting guide](troubleshooting.md) if the problem remains. + +## Create The Workshop Workspace + +Ask the technical lead to complete these steps: + +1. Create a folder named `workshop-output` at the repository root. +2. Add six empty Markdown files using the names in the [workshop overview](partner-workshop.md#outcomes). + +```text +workshop-output/ +|-- 01-context-pack.md +|-- 02-requirements.md +|-- 03-experience.md +|-- 04-architecture.md +|-- 05-backlog.md +`-- 06-publication-readiness.md +``` + +1. Add the scenario title and team member roles to `01-context-pack.md`. +2. Do not enter credentials, personal data, customer secrets, or production content in prompts or files. +3. Commit your workshop outputs to your branch only. + +> [!TIP] +> Use `.copilot-tracking/` only for temporary workflow state. Keep that folder in `.gitignore`. Create `workshop-output` at the repository root so it stays the team's reviewed, shareable result. + +## Learn The Interaction Pattern + +In the next step, we will use the same pattern in every role exercise: + +1. Select the named agent or invoke the named skill. +2. Provide the scenario, known facts, constraints, and requested output path. +3. Ask for a first draft. +4. Review and revise the result. +5. Save only the reviewed result to `workshop-output`. +6. Hand the artifact to the next role. + +Proceed to the [role guide](partner-workshop-role-tracks.md). + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/partner-workshop-solution.md b/docs/getting-started/partner-workshop-solution.md new file mode 100644 index 0000000000..7064c19793 --- /dev/null +++ b/docs/getting-started/partner-workshop-solution.md @@ -0,0 +1,130 @@ +--- +title: Partner Workshop solution +description: Integrate role outputs into a shared solution pack, backlog, architecture view, and publication-readiness plan +sidebar_position: 10 +author: Microsoft +ms.date: 2026-08-17 +ms.topic: tutorial +keywords: + - workshop solution + - backlog + - requirements traceability + - Azure diagram + - publication readiness +estimated_reading_time: 8 +--- + +## Workshop Agenda + +| Step | Activity | Time | +|------|--------------------------------------------------------------------------------------------------|--------| +| 1 | [Workshop Overview](partner-workshop.md) | 30 min | +| 2 | [Set up Codespaces or local VS Code](partner-workshop-setup.md) | 30 min | +| 3 | [Plan, Envision, Experience, Architecture Design, Backlog](partner-workshop-role-tracks.md) | 90 min | +| 4 | [**Validation & Solutioning**](partner-workshop-solution.md) | 30 min | +| 5 | [Microsoft Marketplace and Copilot Agent Store readiness](partner-workshop-publishing.md) | 60 min | +| 6 | [Handoff to Implementation & Commercialization](partner-workshop-implementation.md) | 30 min | + +Use this guide during the solution portion of the workshop. Participants should bring their role outputs together, check for gaps and traceability, and leave with a reviewed handoff that can be refined after the session. + +## Objective + +Create one shared solution draft that connects business context, requirements, experience, backlog, architecture, and publication readiness into a coherent story. + +## Suggested solution flow + +1. Ask each role to summarize its artifact in two minutes. +2. Open the workshop output files in the shared folder. +3. Compare terminology across the files and resolve contradictions. +4. Use the SME context pack as the source of truth for domain terms and business rules. +5. Confirm that each user story identifies a user, need, and outcome. +6. Confirm that each acceptance criterion is observable and testable. +7. Confirm that each architecture component maps to at least one requirement. +8. Confirm that high-risk requirements and important decisions map to backlog items. +9. Confirm that the experience captures uncertainty, feedback, access failures, and human escalation. +10. Record unresolved items as follow-up work in 06-publication-readiness.md. + +## Traceability review + +Select **RPI Planner** and enter this prompt: + +```text +"Review the workshop output set from 01-context-pack.md through 06-publication-readiness as one solution pack. Build a traceability matrix from context facts and decisions to requirements, experience needs, architecture components, backlog items, tests, and publication gates. Report missing links, contradictions, unsupported claims, and unowned risks. Do not implement or publish anything." +``` + +Then complete these steps: + +1. Capture the matrix draft in 07-traceability-matrix.md +2. Assign an owner to each gap. +3. Fix gaps that can be resolved from workshop evidence. +4. Record remaining gaps in 06-publication-readiness.md +5. Mark generated content as draft until a responsible human reviews it. + +## Prepare the backlog target + +Choose one target. Creating external items is optional during the workshop. + +### GitHub Issues + +1. Select **Backlog Manager**. +2. Ask it to inspect 05-backlog.md for readiness and duplicates. +3. Confirm repository, labels, milestone, owners, and issue hierarchy. +4. Ask for a dry-run summary before any mutation. +5. Review the proposed issue titles and acceptance criteria. +6. Create issues only with facilitator approval and repository permission. + +### Markdown-only fallback + +1. Keep 05-backlog.md as the system-neutral backlog. +2. Add columns for target system, owner, state, and external ID. +3. Assign a post-workshop owner to import or create each approved item. + +## Review the architecture + +1. Open 04-architecture.md in Markdown Preview. +2. Follow the primary user request from Microsoft 365 Copilot to the Azure API, retrieval layer, model, and response path. +3. Follow the content ingestion and update path separately. +4. Identify where authorization is enforced. +5. Identify where secrets and keys are stored. +6. Identify where prompts, retrieved content, responses, and feedback could be logged. +7. Confirm telemetry does not collect secrets or unnecessary personal data. +8. Add failure paths for model, search, identity, and dependency outages. +9. Add a cost owner and an operational owner. +10. Mark the diagram as conceptual until infrastructure source and deployment validation exist. + +## Create the follow-up plan + +1. Open 06-publication-readiness.md +2. Add separate sections for Azure Managed Application and Microsoft 365 agent. +3. Record required accounts, subscriptions, tenants, roles, and approvers. +4. Record security, privacy, accessibility, legal, support, and Responsible AI reviews. +5. Record test environments and preview audiences. +6. Record listing content, icons, screenshots, privacy links, support links, and terms that still need owners. +7. Assign target dates outside the workshop. +8. Continue with the [publication guide](partner-workshop-publishing.md). + +## Ten-minute team discussion + +1. The PM presents the outcome, requirements, and first release slice. +2. The SME presents key constraints and unresolved domain questions. +3. The designer presents the primary journey and human review points. +4. The technical lead presents the architecture view and publication routes. +5. The team names its three highest risks. +6. The facilitator confirms owners and the next review date. + +## Deliverable + +A reviewed workshop handoff that connects context, requirements, experience, backlog, architecture, and publication readiness into one shared draft. + +## Working session reminder + +Keep the output concise and action-oriented. Do not wait for perfect information. The goal is to produce a reviewed draft that the team can refine after the workshop. + +Proceed to the [publishing guide](partner-workshop-publishing.md). + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/partner-workshop.md b/docs/getting-started/partner-workshop.md new file mode 100644 index 0000000000..d697a50119 --- /dev/null +++ b/docs/getting-started/partner-workshop.md @@ -0,0 +1,121 @@ +--- +title: HVE Partner Workshop +description: Workshop for partners to create requirements, context, a backlog, Azure architecture, and publication plans with HVE Core +sidebar_position: 7 +author: Microsoft +ms.date: 2026-08-17 +ms.topic: tutorial +keywords: + - partner workshop + - HVE Core + - role-based learning + - Azure architecture + - Microsoft Marketplace + - Copilot Agent Store +estimated_reading_time: 8 +--- + +Use this workshop to move a product idea to a connected set of delivery artifacts. Participants work in one shared project, split into role tracks, and then combine their outputs into a requirements pack, prioritized backlog, Azure architecture, and publication readiness plan. + +The workshop teaches a repeatable workflow. It does not compress production security review, Azure deployment, or Microsoft Marketplace certification into a day. + +## Workshop Agenda + +| Step | Activity | Time | +|------|--------------------------------------------------------------------------------------------------|--------| +| 1 | [**Workshop Overview**](partner-workshop.md) | 30 min | +| 2 | [Set up Codespaces or local VS Code](partner-workshop-setup.md) | 30 min | +| 3 | [Plan, Envision, Experience, Architecture Design, Backlog](partner-workshop-role-tracks.md) | 90 min | +| 4 | [Validation & Solutioning](partner-workshop-solution.md) | 30 min | +| 5 | [Microsoft Marketplace and Copilot Agent Store readiness](partner-workshop-publishing.md) | 60 min | +| 6 | [Handoff to Implementation & Commercialization](partner-workshop-implementation.md) | 30 min | + +## Outcomes + +By the end of the facilitated session, the team can: + +* Provide HVE Core grounded business, user, domain, design, and technical context +* Create business and user requirements with testable acceptance criteria +* Convert requirements into a prioritized GitHub backlog +* Generate and review a Mermaid architecture diagram for an Azure solution +* Explain the steps and approval gates for an Azure Managed Application offer on Microsoft Marketplace +* Explain the supported routes to the Microsoft 365 Copilot Agent Store + +The team should leave with these artifacts: + +```text +workshop-output/ +|-- 01-context-pack.md +|-- 02-requirements.md +|-- 03-experience.md +|-- 04-architecture.md +|-- 05-backlog.md +`-- 06-publication-readiness.md +``` + +| Outcome | Complete In Workshop | Continue After Workshop | +|-------------------------------|---------------------------------------|--------------------------------------------------------| +| Context and user requirements | Reviewed draft | Customer validation and approval | +| Backlog | Prioritized draft or planning handoff | Create approved external work items | +| Architecture Design | Reviewed conceptual Mermaid diagram | Implement and validate infrastructure | +| Azure Managed Application | Package and offer readiness plan | Build, test, certify, and publish offer on Marketplace | +| Microsoft 365 Copilot Agent | Experience and distribution plan | Build, test, approve, and publish agent | + +> [!IMPORTANT] +> HVE Core custom agents run in GitHub Copilot and VS Code. They are not +> Microsoft 365 Copilot agents and cannot be uploaded directly to the Agent +> Store. The team should build the customer-facing agent with a supported +> Microsoft 365 agent tool, package it, validate it, and follow the applicable +> organizational catalog or Partner Center publishing route. + +## Audience And Roles + +Form multidisciplinary teams of four to six people. + +| Track | Suggested Participants | Primary Workshop Output | +|-----------------------|------------------------------------------------------------------------|-------------------------------------------------------------------------| +| Project Management | PM, Program manager, Product owner | Outcomes, requirements, priorities, backlog structure | +| Subject Matter Expert | Industry SME, Compliance Lead, Operations Lead | Domain context, terminology, constraints, evidence | +| Design | UX Designer, Service Designer, Design Thinking Facilitator, Researcher | Personas, User Journey, Accessibility, Responsible AI, Agent experience | +| Technical | Architect, Forward Deployed Engineer, Security, Platform Lead | Azure design, diagram, deployment and publication plan | + +Review the broader [HVE role guides](../hve-guide/roles/) after the workshop for ongoing role-specific workflows. + +### Sample Scenario + +Use this scenario when participants do not bring a project: + +> A partner wants to offer a Service Knowledge Assistant to enterprise +> customers. Support specialists ask questions in Microsoft 365 Copilot and +> receive grounded answers from approved product and service documents. Each +> customer deploys the Azure data, search, model, API, identity, and monitoring +> resources into its own subscription through an Azure Managed Application. +> The solution must preserve source citations, respect user access, avoid using +> customer content for model training, and provide operational audit evidence. + +Do not use production customer data during the workshop. Use synthetic or public sample content. + +## Participant Flow + +1. Complete [shared setup](partner-workshop-setup.md). +2. Choose a section in the [role guide](partner-workshop-role-tracks.md). +3. Complete the [cross-role solution guide](partner-workshop-solution.md). +4. Complete the [publication guide](partner-workshop-publishing.md) during the workshop and finish it after the session. + +## Completion Standard + +The workshop is complete when the team has reviewed the six draft artifacts, identified unresolved assumptions, and assigned owners for publication follow-up. Actual Azure deployment, commercial Microsoft Marketplace validation, and Copilot Agent Store availability are post-workshop milestones unless the facilitator explicitly provides extra time and project managers have authorized environments. + +## Related Guidance + +* [Installing HVE Core](install.md) +* [Your First Full Workflow](first-workflow.md) +* [Architecture Diagrams Skill](../agents/project-planning/arch-diagram-builder.md) +* [MCP Configuration](mcp-configuration.md) + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/samples/FSI/01-context-pack.md b/docs/getting-started/samples/FSI/01-context-pack.md new file mode 100644 index 0000000000..ef58d358bb --- /dev/null +++ b/docs/getting-started/samples/FSI/01-context-pack.md @@ -0,0 +1,130 @@ +--- +title: "Context Pack FSI" +description: "Context pack for the financial services relationship manager" +author: Microsoft +ms.date: 2026-08-17 +ms.topic: reference +keywords: + - sample + - FSI + - context pack + - workshop +estimated_reading_time: 5 +--- + +## Platform + +* Platform: Operations Intelligence Platform +* Purpose: Help teams turn operational signals into timely decisions, coordinated actions, and measurable outcomes across business functions. +* Scope: Focus on high-value scenarios that combine data, workflow, and agent-assisted execution. + +## Selected industry scenarios + +* Financial services: Relationship Manager + +## Active scenario + +* Scenario title: Relationship Manager Intelligence Experience +* Business problem: Relationship managers often work from fragmented information spread across CRM systems, email threads, call notes, transaction history, and internal knowledge sources. They spend too much time gathering context and too little time acting on the most valuable opportunities. As a result, they can miss early warning signals, delay follow-up, and overlook high-potential cross-sell or upsell moments. +* Core challenges: + * Fragmented customer and account insights across multiple tools + * Manual research and data gathering before each client interaction + * Difficulty prioritizing accounts that need attention now + * Limited visibility into risk, growth potential, and next-best actions + * Inconsistent follow-through that reduces retention and revenue outcomes +* Desired outcome: Give the relationship manager one trusted view of account health, customer signals, risk exposure, and recommended actions so they can respond faster, act with confidence, and focus on opportunities that matter most. +* Revenue impact: By surfacing timely, evidence-based recommendations, the organization can improve retention, increase cross-sell and upsell success, grow wallet share, and unlock new revenue through more proactive relationship management. +* User requirements for the product: + * Consolidate customer, account, and activity signals into a single view + * Highlight priority accounts and the most valuable next actions + * Surface both risk indicators and growth opportunities with supporting evidence + * Recommend actions that help the manager deepen relationships and grow revenue + * Support fast follow-up with clear, explainable recommendations that the manager can trust + +## Team + +* PM: Workshop product lead +* SME: Relationship management subject matter expert +* Designer: Experience designer +* Technical lead: Solution architect or engineering lead + +## Partner solution framing + +* Target users: + * Primary: Relationship managers who prepare for customer conversations and need timely, trusted guidance. + * Secondary: Team leads, account owners, and risk or compliance reviewers who need visibility into account priorities and evidence-backed recommendations. +* Jobs to be done: + * Understand account context quickly before a customer interaction. + * Identify at-risk accounts and growth opportunities. + * Prioritize the most valuable next actions. + * Decide what to say or do next with confidence. +* Business outcomes: + * Improve retention and account health. + * Increase cross-sell and upsell opportunity capture. + * Reduce missed follow-up and delayed actions. + * Help the organization grow revenue through more proactive relationship management. +* Measurable success metrics: + * Time to understand account context before an interaction: target less than 5 minutes. + * Number of prioritized actions completed within 24 hours: target greater than 70%. + * Conversion rate of recommended opportunities into customer actions: target greater than 12%. + * Improvement in account coverage for priority relationships: target greater than 85%. +* Stakeholders: + * Relationship managers as primary users. + * Business leaders who care about growth, retention, and revenue outcomes. + * Risk or compliance stakeholders who need explainable recommendations and governance. + * Product, design, and technical teams building the experience. + * Sales operations or CRM administrators who support data quality and workflow integration. +* Assumptions: + * The solution will be framed as a scenario-specific experience rather than a one-size-fits-all platform. + * The team will capture the scenario details, assumptions, and open questions in this file before expanding to other industries. + * The product should support explainable recommendations rather than opaque automation. + * The initial release will rely on approved enterprise data sources and human review of suggested actions. +* Exclusions: + * No market research or competitor claims are included in this framing. + * No production-sensitive customer data or credentials. + * No detailed implementation decisions are assumed at this stage. + +## Open questions + +* Which customer or operational signals are most important for the first release? +* Which actions should be suggested to the relationship manager first? +* What evidence or approvals are required before the system recommends a next step? +* Which exact user roles should be included in the target-user definition? +* Which stakeholders need to review or sign off on the experience? + +## Simple user journey + +1. The relationship manager prepares for an upcoming customer conversation or follow-up. +2. They open the account view and quickly review recent signals, account health, and outstanding actions. +3. The experience highlights the highest-priority risks and growth opportunities with supporting evidence. +4. The manager reviews the recommended next-best action and decides whether to act, defer, or escalate. +5. The action is documented for follow-up, with the outcome visible for later review. + +## Experience outline + +* Account snapshot: a concise summary of recent customer activity, account status, and key signals. +* Priority view: a ranked list of the most important risks, opportunities, and next actions. +* Evidence panel: visible supporting context for each recommendation, including why it matters. +* Action decision: a simple path to review, approve, defer, or escalate a suggested step. +* Follow-up trail: a lightweight record of actions taken and outcomes for future conversations. + +## Key pain points + +* Context is scattered across multiple tools, which slows preparation. +* Managers spend too much time manually researching before each interaction. +* It is hard to tell which accounts need attention first. +* Recommendations are not always easy to trust without clear evidence. +* Follow-through is inconsistent, which reduces retention and growth opportunities. + +## Constraints + +* Do not add credentials, personal data, customer secrets, or production content. +* Keep the content concise, reviewable, and suitable for collaborative workshop use. +* The initial experience should remain scenario-specific and human-reviewable rather than fully automated. + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/samples/FSI/02-requirements.md b/docs/getting-started/samples/FSI/02-requirements.md new file mode 100644 index 0000000000..798c4820e6 --- /dev/null +++ b/docs/getting-started/samples/FSI/02-requirements.md @@ -0,0 +1,127 @@ +--- +title: "Workshop Requirements" +description: "Concise requirements for the FSI relationship manager" +sidebar_position: 2 +author: Microsoft +ms.date: 2026-08-15 +ms.topic: reference +keywords: + - workshop + - requirements + - FSI + - relationship manager +estimated_reading_time: 5 +--- + +## Workshop Requirements Draft + +This draft consolidates the relationship manager scenario into a concise product requirements view for workshop use. It is intended for review by design, product, and engineering before deeper backlog refinement. + +### Problem Statement + +Relationship managers spend too much time collecting fragmented customer context before conversations and follow-up work. They need a trusted, single view that highlights risks, opportunities, and next-best actions so they can prepare quickly and follow through consistently. + +### Business Goals + +* BR-01 Improve account coverage and retention by helping relationship managers act on the most important signals sooner. +* BR-02 Increase cross-sell and upsell opportunity capture through earlier identification of growth moments. +* BR-03 Reduce missed follow-up and delayed actions by surfacing clear next steps with supporting evidence. + +### Target Users + +* PR-01 Relationship manager: prepares for customer conversations and needs a trusted view of account health and recommended actions. +* PR-02 Team lead or account owner: needs to prioritize coverage and monitor which accounts require attention. +* PR-03 Risk or compliance reviewer: needs explainable recommendations and confidence in the evidence behind them. + +### Scope + +#### In Scope + +* Consolidate customer, account, and activity signals from multiple sources into one view. +* Surface priority accounts and identify the most valuable next actions. +* Highlight risks and growth opportunities with supporting evidence. +* Support human-reviewable follow-up and action tracking. + +#### Out of Scope + +* Full workflow automation across all business processes. +* Production-sensitive customer data or credentials. +* A broad multi-industry platform release in the first version. + +### Assumptions and Constraints + +#### Assumptions + +* Approved enterprise data sources will be available for the workshop scenario. +* Relationship managers and reviewers will help validate the signal set and recommendation quality. + +#### Constraints + +* C-01 No production credentials, personal data, customer secrets, or sensitive content may be used in the workshop scenario. +* C-02 The solution must remain concise, reviewable, and suitable for collaborative workshop use. +* C-03 The initial scope should remain scenario-specific rather than expanding into a generalized platform vision. + +### Functional Requirements + +* FR-01 The experience must consolidate customer, account, and activity signals from multiple sources into a single view. +* FR-02 The experience must highlight priority accounts and identify the most valuable next actions. +* FR-03 The experience must surface both risk indicators and growth opportunities with supporting evidence. +* FR-04 The experience must recommend actions that help the user deepen relationships and grow revenue. +* FR-05 The experience must support fast follow-up with clear, explainable recommendations that the user can trust. + +### Non-Functional Requirements + +* NFR-01 The experience must present recommendations with enough context for a human reviewer to understand why they were suggested. +* NFR-02 The experience must be usable in a fast-paced workflow, with response times that support real-time preparation for customer interactions. +* NFR-03 The experience must protect sensitive information and avoid exposing credentials, personal data, or production secrets. +* NFR-04 The experience must be reviewable and understandable for workshop stakeholders, including business, design, and technical participants. + +### Data and AI Requirements + +* DAI-01 The system must use approved enterprise data sources such as CRM records, email or call context, transaction history, and internal knowledge content. +* DAI-02 Recommendations must be grounded in cited evidence and must distinguish between observed facts and inferred suggestions. +* DAI-03 The experience must support human review of AI-generated recommendations before action is taken. +* DAI-04 The system must avoid using unverified or unsupported claims as customer facts. + +### Business Rules + +* Recommendations must be tied to visible evidence and understandable to a human reviewer. +* Human approval is required before any operational action is executed from a suggestion. +* The system must prioritize clarity and trust over automation when evidence is incomplete. +* Only approved enterprise data sources may be used in the experience. + +### Known Failure Cases + +* Source data is missing, stale, or inconsistent. +* Signals conflict and the system cannot determine a clear priority. +* The recommendation confidence is low and should be shown as uncertain. +* No reasonable next-best action can be produced for the current account state. + +### Success Metrics + +* Time to understand account context before an interaction: target less than 5 minutes. +* Percentage of prioritized actions completed within 24 hours: target greater than 70%. +* Conversion rate of recommended opportunities into customer actions: target greater than 12%. +* Improvement in account coverage for priority relationships: target greater than 85%. + +### Acceptance Criteria + +* AC-01 When a relationship manager opens the experience for an account, the system presents consolidated context and the most relevant next action within the first screen. +* AC-02 When an account shows elevated risk or growth potential, the system highlights that signal and provides supporting evidence. +* AC-03 When the user reviews a recommendation, the system shows the underlying evidence and allows the user to understand the reasoning. +* AC-04 When the user completes a recommended action, the system records that action as part of the follow-up workflow. + +### AI Guardrails + +* Do not fabricate evidence, customer facts, or actions that are not supported by approved data. +* Clearly label uncertainty, low-confidence outputs, and inferred recommendations. +* Show the rationale and evidence behind every recommendation so it can be reviewed by a human. +* Avoid exposing sensitive or personally identifiable information outside approved contexts. +* Fail safely when data is incomplete or the system cannot produce a trustworthy recommendation. + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/samples/FSI/03-experience.md b/docs/getting-started/samples/FSI/03-experience.md new file mode 100644 index 0000000000..5c53cbcbf5 --- /dev/null +++ b/docs/getting-started/samples/FSI/03-experience.md @@ -0,0 +1,127 @@ +--- +title: "Experience Outline: Relationship Manager for FSI" +description: "User experience brief for the financial services relationship manager" +author: Microsoft +ms.date: 2026-08-17 +ms.topic: reference +keywords: + - sample + - FSI + - experience + - workshop +estimated_reading_time: 5 +--- + +## Scenario summary + +A relationship manager needs a trusted view of each account before customer conversations and follow-up work. The experience should help them quickly understand account health, surface risks and growth opportunities, and choose the next best action with confidence. + +## Simple user journey + +1. Prepare for the conversation + * The relationship manager opens the account view for a priority client. + * The experience gathers CRM data, email history, call notes, transaction activity, and internal knowledge into one place. + +2. Review account context + * The manager sees the latest signals, account health, and likely risks or opportunities. + * The experience highlights which accounts need attention now and why. + +3. Decide on the next step + * The manager reviews suggested talking points, likely next actions, and the evidence behind each recommendation. + * The experience helps them act quickly without starting from scratch. + +4. Follow up after the interaction + * The manager captures the next action and moves smoothly to execution. + * The experience supports consistent follow-through and keeps the team aligned. + +## Experience outline + +* A unified view of customer, account, and activity signals +* Clear prioritization of accounts that need attention now +* Visible risk indicators and growth opportunities with supporting evidence +* Recommended next-best actions that are explainable and easy to trust +* A fast path from insight to follow-up so the manager can act promptly + +## Key pain points + +* Context is scattered across multiple tools, which slows preparation. +* Too much time is spent gathering information before each interaction. +* It is hard to tell which accounts need immediate attention. +* Risk exposure and growth potential are not always clear. +* Follow-through is inconsistent, which weakens retention and revenue outcomes. + +## Accessibility requirements + +* The experience must be fully keyboard accessible for reviewing account summaries, priority actions, and follow-up choices. +* Content must be structured with clear headings and labels so screen-reader users can navigate the account view efficiently. +* Priority signals, risks, and recommended actions must not rely on color alone; they should include text labels or icons with text alternatives. +* Text and interactive elements must meet strong contrast and readable sizing standards. +* Recommendations should be presented in plain language with visible evidence and a clear explanation of why the action matters. +* The experience should support predictable focus order and clear confirmation feedback for actions such as approve, defer, or escalate. + +## Accessibility user needs + +* Users need to understand the most important account information quickly without reading a long or dense screen. +* Users need to distinguish between priority actions, risks, opportunities, and evidence without ambiguity. +* Users need to trust and review recommendations through clear, readable explanations. +* Users need to complete core tasks with assistive technologies, including keyboard navigation and screen readers. +* Users need a low-cognitive-load experience that reduces confusion during time-sensitive interactions. + +## Follow-up questions for implementation + +* Which screens or components are most critical for keyboard and screen-reader testing? +* How should recommendation confidence and evidence be presented when data is incomplete or uncertain? +* What accessibility validation tools and assistive technologies should be used during implementation? +* Should the experience include a simplified view for high-pressure or time-sensitive workflows? +* How will users review, override, or dismiss a suggested action if they do not agree with it? +* How should the experience support users who need more time, clearer language, or reduced visual complexity? + +## Responsible AI requirements + +* Recommendations must be explainable and traceable to visible evidence. +* The experience should clearly label uncertain, low-confidence, or inferred recommendations. +* Users must be able to review, override, or reject suggested actions before they are acted on. +* The experience should avoid exposing sensitive or personally identifiable information beyond what is necessary for the task. +* The system should fail safely when data is missing, incomplete, or inconsistent. +* Human review should remain part of the workflow for high-impact actions. + +## Potential harms + +* Recommendations may be wrong, incomplete, or overly confident. +* Users may over-trust suggested actions without reviewing the evidence. +* Sensitive customer information could be exposed if data handling is not carefully limited. +* Bias in underlying data could lead to unfair or skewed prioritization. +* The experience could create automation bias by making users feel they should follow recommendations without question. + +## Mitigation ideas + +* Show the evidence, confidence level, and rationale for each recommendation. +* Require a human review step before operational action is taken. +* Use clear labels for uncertainty and provide an option to request more context. +* Limit visible data to approved fields and protect sensitive information. +* Review data sources and recommendation logic for bias, fairness, and quality issues. +* Capture user feedback and review outcomes to improve the experience over time. + +## Microsoft 365 Copilot integration benefits + +* End users could save time by asking Copilot to summarize account context, recent interactions, and likely next steps in natural language. +* Relationship managers could prepare more quickly for customer conversations by using Copilot to pull together evidence from existing documents, notes, and account history. +* The experience could help users draft follow-up emails, meeting notes, and action summaries more consistently. +* Copilot could reduce manual effort in reviewing fragmented data and support better focus on customer relationships rather than admin work. +* The integration could improve confidence if Copilot surfaces concise, evidence-based summaries that are easy to review and verify. + +## Research needed to validate the value + +* Run interviews with relationship managers, team leads, and reviewers to understand where they currently lose time and where Copilot would be most useful. +* Observe a sample of existing workflows to identify the most frequent preparation and follow-up tasks that could benefit from AI assistance. +* Test a prototype with users to measure whether Copilot-generated summaries and next-step suggestions improve speed, clarity, and trust. +* Validate whether users prefer Copilot output that is short, explainable, and grounded in visible evidence. +* Assess whether the integration changes behavior in a positive way, such as faster follow-up, better account coverage, or improved confidence in recommendations. +* Confirm that users understand the limits of Copilot and still want human review for important decisions. + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/samples/FSI/04-architecture.md b/docs/getting-started/samples/FSI/04-architecture.md new file mode 100644 index 0000000000..49a8b73fbe --- /dev/null +++ b/docs/getting-started/samples/FSI/04-architecture.md @@ -0,0 +1,223 @@ +--- +title: "Architecture draft: Relationship Manager for FSI" +description: "Solution approach, security review, Cloud Adoption Framework alignment, publication readiness, and architecture diagram" +sidebar_position: 4 +author: Microsoft +ms.date: 2026-08-17 +ms.topic: reference +keywords: + - architecture + - FSI + - relationship manager + - Microsoft Marketplace + - Copilot Agent Store +estimated_reading_time: 10 +--- + +## Proposed MVP solution approach + +A lightweight first-slice experience can be delivered as a scenario-specific account workspace that combines approved enterprise data with an evidence-backed recommendation layer. The experience should present a single account view, highlight priority actions, and keep the user in control through explainable guidance and human review before any action is taken. + +### Recommended MVP shape + +* The experience starts with one primary workflow: preparing for a customer conversation. +* The account view shows a concise summary, the most relevant signals, the evidence behind the recommendation, and a clear next action. +* Recommendations are framed as assistive suggestions rather than hidden automation. +* The first release uses a small set of approved data sources and a curated or mocked data set for workshop validation, with real connectors added later. + +## Recommended Microsoft platform fit + +For the first MVP, the stack should stay simple and purposeful rather than introducing every possible platform capability at once. + +* Microsoft Foundry is the most natural place to host the orchestration, grounding, and prompt workflow for evidence-backed recommendations. +* Microsoft 365 Copilot can provide an optional entry point for summarization and follow-up drafting inside the user’s existing workflow. +* Microsoft Agent 365 Control Plane is appropriate if the team wants a more explicit agent control and policy layer for role-based assistance, follow-up actions, and guided task execution. +* Microsoft Entra ID should be the standard identity and access control layer for the experience and its connected services. +* Microsoft Fabric is a good fit for later analytics, reporting, and trend review, but it can remain optional in the first slice if the team wants to keep deployment lightweight. +* Microsoft IQ can be used as a signal-enrichment layer to improve account context ranking, relationship insights, and prioritization quality when available. +* Azure Databases should be used for any minimal structured state such as workflow metadata, reviewed recommendations, or task history once the solution moves beyond a purely demo-oriented setup. + +## Core services + +* Experience layer: account workspace, summary view, and recommended next actions for the relationship manager. +* Orchestration service: coordinates data retrieval, grounding, recommendation generation, response formatting, and confidence labeling. +* Insight and recommendation service: identifies risks, growth signals, and next-best actions based on visible evidence. +* Retrieval and grounding layer: connects approved data sources and surfaces cited evidence supporting each recommendation. +* Action tracking service: records follow-up tasks, recommended next steps, and completion status for the user workflow. +* Governance and observability layer: manages logging, auditability, permission checks, and reviewability for workshop stakeholders. + +## Data sources and integration points + +* CRM system: customer and account profile data, relationship history, and account ownership context. +* Email and call context: recent communications, notes, and engagement signals. +* Transaction history: account activity, product holdings, and recent financial behavior. +* Internal knowledge sources: policy documents, playbooks, internal guidance, and approved reference content. +* Identity and permissions service: ensures the right users and reviewers can access the right data. +* Workflow integration: links recommended actions to follow-up tasks, task tracking, or downstream business processes. +* Optional Microsoft 365 Copilot integration: can summarize account context and draft follow-up content when the user explicitly requests it. +* Optional Microsoft Agent 365 Control Plane integration: can enforce agent lifecycle policies, tool governance, and agent routing controls. +* Optional Microsoft Fabric integration: can be used later for reporting, insight trend review, and adoption analysis. +* Optional Microsoft IQ integration: can enrich relationship signals and improve recommendation relevance. +* Optional Azure Databases integration: can store structured workflow state, reviewed recommendations, and task history for a more production-like experience. + +## Major tradeoffs + +* Human-in-the-loop vs. automation: keep recommendations explainable and reviewable in the first slice rather than automating sensitive actions too early. +* Breadth vs. depth: prioritize one concise, high-value experience over a broad multi-scenario experience. +* Speed vs. completeness: use a small set of approved data sources first, then expand after stakeholder feedback. +* Custom implementation vs. managed platform services: start with a simple hosted experience and managed identity and telemetry patterns instead of overbuilding a custom distributed platform. + +## Architecture notes for the first MVP + +* Keep the user experience simple and task-focused. +* Treat recommendations as evidence-backed suggestions, not hidden automation. +* Make the reasoning visible so risk and compliance reviewers can trust the output. +* Design the first slice for workshop reviewability and early validation, not full production scale. +* Preserve a clear human review path for any action that could affect a customer relationship. +* Use explicit confidence labels and safe fallback behavior when data is incomplete or low quality. + +## Cloud architecture notes for the first MVP + +* Use a modular cloud design with clear boundaries between experience, orchestration, data retrieval, and follow-up workflows. +* Keep stateful and stateless services separate so the orchestration layer can scale independently from storage and analytics components. +* Use managed identity, managed secrets, and managed observability services to reduce operational overhead in early releases. +* Introduce Microsoft Fabric and Microsoft IQ as optional capabilities behind feature flags so the first slice remains lightweight. +* Treat Microsoft 365 Copilot and Microsoft Agent 365 Control Plane as channel and governance surfaces that consume shared orchestration APIs. + +## Security review and implementation follow-up + +The current draft is directionally strong, but implementation should not begin until a few controls are explicitly defined. + +### Key security risks + +* Data overexposure: the system could expose more customer or account detail than necessary for the task. +* Weak evidence grounding: recommendations may appear authoritative without visible sources or confidence labeling. +* Unauthorized access: the experience may allow users to view data outside their approved business context. +* Prompt or content injection risk: untrusted knowledge sources or user input could influence the recommendation logic in unsafe ways. +* Insufficient auditability: follow-up actions may not be traceable for compliance or review purposes. + +### Follow-up actions before implementation + +* Define a data classification and minimization policy for the workshop scenario. +* Enforce least-privilege access with Microsoft Entra ID and role-based permissions. +* Restrict the solution to approved data sources and approved fields only. +* Add a clear review and override path for users before any operational action is taken. +* Store audit data for recommendation review, user decisions, and follow-up outcomes. +* Validate that no production credentials, personal data, secrets, or customer-sensitive content are included in the sample environment. +* Add content safety and grounding checks so generated summaries or recommendations do not fabricate evidence. + +## Deployment and operations considerations + +* Deployment: use a lightweight hosted experience with clearly scoped data access for the workshop environment. +* Security: avoid production credentials, personal data, customer secrets, and sensitive content; enforce least-privilege access and role-based permissions. +* Operations: log recommendation activity, maintain review trails, and define clear ownership for monitoring and follow-up. +* Reliability: support graceful fallback when a data source is unavailable and keep the user experience understandable under partial failure. +* Support model: document support ownership, escalation paths, known limitations, and how the user should report issues. + +## Well-architected review and Microsoft Cloud Adoption Framework alignment + +The first MVP should align to Microsoft Cloud Adoption Framework guidance by focusing on a secure, governed, and easy-to-operate foundation rather than a broad platform expansion. + +### Reliability + +* Add graceful degradation when a connector is unavailable or returns partial data. +* Define retry and timeout behavior for data retrieval and recommendation requests. +* Keep a clear fallback experience when a recommendation cannot be produced confidently. + +### Security + +* Use Microsoft Entra ID for identity and access control. +* Apply least privilege to app registrations, API scopes, and data access connectors. +* Protect secrets in Key Vault or equivalent managed secret storage. +* Apply data loss prevention and content filtering where relevant. +* Ensure the agent or assistant cannot expose data outside the current user context. + +### Operational excellence + +* Add telemetry for page load latency, data retrieval failures, recommendation confidence, and user review outcomes. +* Define an ownership model for support, monitoring, and incident response. +* Keep deployment simple with repeatable configuration and documented rollback steps. + +### Performance efficiency + +* Retrieve only the data necessary for the current account view. +* Use caching for static or frequently reused context where appropriate. +* Optimize for fast response times during live customer preparation workflows. + +### Cost optimization + +* Keep the first MVP rules-based or lightly assisted rather than heavy-model or compute-intensive. +* Use managed services and small-scale hosting to avoid unnecessary cost at early stages. +* Avoid overprovisioning infrastructure when the scope is a workshop or pilot experience. + +## Marketplace and Microsoft 365 Copilot Agent Store readiness + +The solution should be treated as two related products for publication planning: an Azure-based offering and a Microsoft 365 Copilot experience. + +### Packaging and distribution requirements + +* Azure-based deployment: package the solution as a managed application or supported Azure deployment artifact with clear configuration, identity, and dependency documentation. +* Microsoft 365 experience: package the agent or experience with its name, description, instructions, icons, screenshots, and supported tenant settings. +* For the first MVP, a workshop or pilot package is sufficient, but the package should still be structured so it can later be submitted through Partner Center or the Microsoft 365 agent publishing path. + +### Metadata and listing requirements + +* Clear product title and short description that explain the scenario and value. +* Customer-facing summary, audience, key capabilities, screenshots, and support information. +* Privacy, compliance, accessibility, and Responsible AI disclosures. +* Publisher identity, versioning, support contact, and terms of use. + +### Support expectations + +* Publicly document support channels, response expectations, and known limitations. +* Include onboarding steps, deployment notes, and troubleshooting guidance. +* Define who owns incident escalation and update communications. + +### User experience and technical integration requirements + +* The experience should support single sign-on and tenant-aware access. +* The agent or experience should clearly show citations or evidence for recommendations. +* The user should be able to review, override, or reject a suggested action before it is acted on. +* The experience should include feedback capture for trust, usefulness, and recommendation quality. +* The solution should support clear human escalation for low-confidence or high-impact suggestions. +* Integration guidance should define which capabilities are required for baseline readiness (Foundry, Entra ID, and core data connectors) and which are optional for phase two (Fabric, Microsoft IQ, and advanced agent governance via Agent 365 Control Plane). + +## Architecture diagram + +Rendered image: [Relationship Manager for FSI Architecture.jpg](Relationship%20Manager%20for%20FSI%20Architecture.jpg) + +```mermaid +flowchart LR + User[Relationship Manager] --> UI[Account Workspace UI] + UI --> Copilot[Microsoft 365 Copilot] + UI --> AgentCP[Microsoft Agent 365 Control Plane] + UI --> Orchestrator[Foundry Orchestration Layer] + Orchestrator --> CRM[CRM Data] + Orchestrator --> Email[Email and Call Context] + Orchestrator --> Txn[Transaction History] + Orchestrator --> Knowledge[Internal Knowledge] + Orchestrator --> MIQ[Microsoft IQ] + Orchestrator --> Insights[Recommendation Service] + Insights --> UI + Orchestrator --> Actions[Action Tracking] + Actions --> Workflow[Follow-up Workflow] + Orchestrator --> Auth[Microsoft Entra ID] + Orchestrator --> Telemetry[Telemetry and Audit Logging] + Orchestrator --> DB[Azure Database] + Orchestrator --> Fabric[Microsoft Fabric Analytics] + Copilot --> Orchestrator + AgentCP --> Orchestrator + Orchestrator --> Governance[Security, Privacy, and Review Controls] + Governance --> Publish[Marketplace and Agent Store Readiness] +``` + +## Summary + +The proposed MVP is practical for workshop use and is well aligned to a human-review-first experience. The main gaps to resolve before implementation are access control, evidence grounding, auditability, deployment ownership, and publication packaging. If those controls are defined early, the solution can evolve from a workshop demo into a more enterprise-ready product without changing the core user experience. + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/samples/FSI/05-backlog.md b/docs/getting-started/samples/FSI/05-backlog.md new file mode 100644 index 0000000000..d92488c7df --- /dev/null +++ b/docs/getting-started/samples/FSI/05-backlog.md @@ -0,0 +1,87 @@ +--- +title: "Backlog" +description: "Backlog hierarchy for the relationship manager" +sidebar_position: 5 +author: Microsoft +ms.date: 2026-08-16 +ms.topic: reference +keywords: + - backlog + - workshop + - FSI + - relationship manager +estimated_reading_time: 5 +--- + +## First MVP Backlog Draft + +This draft refines the workshop requirements into a more implementation-ready backlog for the first MVP. It stays lightweight, but it is structured enough for backlog refinement, sequencing, and early implementation planning. + +### Epic + +* EPIC-01 Prepare the relationship manager for customer conversations with a trusted account view + +### Features + +* FEAT-01 Unified account context view +* FEAT-02 Evidence-backed priority signals and next-best actions +* FEAT-03 Reviewable follow-up and action capture + +### Stories and Tasks + +#### FEAT-01 Unified account context view + +* STORY-01 As a relationship manager, I can open an account view that consolidates customer, account, and activity context so I can prepare quickly. + * TASK-01 Identify approved data sources for the workshop scenario. + * TASK-02 Create a simple account summary view that surfaces key customer and account facts. + * TASK-03 Display recent interactions, transactions, and internal notes in one place. + * TASK-04 Define the initial layout for the first-slice experience and its core information hierarchy. + +#### FEAT-02 Evidence-backed priority signals and next-best actions + +* STORY-02 As a relationship manager, I can see which accounts need attention now and why. + * TASK-05 Define the initial priority rules for risk and growth signals. + * TASK-06 Surface urgency, risk indicators, and growth opportunities with supporting evidence. + * TASK-07 Label recommendations as high confidence, low confidence, or uncertain when data is incomplete. + +* STORY-03 As a relationship manager, I can review suggested next-best actions with clear rationale before acting. + * TASK-08 Create a recommendation panel for the next-best action. + * TASK-09 Show the evidence and reasoning behind each recommendation. + * TASK-10 Add a review path for approve, defer, or escalate decisions. + +#### FEAT-03 Reviewable follow-up and action capture + +* STORY-04 As a relationship manager, I can record the chosen action and keep follow-up work aligned. + * TASK-11 Create a simple action capture flow for selected follow-up steps. + * TASK-12 Record the action outcome and completion status for review. + * TASK-13 Ensure the workflow fails safely when the system cannot produce a trustworthy recommendation. + +### Suggested Priority for the First MVP + +* P0: Unified account context view +* P0: Evidence-backed recommendations with clear rationale +* P1: Reviewable follow-up and action capture + +### Publication Readiness Notes + +* Capture early packaging and discoverability requirements for Microsoft Marketplace and Microsoft 365 Copilot Agent Store. +* Document the minimum user experience and support expectations needed for review readiness, including clear value, trust, and explainability. +* Keep the first MVP focused on a clearly scoped scenario so it remains easy to review and publish later. + +### GitHub Issue Status + +* A planning-ready backlog hierarchy has been prepared for the first slice. +* The backlog is ready to be translated into GitHub Issues once a GitHub-capable execution context is available. + +### Notes for Backlog Refinement + +* Keep the first slice focused on one primary scenario: preparing for a customer conversation. +* Treat evidence, trust, and human review as core requirements rather than optional enhancements. +* Use this draft as the starting point for a more detailed implementation backlog once the team confirms scope and data availability. + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/samples/FSI/06-publication-readiness.md b/docs/getting-started/samples/FSI/06-publication-readiness.md new file mode 100644 index 0000000000..efabb901e2 --- /dev/null +++ b/docs/getting-started/samples/FSI/06-publication-readiness.md @@ -0,0 +1,196 @@ +--- +title: "Publication Readiness" +description: "Practical publication-readiness checklist and ownership plan for the FSI relationship manager MVP" +sidebar_position: 6 +author: Microsoft +ms.date: 2026-08-17 +ms.topic: reference +keywords: + - publication readiness + - Microsoft Marketplace + - Microsoft 365 Copilot Agent Store + - FSI + - relationship manager +estimated_reading_time: 7 +--- + +## Publication Readiness Draft + +This draft captures the minimum information needed to prepare the relationship manager MVP for Microsoft Marketplace and Microsoft 365 Copilot Agent Store review. + +## Solution summary + +The MVP helps a relationship manager prepare for customer conversations by consolidating account context, surfacing risks and opportunities, and recommending next-best actions with visible evidence and human review. + +## Target user + +* Primary: relationship manager preparing for customer interactions. +* Secondary: team lead or account owner monitoring priority coverage. +* Secondary: risk or compliance reviewer validating recommendation quality and traceability. + +## Value proposition + +* Reduces time-to-context for customer preparation. +* Improves consistency of follow-up actions. +* Increases confidence through explainable recommendations and clear evidence. +* Supports publication-ready positioning as a practical, governed AI-assisted workflow. + +## Product positioning and go-to-market + +### Branding and marketing + +* Keep the product name, short description, and value statement consistent across Marketplace and Copilot Agent Store listings. +* Prepare a simple narrative that explains the customer problem, the AI-assisted workflow, and the business outcome. +* Capture differentiators such as human review, evidence-backed recommendations, and role-based workflow fit. + +### Geographic coverage and launch scope + +* Identify the initial target regions and any language requirements for the first launch. +* Note any compliance, data residency, or regional support constraints that affect publication scope. +* Keep the first release focused on a clear launch geography rather than a broad global rollout. + +### Monetization, billing, and taxation + +* Define the commercial model early, including whether the offer is free, paid, metered, or tied to an Azure subscription. +* Document billing and tax expectations, payout or invoicing requirements, and any customer-facing pricing notes. +* Align the commercial story with the Marketplace offer plan and any agent add-on packaging assumptions. + +### Lean Business Canvas summary + +* Customer segments: relationship managers, sales leaders, and compliance reviewers. +* Problem: manual context gathering and inconsistent follow-up planning. +* Solution: governed AI-assisted preparation and review workflow. +* Channels: direct sales, partner channels, and Microsoft marketplace discovery. +* Revenue and cost: define pricing, support cost, and operating assumptions early. +* Partners and differentiators: partner, security, and support stakeholders should be named as part of the launch plan. + +## User experience and packaging notes + +### Core user flow + +* Open account workspace. +* Review consolidated signals and evidence-backed recommendations. +* Approve, defer, or escalate next action. +* Capture follow-up outcome. + +### Packaging assets needed + +* One-page solution summary for listing copy. +* Architecture diagram and one end-to-end flow diagram. +* Screenshots for account overview, recommendation panel, and action review state. +* Demo script showing trust controls, confidence labels, and human approval. + +### Copilot and agent value narrative + +* Microsoft 365 Copilot supports optional summarization and follow-up drafting. +* Microsoft Agent 365 Control Plane can enforce agent policy, tool governance, and routing rules. + +## Commercial and marketplace readiness + +### Partner Center Admin checklist for Azure IP Cosell on Marketplace + +* Confirm the Partner Center publisher, legal entity, tax profile, payout setup, and support contacts. +* Define the offer type, pricing plan, billing model, and any required customer terms or legal content. +* Prepare listing metadata, categories, privacy and support links, documentation, screenshots, and diagrams. +* Confirm the technical package, deployment experience, and certification readiness for the Marketplace offer. +* Record owner names for publisher administration, legal review, finance, and support escalation. + +### Copilot Agent Store add-on considerations + +* Verify the agent type and distribution path support commercial or add-on packaging before committing to a listing plan. +* Document required tenant admin approvals, consent boundaries, support expectations, and any dependency on the Azure offer. +* Treat the following as verification items before submission: supported agent type, supported commercial route, required approvals, packaging constraints, and whether the listing should be a standalone offer or an add-on. + +## Technical readiness + +### Baseline integration set for first publishable slice + +* Microsoft Foundry for orchestration, grounding, and recommendation flow. +* Microsoft Entra ID for identity, access control, and tenant-aware sign-in. +* Core data connectors for CRM, interaction history, transaction signals, and internal knowledge. +* Azure Databases for structured workflow state and reviewed action history. + +### Optional phase-two integrations + +* Microsoft Fabric for analytics, trend review, and adoption reporting. +* Microsoft IQ for signal enrichment and ranking quality improvements. + +### Deployment and prerequisites + +* Document environment prerequisites, connector dependencies, and tenant setup steps. +* Define app registration scopes, consent model, and secrets handling approach. +* Publish configuration guidance for pilot and production-like environments. + +## Security, privacy, and governance + +* Enforce least privilege through Microsoft Entra ID roles and scoped connector access. +* Apply data minimization and approved-field filtering to prevent overexposure. +* Store secrets in managed secret storage and avoid plain-text configuration. +* Log recommendation evidence, user decisions, and action outcomes for auditability. +* Require human review for high-impact actions. +* Label uncertainty and low-confidence outputs, and fail safely when data quality is insufficient. + +## Support and operations expectations + +### Support ownership + +* Technical lead owns architecture, deployment, and support runbook readiness. +* Project manager owns publication narrative, scope control, and release coordination. +* Design lead owns screenshot assets, UX clarity, and accessibility evidence. +* Security or compliance reviewer owns policy checks and governance sign-off. + +### Operating expectations + +* Define incident path, escalation contacts, and response expectations. +* Document known limitations and explicit out-of-scope behavior for MVP. +* Monitor latency, connector failures, confidence trends, and user feedback. + +## Publication requirements + +### Microsoft Marketplace + +* Prepare listing metadata: product title, description, category, target customer, and value statement. +* Include deployment and configuration documentation with support contact details. +* Provide privacy, compliance, accessibility, and Responsible AI disclosures. + +### Microsoft 365 Copilot Agent Store + +* Prepare agent package details: name, description, instructions, icon, screenshots, and tenant settings. +* Document Microsoft 365 integration prerequisites and consent boundaries. +* Validate user experience standards for evidence visibility, safe actions, and feedback loops. + +## Remaining checklist and follow-up owners + +| Item | Status | Owner | Follow-up | +|-----------------------------------------------------------------------------|-------------|----------------------------------------|-------------------------------------------------------------------------------------| +| Confirm final solution name and listing copy | Open | Project manager | Draft final short and long descriptions for both destinations | +| Finalize branding, positioning, and marketing narrative | Open | Project manager | Prepare a clear value proposition, differentiators, and launch messaging | +| Define geographic coverage and launch scope | Open | Project manager | Confirm target regions, language needs, and any launch constraints | +| Define pricing, billing, and taxation model | Open | Business owner | Align commercial terms with the Marketplace plan and any add-on packaging | +| Complete Partner Center Admin checklist for Azure IP Co-sell on Marketplace | Open | Partner Center admin or business owner | Confirm publisher setup, offer metadata, legal terms, support, and tax readiness | +| Confirm Copilot Agent Store add-on limits and approvals | Open | Technical lead | Validate supported agent type, packaging constraints, and required tenant approvals | +| Finalize architecture and flow visuals | In progress | Technical lead | Publish final diagram set and screenshot package | +| Validate Entra ID access model and scopes | Open | Technical lead | Confirm least-privilege roles and consent workflow | +| Define data classification and minimization controls | Open | Security or compliance reviewer | Approve allowed fields and retention expectations | +| Complete Responsible AI evidence and guardrail notes | In progress | Technical lead | Map confidence labels and human review checkpoints | +| Complete accessibility validation evidence | Open | Design lead | Capture keyboard, contrast, and screen-reader checks | +| Prepare deployment and support runbook | Open | Technical lead | Add setup, troubleshooting, escalation, and rollback guidance | +| Confirm legal and privacy disclosures | Open | Security or compliance reviewer | Validate publication disclosures and policy language | +| Validate Marketplace packaging structure | Open | Project manager | Ensure metadata, assets, and support contacts are complete | +| Validate Copilot Agent Store package readiness | Open | Technical lead | Ensure agent metadata, instructions, and tenant notes are complete | + +## Workshop exit criteria + +This draft is ready for capstone handoff when the team can answer these questions with evidence. + +* What problem does this solution solve and for whom? +* Which integrations are required now and which are optional later? +* How are trust, security, and human review enforced? +* What is still open before Marketplace and Copilot Agent Store submission? + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/samples/FSI/07-traceability-matrix.md b/docs/getting-started/samples/FSI/07-traceability-matrix.md new file mode 100644 index 0000000000..1f244b41b0 --- /dev/null +++ b/docs/getting-started/samples/FSI/07-traceability-matrix.md @@ -0,0 +1,50 @@ +--- +title: "Traceability Matrix" +description: "Traceability review for the FSI relationship manager" +sidebar_position: 7 +author: Microsoft +ms.date: 2026-08-17 +ms.topic: reference +keywords: + - traceability + - workshop + - relationship manager + - publication readiness +estimated_reading_time: 5 +--- + +## Traceability matrix draft + +This draft links the workshop scenario context and decisions to requirements, experience needs, architecture components, backlog items, test ideas, and publication gates. + +| Source fact or decision | Requirement or need | Experience need | Architecture component | Backlog item | Test or review check | Publication gate | +|-------------------------------------------------------------------------------------------------|------------------------------------|------------------------------------------------------------------------|------------------------------------------------------|-------------------------------------|--------------------------------------------------------------------------------------------|-----------------------------------------------| +| Relationship managers work from fragmented CRM, email, call, transaction, and knowledge sources | FR-01, FR-02, FR-05 | Show a unified account view and prioritized next actions | Retrieval and grounding layer, orchestration service | FEAT-01, STORY-01 | Verify that the first screen presents consolidated context and a clear next action | Technical readiness, data access, packaging | +| The experience must support explainable recommendations | FR-03, FR-05, DAI-02 | Show visible evidence, reasoning, and confidence labels | Insight and recommendation service, governance layer | FEAT-02, STORY-03 | Validate that each recommendation includes evidence and rationale | Responsible AI, trust, and reviewability | +| Human review is required before operational action | DAI-03, NFR-01 | Provide approve, defer, and escalate choices | Action tracking service, governance layer | FEAT-03, STORY-03 | Verify that the workflow supports human decision points before action | Security, privacy, review controls | +| The solution must avoid production credentials, personal data, and sensitive content | C-01, C-02, NFR-03 | Keep the sample experience safe and workshop-friendly | Identity and permissions service, governance layer | FEAT-01, TASK-01 | Confirm that no secrets or production data appear in the sample environment | Privacy, compliance, and data handling | +| The primary user is the relationship manager preparing for a customer conversation | PR-01, BR-01, BR-03 | Support rapid preparation and follow-up during live customer workflows | Experience layer, account workspace UI | FEAT-01, STORY-01 | Validate that the account view supports fast preparation and action capture | User value and marketplace fit | +| Secondary users include team leads, account owners, and reviewers | PR-02, PR-03 | Support prioritization, review, and oversight | Experience layer, governance layer | FEAT-02, STORY-02 | Verify that reviewers can understand the evidence and the chosen next action | Governance and support readiness | +| The first MVP should remain scenario-specific and human-reviewable | C-03, NFR-04 | Keep the experience clear, concise, and reviewable | Experience layer, orchestration service | FEAT-01, FEAT-02 | Review the first-slice scope for clarity and workshop fit | Packaging and launch scope | +| The solution should be publishable later through Marketplace and Copilot Agent Store | Publication readiness requirements | Provide clear value, evidence, and packaging assets | Publish Readiness and support layers | Publication readiness backlog items | Review whether the solution has the required metadata, screenshots, support, and approvals | Marketplace and Agent Store publication gates | + +## Missing links and gaps + +* The sample backlog should explicitly link each story to the related requirement IDs and the publication gate that depends on it. +* The architecture draft should reference the exact evidence and review controls that support each recommendation. +* The publication readiness draft should capture owner names for each remaining gate, especially privacy, support, tax, and offer packaging. +* The workshop output should identify which test or validation activity will prove each requirement before implementation begins. + +## Suggested review questions + +* Which facts or decisions are still unsupported by evidence? +* Which requirements have no clear owner or no mapped backlog item? +* Which publication gates remain unowned or uncertain? +* Which risks need a human decision before the team can proceed to implementation? + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/getting-started/samples/FSI/Relationship Manager for FSI Architecture.jpg b/docs/getting-started/samples/FSI/Relationship Manager for FSI Architecture.jpg new file mode 100644 index 0000000000..d2f4e0a720 Binary files /dev/null and b/docs/getting-started/samples/FSI/Relationship Manager for FSI Architecture.jpg differ diff --git a/docs/getting-started/samples/Retail/01-context-pack.md b/docs/getting-started/samples/Retail/01-context-pack.md new file mode 100644 index 0000000000..4a7f1e6d34 --- /dev/null +++ b/docs/getting-started/samples/Retail/01-context-pack.md @@ -0,0 +1,106 @@ +--- +title: Context Pack Retail +description: Sample context pack for the retail store operations workshop scenario +author: Microsoft +ms.date: 2026-08-17 +ms.topic: reference +keywords: + - sample + - retail + - context pack + - workshop +estimated_reading_time: 5 +--- + +## Platform + +* Platform: Operations Intelligence Platform +* Purpose: Help teams turn operational signals into timely decisions, coordinated actions, and measurable outcomes across business functions. +* Scope: Focus on high-value scenarios that combine data, workflow, and agent-assisted execution. + +## Selected industry scenarios + +* Retail: Store Operations Agent + +## Active scenario + +* Scenario title: Retail Store Operations Agent +* Business problem: Store leaders and operations teams often need to respond quickly to a mix of customer flow, staffing, inventory, and service issues across one or more locations. They may be working from fragmented information spread across point-of-sale data, staffing schedules, inventory systems, incident logs, and team communications. As a result, they can miss early warning signals, delay action, and lose sales or service quality opportunities. +* Core challenges: + * Fragmented store and operational signals across multiple tools + * Manual triage and coordination before action is taken + * Difficulty prioritizing stores, teams, or issues that need attention now + * Limited visibility into customer experience, stock availability, and staffing risks + * Inconsistent follow-through that reduces store performance and customer satisfaction +* Desired outcome: Give store operations teams one trusted view of current store health, emerging issues, and recommended next actions so they can respond faster, coordinate effectively, and protect customer experience and sales outcomes. +* Revenue impact: By surfacing timely, evidence-based recommendations, the organization can reduce missed sales opportunities, improve service levels, protect margin, and support stronger store performance through more proactive operations management. +* User requirements for the product: + * Consolidate store, staffing, inventory, and customer experience signals into a single view + * Highlight the most urgent store issues and the most valuable next actions + * Surface both operational risks and performance opportunities with supporting evidence + * Recommend actions that help store teams improve execution and customer experience + * Support fast follow-up with clear, explainable recommendations that leaders can trust + +## Team + +* PM: +* SME: +* Designer: +* Technical lead: + +## Partner solution framing + +* Target users: + * Primary: Store managers and assistant managers who need to understand store conditions and take timely action. + * Secondary: Regional operations leaders or area supervisors who oversee store execution and prioritization. Open question: Which specific roles should be included in the first release? +* Jobs to be done: + * Understand store conditions quickly before taking action. + * Identify urgent operational issues such as staffing gaps, stock concerns, or service risks. + * Prioritize the most valuable next actions for the store or region. + * Decide what to do next with confidence. +* Business outcomes: + * Improve store execution and customer experience. + * Reduce lost sales from out of stock products, service delays, or missed follow-up. + * Improve team responsiveness and operational consistency. + * Help the organization protect margin and strengthen store performance. +* Measurable success metrics: + * Time to identify a store issue or emerging risk. + * Time to act on the highest-priority recommendation. + * Reduction in service delays, out of stock products, or other operational incidents. + * Improvement in store-level sales, conversion, or customer satisfaction outcomes. + * Open question: What are the target baselines and success thresholds for each metric? +* Stakeholders: + * Store managers and assistant managers as primary users. + * Regional operations leaders who care about execution and store performance. + * Merchandising, people operations, or compliance stakeholders who need clear recommendations. + * Product, design, and technical teams building the experience. + * Open question: Which specific stakeholder groups must approve the solution and how will decisions be made? +* Assumptions: + * The solution will be framed as a scenario-specific experience rather than a one-size-fits-all platform. + * The team will capture the scenario details, assumptions, and open questions in this file before expanding to other industries. + * The product should support explainable recommendations rather than opaque automation. +* Exclusions: + * No market research or competitor claims are included in this framing. + * No production-sensitive customer data or credentials. + * No detailed implementation decisions are assumed at this stage. + +## Open questions + +* Which store or operational signals are most important for this scenario? +* Which actions should be suggested to the store operations team first? +* What evidence or approvals are required before the system recommends a next step? +* Which exact user roles should be included in the target-user definition? +* What success metrics and target values should the team use for the first release? +* Which stakeholders need to review or sign off on the experience? + +## Constraints + +* Do not add credentials, personal data, customer secrets, or production content. +* Keep the content concise, reviewable, and suitable for collaborative workshop use. + +--- + + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, +then carefully refined by our team of discerning human reviewers.* + diff --git a/docs/reference/README.md b/docs/reference/README.md index 324c47b74d..71834bfef7 100644 --- a/docs/reference/README.md +++ b/docs/reference/README.md @@ -18,5 +18,5 @@ This page lists the generated reference documentation, grouped by asset kind. | [Agents](agents/README.md) | 55 | | [Instructions](instructions/README.md) | 57 | | [Prompts](prompts/README.md) | 48 | -| [Skills](skills/README.md) | 72 | +| [Skills](skills/README.md) | 73 | diff --git a/docs/reference/agents/design-thinking/dt-coach.md b/docs/reference/agents/design-thinking/dt-coach.md index 0653fd26cd..81bac8060d 100644 --- a/docs/reference/agents/design-thinking/dt-coach.md +++ b/docs/reference/agents/design-thinking/dt-coach.md @@ -28,15 +28,12 @@ Design Thinking coach guiding teams through the 9-method HVE framework with Thin ## When to use it - Describe the situations where this asset is the right choice, and when to reach for a different asset instead. ## How to use it - Walk through invoking this asset step by step. Remove this section when the asset is not interactive. ## Example usage - Provide a concrete example that shows the asset in action, including representative input and the resulting output. diff --git a/docs/reference/skills/README.md b/docs/reference/skills/README.md index 744cd57038..73bbf83155 100644 --- a/docs/reference/skills/README.md +++ b/docs/reference/skills/README.md @@ -25,6 +25,7 @@ This page lists the generated reference documentation for HVE Core skills. | [ds-evaluation-design](data-science/ds-evaluation-design.md) | Design evaluation datasets and supporting documentation for AI systems and agents, covering the scoping interview, difficulty distribution, dataset contract, sample review, and metric and tooling selection. Use when building or reviewing an evaluation set for a conversational agent, assistant, or retrieval-grounded AI system. | | [ds-feasibility](data-science/ds-feasibility.md) | Author and validate durable data and ML feasibility studies using the Feasibility Study Interchange Profile, constrained YAML authority, UUID URN identity, lifecycle lineage, and evidence traceability. Use when assessing whether available data and technical evidence support a proposed outcome. | | [ml-experimentation](data-science/ml-experimentation.md) | Machine learning experimentation reference for model-experimentation conventions, experiment tracking and reproducibility, dataset and model abstractions, ML engagement fundamentals, and model-production readiness. Use when standing up ML experimentation infrastructure or assessing whether a trained model is ready for production. | +| [ai-discovery-cards](design-thinking/ai-discovery-cards.md) | AI Discovery Cards workshop guidance for Design Thinking for AI Agents ideation after problem framing. | | [dt-coaching-foundation](design-thinking/dt-coaching-foundation.md) | Design Thinking coaching foundation knowledge: coach identity and philosophy, quality and fidelity constraints, method sequencing, coaching state schema, and the canonical deck workflow | | [dt-curriculum](design-thinking/dt-curriculum.md) | Design Thinking learning curriculum covering nine progressive modules across the full Problem, Solution, and Implementation Space methods plus a shared manufacturing reference scenario for teaching and practice | | [dt-methods](design-thinking/dt-methods.md) | Design Thinking method coaching knowledge across all nine methods including per-method techniques, deep expertise, and industry context (energy, financial services, healthcare, manufacturing, nonprofit and social impact, pharmaceuticals and life sciences, professional services, public sector, retail and CPG) | diff --git a/docs/reference/skills/design-thinking/ai-discovery-cards.md b/docs/reference/skills/design-thinking/ai-discovery-cards.md new file mode 100644 index 0000000000..f78e768cdc --- /dev/null +++ b/docs/reference/skills/design-thinking/ai-discovery-cards.md @@ -0,0 +1,31 @@ +--- +title: ai-discovery-cards +description: AI Discovery Cards workshop guidance for Design Thinking for AI Agents ideation after problem framing. +sidebar_position: 1 +ms.date: 2026-08-11 +--- + + +| Field | Value | +|-------------|-----------------------------------------------------| +| Kind | skill | +| Source | `.github/skills/design-thinking/ai-discovery-cards` | +| Invocation | Loaded on demand by referencing agents | +| Interactive | No | + + +## What it does + + +AI Discovery Cards workshop guidance for Design Thinking for AI Agents ideation after problem framing. + + +## When to use it + + +Describe the situations where this asset is the right choice, and when to reach for a different asset instead. + +## Example usage + + +Provide a concrete example that shows the asset in action, including representative input and the resulting output.