Dt Rpi Integration

MicrosoftOfficialPublished by Microsoft

Skill
Guidelines
Agent tooling
MIT
No issues found

From the author

Design Thinking handoff knowledge for research-ready rpi-research inputs and DT-aware rpi-plan, rpi-implement, and rpi-review context

— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill acts as the bridge between Design Thinking coaching and the RPI (Research, Plan, Implement, Review) workflow. It defines the formal handoff contracts, artifact schemas, and contextual framing required to ensure that insights gathered during Design Thinking are effectively utilized by downstream RPI phases. It ensures that regardless of the Design Thinking exit point, all projects enter the RPI pipeline through the research phase with standardized, validated documentation.

What it does

Defines the formal handoff contract for transitioning from Design Thinking to RPI phases.
Provides standardized schemas for documenting handoff artifacts and project constraints.
Offers guidance on framing research, planning, implementation, and review contexts based on DT artifacts.
Includes procedures for subagent dispatch to validate handoff readiness.
Provides specific instructions for generating lo-fi image prompts for concept visualization.

When to use it

When a team graduates from a Design Thinking space boundary and needs to begin the RPI workflow.
When you need to prepare research-ready inputs from completed Design Thinking methods.
When you need to ensure that RPI planning and implementation phases are informed by validated DT context.
When you need to generate neutral, lo-fi concept sketches for stakeholder evaluation.

Advantages

Ensures continuity of project context across different development phases.
Standardizes the quality and format of handoff documentation.
Reduces investigation scope by providing validated artifacts from earlier stages.
Maintains neutrality in visual concept generation through strict prompt enforcement.

Usage examples

“How do I structure the handoff summary when moving from the Problem space to RPI research?”: The agent provides the required YAML schema for the handoff-summary.md file, including fields for exit points, artifacts, and constraint tracking.
“Generate a lo-fi image prompt for a concept where a technician uses a tablet to check inventory.”: The agent generates a prompt following the required stick-figure template, ensuring no personal traits are included and the style is set to black-and-white line art.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/microsoft/dt-rpi-integration/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip dt-rpi-integration.zip -d .agents/skills

Documentation by Microsoft

Design Thinking → RPI Integration — Skill Entry

This skill is the entry point for Design Thinking to RPI integration knowledge.

The DT coach loads these references when Design Thinking coaching graduates into the RPI workflow. Every DT exit produces research-ready input for rpi-research. The retained downstream phases, rpi-plan, rpi-implement, and rpi-review, consume the resulting context. RPI Agent is the lifecycle wrapper when end-to-end coordination is needed; it does not replace rpi-research as the handoff target.

Integration references

Reference	When to load
Handoff contract	Exit points, artifact schemas, RPI input contracts, and quality markers for lateral DT-to-RPI handoff
Space-exit handoffs	Step-by-step Problem, Solution, and Implementation Space exit procedures that compile the handoff summary and the RPI entry document
Research context	DT-aware `rpi-research` framing for handoffs from the DT coach
Planning context	DT-aware `rpi-plan` context for plans originating from DT artifacts
Implement context	DT-aware `rpi-implement` context applying fidelity and stakeholder constraints
Review context	DT-aware `rpi-review` criteria for evaluating Design Thinking artifacts
Subagent handoff	Readiness assessment, artifact compilation, and validation via subagent dispatch
Image prompt generation	Method 5 concept visualization with lo-fi prompt enforcement

Skill layout

SKILL.md — this file (skill entrypoint).
references/ — the DT-to-RPI integration reference documents.
- rpi-handoff-contract.md — DT-to-RPI handoff contract: exit points, artifact schemas, RPI input contracts, and confidence markers.
- space-exit-handoffs.md provides the per-space exit procedures, handoff summaries, transition entries, and RPI entry documents.
- rpi-research-context.md provides DT-aware rpi-research context.
- rpi-planning-context.md provides DT-aware rpi-plan context.
- rpi-implement-context.md provides DT-aware rpi-implement context.
- rpi-review-context.md provides DT-aware rpi-review context.
- subagent-handoff.md provides the subagent dispatch workflow for handoff readiness, compilation, and validation.
- image-prompt-generation.md provides Method 5 lo-fi image prompt generation guidance.

Files

ATTRIBUTION.mdAdded by AutoGineer887 B
LICENSELicence file added by AutoGineer1.1 KiB
SKILL.md3.7 KiB
references/image-prompt-generation.md9.0 KiB
references/rpi-handoff-contract.md7.2 KiB
references/rpi-implement-context.md4.3 KiB
references/rpi-planning-context.md5.8 KiB
references/rpi-research-context.md4.2 KiB
references/rpi-review-context.md6.1 KiB
references/space-exit-handoffs.md17.3 KiB
references/subagent-handoff.md3.3 KiB

references/rpi-planning-context.md

title: 'DT Planning Context' description: Adjustments augmenting rpi-plan when planning artifacts that originated from a Design Thinking process.

When rpi-plan operates on artifacts that originated from a Design Thinking process, these adjustments augment the standard planning workflow. The planning phase does not receive direct DT handoffs; DT context arrives through the rpi-research output. Fidelity constraints, stakeholder coverage, and iteration support shape planning decisions.

Planning Adjustments

Standard Planning	DT-Informed Planning
Production-quality deliverables	Space-appropriate fidelity (rough/scrappy/functional)
Linear phase execution	Iteration-aware phases with return paths to earlier methods
Technical success criteria	Stakeholder-segmented success criteria validated by affected groups
Forward-only validation	Validation incorporating DT coach return triggers
Technical risk focus	Confidence-marker-informed risk assessment (validated/assumed/unknown/conflicting)

DT-Specific Planning Patterns

Use confidence markers (validated, assumed, unknown, conflicting) from the handoff artifact to weight task priority and risk. Items marked unknown or conflicting require resolution steps before downstream implementation. Items marked assumed carry elevated risk; include verification steps or note them as research dependencies for rpi-research to resolve.
Verify stakeholder coverage in each plan phase. All stakeholder groups from the handoff's stakeholder map (an artifact entry of type stakeholder-map in the handoff artifacts array) appear in at least one validation step. When the handoff contains no stakeholder map artifact, flag this gap and recommend updating the handoff before planning proceeds.
Plan phases may include iteration loops that direct work back to an earlier DT method rather than only forward through implementation. Represent return paths as conditional outcomes within a phase's completion criteria (for example, "If core assumptions remain unresolved, return to DT Method 2 for targeted research").
Success criteria match the space in which the planned deliverables will be produced: rough acceptance in Problem Space, scrappy acceptance in Solution Space, functional acceptance in Implementation Space.
Reference DT artifact paths from the handoff in the plan's context section so rpi-implement can trace decisions back to research and synthesis outputs.
For Solution Space plans, enforce anti-polish: scope deliverables to scrappy fidelity and flag production-quality requests as out-of-scope for the current space.

Phase Architecture for DT-Origin Plans

Plans originating from DT handoffs follow this content architecture. This describes the phases of the resulting plan, not a replacement for the rpi-plan workflow.

Phase	Purpose
Context Integration	Consume the DT handoff artifact, verify confidence markers, identify constraints inherited from the originating space, and establish plan-level success criteria aligned with DT exit signals
Implementation	Execute implementation tasks with DT constraints applied. Fidelity tier limits scope, stakeholder map informs acceptance criteria, and `assumed` items carry explicit verification steps
Stakeholder Validation	Validate deliverables against each stakeholder group from the handoff's stakeholder map, using space-appropriate evaluation (rough sketches for Problem Space, scrappy prototypes for Solution Space, functional prototypes for Implementation Space)
DT Reconnection	Assess whether findings warrant returning to DT coaching, document outcomes for potential DT method re-entry, and produce context for the next RPI phase or DT coach return

Return Path Triggers

Recommend returning to DT coaching rather than proceeding to rpi-implement when any of these conditions emerge:

Plan decomposition reveals that core assumptions from the DT synthesis remain unknown or conflicting after research.
Stakeholder validation during planning surfaces groups absent from the original stakeholder map.
Fidelity requirements conflict with the originating space tier, indicating the team may have advanced too quickly through DT methods.
Implementation constraints invalidate the concept or prototype that was validated during DT coaching, requiring a return to Solution Space methods.

These adjustments complement co-loaded instruction files (dt-rpi-handoff-contract, dt-quality-constraints, dt-method-sequencing, dt-rpi-research-context, dt-rpi-review-context): reference their content during planning rather than duplicating it.

All DT coaching artifacts are scoped to .copilot-tracking/dt/{project-slug}/. Never write DT artifacts directly under .copilot-tracking/dt/ without a project-slug directory.

Requirements and compatibility

Written for: GitHub Copilot, Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Claude Code frontmatter

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

Microsoft

Publisher

Microsoft (Official)

Source

microsoft/hve-core · .github/skills/design-thinking/dt-rpi-integration · commit f425e94

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download dt-rpi-integration.zip