Dt Coaching Foundation

title: 'DT Canonical Deck Instructions' description: Optional canonical deck and customer-card slide-content workflow for Design Thinking teams, offered on request or once DT work has produced renderable assets.

Use this workflow when the team requests canonical deck support, or when it accepts an automatic offer at an eligible method exit.

Scope

Canonical deck workflow covers two related outputs:

1. Canonical markdown artifacts under .copilot-tracking/dt/{project-slug}/canonical/.

2. Optional customer-card slide content (content.yaml) under .copilot-tracking/dt/{project-slug}/render/.

Treat canonical deck and customer-card generation as optional and skippable at each offer point. An HTML presentation is a separate explicit handoff to hve-slides, not an automatic part of YAML generation. No PPTX build is available.

Single Source of Truth

Keep canonical-deck rules in this file only.

Do not duplicate transition gates or non-waivable checks in:

• Method instructions (for example Method 1 or sequencing)

• DT Coach agent behavior text

• Other DT skill references

Activation Rule

Canonical deck and customer-card generation is available on request at any time, and is offered automatically only once the DT work has produced content worth capturing.

Do not ask about this workflow during session initialization, at the end of Method 1, or at the end of Method 2. Those points produce scope and raw research, not the validated content the canonical artifacts require, so an offer there asks the team to decide about rendering before there is anything to render.

The workflow is active when either condition is true:

1. The user asks for canonical deck or customer cards.

2. The user accepts an automatic offer at an eligible method exit.

Until then, continue normal DT coaching with no canonical-deck enforcement.

Offer Points (Optional)

Offer canonical deck snapshot creation or refresh at these method exits, and only when the asset-readiness check below passes:

1. End of Method 3

2. End of Method 5

Method 3 produces validated problem definitions and synthesized themes; Method 5 produces selected concepts. Both give the canonical artifacts real content to draw from.

Each offer is optional and skippable. Declining must not block a method transition.

Asset-Readiness Check

Before making an automatic offer, confirm the project has DT method outputs that map to at least one supported canonical artifact type. When it does not, make no offer and continue coaching. An explicit user request is always honored regardless of this check; when assets are thin, say what is missing and let the user decide.

Mandatory Post-Snapshot Customer-Card Checkpoint

After any canonical deck create or refresh, the coach must ask this yes-or-no question in the same turn:

Would you like to generate the customer-card slide content now?

This checkpoint is required whenever canonical artifacts were created or updated at the Method 3 or Method 5 offer points, or at an explicit user request.

Do not end canonical snapshot workflow without asking this question.

Record the offer timestamp and user response in coaching state.

Customer-Card Re-Offer Rules

If the user declines the customer-card offer:

• If the decline happens before Method 5: do not re-offer until the Method 5 exit checkpoint.

• At the Method 5 exit checkpoint: ask one final customer-card question before the transition to Method 6: "We're finishing up Method 5. Before we move to prototyping, would you like to generate the customer-card slide content now?"

• If the decline happens at Method 5 (first or second decline): do not re-offer again in the current DT run; continue to implementation methods.

Record all offers and responses in coaching state for audit and session recovery.

Offer Language

Use concise coaching language. Example:

We can snapshot the canonical deck now so your current artifacts are easier to track and share. Want to do that now or skip for later?

If the team declines, continue without additional commentary.

Validation Checklist (When Workflow Is Active)

Before generating or refreshing canonical deck content, run this checklist:

1. Confirm project scope path exists: .copilot-tracking/dt/{project-slug}/.

2. Resolve canonical directory as .copilot-tracking/dt/{project-slug}/canonical/.

3. Confirm canonical source artifacts available from DT method outputs. When none map to a supported artifact type, stop and tell the user what is missing.

4. Detect create vs refresh mode:

   • create: no canonical entries exist yet

   • refresh: canonical entries already exist

5. If refreshing, compute artifact fingerprints and update only changed or new entries.

6. Record snapshot metadata in coaching state for the current method checkpoint when generated.

7. Ask the mandatory post-snapshot customer-card checkpoint question.

8. Record the offer timestamp and user response in coaching state.

9. If requested, proceed to the customer-card slide-content branch.

Canonical Artifact Model

Canonical deck entries are maintained in place under:

.copilot-tracking/dt/{project-slug}/canonical/
├── vision-statement.md
├── problem-statement.md
├── scenarios/
├── use-cases/
└── personas/

Use existing Design Thinking evidence and avoid speculative content.

Required Vision Statement Sections

Every vision-statement entry must include:

1. Title from frontmatter title, or first heading if no frontmatter title exists

2. ## Vision Statement — Concise articulation of what the team wants to achieve or create, written as a goal statement from the team's perspective

3. ### Why This Matters — Business value, strategic importance, and stakeholder impact of the vision. Explain what problems this vision solves and what opportunities it enables

If information is missing, use <insufficient knowledge> and add #### Questions to Ask with 2-5 targeted questions.

Required Problem Statement Sections

Every problem-statement entry must include:

1. Title from frontmatter title, or first heading if no frontmatter title exists

2. ## Problem Statement — Exactly one sentence using this required generator framework:

   The [root cause] is producing an [undesirable effort] for [who it impacts]. How might we do [opportunity] so that we can provide [benefits]?

   Framework enforcement requirements:

   • Replace all bracketed placeholders with concise, evidence-grounded content from available DT artifacts

   • Do not leave bracketed placeholders in final canonical output

   • Keep each replacement brief and specific; avoid generic filler

   • Preserve the sentence structure and punctuation pattern of the framework

   • If any required component is unknown, use <insufficient knowledge> in that component position

If information is missing, use <insufficient knowledge> and add #### Questions to Ask with 2-5 targeted questions.

Required Scenario Sections

Every scenario entry must include:

1. ### Description — Short customer-facing overview of the scenario (2-3 sentences). Set the context: who is involved, what is happening, and why it matters

2. ### Scenario Narrative — People-centered story grounded in actual research. Clearly articulate business value being unlocked, describe the stakeholders/users and what they care about, explain their challenges and what they are trying to accomplish, and show what success looks like

3. ### How Might We — Opportunity framing that captures what the team could explore. Address the business value, stakeholders, potential solutions space, and what unlocking this scenario would enable

If information is missing, use <insufficient knowledge> and add #### Questions to Ask with 2-5 targeted questions.

Required Use Case Sections

Every use case entry must include all required subsections in this exact order:

1. ### Use Case Description — Short narrative describing what the use case is about (1-2 sentences)

2. ### Use Case Overview — Detailed explanation of the use case including context, actors, and what they are trying to accomplish

3. ### Business Value — What value is delivered by this use case? Who benefits (user, organization, customer)? What outcomes or metrics matter?

4. ### Primary User — Who is the main actor in this use case? Describe their role, goals, and constraints

5. ### Secondary User — Who else interacts with or is affected by this use case?

6. ### Preconditions — What must be true before this use case can start? What state or data must exist?

7. ### Steps — Numbered sequence of actions the user takes and the system's responses. Be precise about the interaction flow

8. ### Data Requirements — What information or data is needed for this use case to work? What data is created or modified?

9. ### Equipment Requirements — What tools, devices, or systems does the user need to accomplish this use case?

10. ### Operating Environment — Where and when does this use case happen? What are the environmental constraints (noise, lighting, accessibility, connectivity)?

11. ### Success Criteria — How do we know when this use case succeeds? What are the measurable outcomes or user satisfaction signals?

12. ### Pain Points — What challenges, frustrations, or inefficiencies exist in the current execution of this use case?

13. ### Extensions — What variations or alternative paths exist? When would they be used?

14. ### Evidence — What research, data, or user quotes support this use case? Reference the source DT method artifacts

If information is missing, use <insufficient knowledge> and add #### Questions to Ask with 2-5 targeted questions.

Required Persona Sections

Every persona entry must include:

1. ### Description — Who is this person? Include demographic context (role, organization type, experience level), what they do, and why they matter to the project

2. ### User Goal — What is this person trying to accomplish? What is their primary objective or desired outcome?

3. ### User Needs — What do they need to achieve their goal? Distinguish between explicit needs (what they ask for) and latent needs (what they actually need to succeed)

4. ### User Mindset — How do they think about their work? What are their mental models, priorities, frustrations, and decision-making patterns? What assumptions do they hold?

If information is missing, use <insufficient knowledge> and add #### Questions to Ask with 2-5 targeted questions.

Customer Card Slide-Content Branch

When the team requests customer cards, accepts a generation offer, or accepts the mandatory post-snapshot checkpoint:

1. Activate the customer-card-render skill by name and run its generation command with --canonical-dir set to .copilot-tracking/dt/{project-slug}/canonical and --output-dir set to .copilot-tracking/dt/{project-slug}/render/content.

2. Report the canonical artifact path and the generated content.yaml directory.

3. If the user asks for a presentation, offer the hve-slides HTML workflow using reviewed YAML as authoring input. Resolve the skill by name and preserve canonical text, order and source labels. Keep rendering separate from canonical/YAML generation; report missing renderer or validation evidence instead of guessing a pipeline. For levelled HTML/MP4 demo material, use hve-demo-material and its references/slide-content.md input contract. A PPTX request cannot be satisfied by claiming HTML is PPTX.

Generation Outcome

• Do not run pip install or install dependencies manually. Rely on the customer-card-render skill's documented prerequisites.

• Keep generated output under .copilot-tracking/dt/{project-slug}/render/.

• When generation fails, do not retry or troubleshoot on your own. Report the cause in plain language and offer to re-run generation from the same canonical artifacts.

• When the customer-card-render skill is unavailable, say so and stop rather than reimplementing its mapping here.

Method 5 Auto-Generate

If the team completes Method 5 and the asset-readiness check passes, ask whether to create or update canonical deck and customer card artifacts. If accepted, generate a final canonical deck refresh and then offer customer-card generation.

Coaching State Expectations

When canonical workflow is active, maintain canonical state fields in coaching state for:

• Snapshot status and timestamp for offered checkpoints

• Entry counts and candidate counts when generated

• Fingerprints for staleness detection

• Last offered and last generated customer-card snapshot keys

If the team does not opt in, these fields are optional and should not gate progress.