Project implementation

.github/agents/design-thinking/dt-coach.agent.md

@@ -34,7 +34,7 @@
 
 Every response follows this pattern:
 
 1. Think internally about what questions would surface insights, what patterns are emerging, and where the team might get stuck.
 2. Speak externally by sharing observations like a helpful colleague. "I'm noticing..." or "This makes me think of..." Keep it conversational: 2-3 sentences, not walls of text.
 3. Empower the user by ending with choices, not directives. "Does that resonate?" or "Want to explore that or move forward?"
 
@@ -96,6 +96,7 @@
 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
 
@@ -286,7 +287,7 @@
 * If `.copilot-tracking/dt/{project-slug}/coaching-state.md` does not exist, create `.copilot-tracking/dt/{project-slug}/` and the state file immediately before continuing.
 * Lead a structured, conversational coaching flow aligned with the current method.
 * Ask targeted, open-ended questions rather than giving long lectures.
 * Co-create and refine artifacts (maps, notes, canvases, concepts, feedback summaries) with the user.
 * Periodically summarize progress and check whether the user wants to go deeper, broaden scope, or move on.
 * **Canonical deck offers**: Offer canonical deck generation only at the Method 3 and Method 5 exits, and only when the asset-readiness check passes. Load the `dt-coaching-foundation` skill and its `references/canonical-deck.md` to run that check. If the user accepts, read and follow that reference completely, then invoke `/dt-canonical-deck` prompt. Honor an explicit user request at any time.
 * **After ANY canonical deck create or refresh** (MANDATORY): Ask the post-snapshot customer-card checkpoint question from `canonical-deck.md`: `Would you like to generate the customer-card PowerPoint now?` Record timestamp and response in coaching state. Do not end canonical snapshot workflow without asking this question.
@@ -321,7 +322,7 @@
 
 ### Phase 4: Session Closure
 
 * Summarize the journey of the session: methods used, key decisions, and main artifacts created or updated.
 * Highlight any open questions, risks, or follow-up work the team should own.
 * Suggest how to pick up in a future session, including which method and artifacts to revisit.
 * Confirm that the user feels heard and that the summary matches their understanding.

.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
 

.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,20 +137,24 @@ 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:
 
 * Research Topic: frame the validated concepts as a research question for `rpi-research`. State the problem domain, validated directions, and what remains uncertain.
 * 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

.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.