mixed-reality

Name: mixed-reality
Author: managedcode

461stars35forks

How to install mixed-reality?

managedcode/dotnet-skills/mixed-reality

$npx -y skills add managedcode/dotnet-skills --skill mixed-reality

Installs into the current project.

Summary

Work on C# and .NET-adjacent mixed-reality solutions around HoloLens, MRTK, OpenXR, Azure services, and integration boundaries where .NET participates in the stack. USE FOR: building or integrating mixed-reality solutions with C#; working on HoloLens, MRTK, Azure mixed-reality se

Files · 1

View on GitHub

SKILL.md

1	# Mixed Reality with .NET
2
3	## Trigger On
4
5	- building or integrating mixed-reality solutions with C#
6	- working on HoloLens, MRTK, Azure mixed-reality services, or OpenXR-related code
7	- reviewing how .NET services support a mixed-reality client
8
9	## Workflow
10
11	1. Acknowledge that much of Microsoft mixed-reality guidance is Unity-centered even when the implementation language is C#; do not pretend it is a standard .NET desktop stack.
12	2. Separate engine-side concerns, device capability concerns, and backend service integration so the system boundary stays understandable.
13	3. Use MRTK and OpenXR guidance intentionally, and verify current toolkit status before choosing a package or template path. See [references/patterns.md](references/patterns.md) for established architecture patterns.
14	4. Treat performance, input, and spatial UX as core constraints, not polish items.
15	5. When .NET mostly lives on the backend for a mixed-reality product, route that backend work through the relevant ASP.NET Core, SignalR, or Azure skill instead of overloading this one.
16	6. Validate with the actual device or emulator path whenever possible because editor-only success is not enough.
17
18	## References
19
20	- [references/patterns.md](references/patterns.md) - MRTK service architecture, OpenXR feature plugins, input action patterns, spatial awareness observers, and cross-cutting patterns for dependency injection, object pooling, and graceful degradation.
21	- [references/examples.md](references/examples.md) - Common HoloLens scenarios including spatial anchors, hand menus, spatial mapping physics, eye tracking, remote rendering, voice commands, QR code tracking, and shared multi-user experiences.
22
23	## Deliver
24
25	- clear boundaries between device code and backend services
26	- mixed-reality guidance grounded in current Microsoft tooling
27	- realistic validation expectations for MR scenarios
28
29	## Validate
30
31	- the chosen toolkit path is current enough for the project
32	- device-specific constraints are explicit
33	- backend and client responsibilities are not blurred

People who liked this also viewed

6 picks

Type

mixed-reality

461stars35forks

View on GitHub

How to install mixed-reality?

managedcode/dotnet-skills/mixed-reality

$npx -y skills add managedcode/dotnet-skills --skill mixed-reality

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Mixed Reality with .NET
2
3	## Trigger On
4
5	- building or integrating mixed-reality solutions with C#
6	- working on HoloLens, MRTK, Azure mixed-reality services, or OpenXR-related code
7	- reviewing how .NET services support a mixed-reality client
8
9	## Workflow
10
11	1. Acknowledge that much of Microsoft mixed-reality guidance is Unity-centered even when the implementation language is C#; do not pretend it is a standard .NET desktop stack.
12	2. Separate engine-side concerns, device capability concerns, and backend service integration so the system boundary stays understandable.
13	3. Use MRTK and OpenXR guidance intentionally, and verify current toolkit status before choosing a package or template path. See [references/patterns.md](references/patterns.md) for established architecture patterns.
14	4. Treat performance, input, and spatial UX as core constraints, not polish items.
15	5. When .NET mostly lives on the backend for a mixed-reality product, route that backend work through the relevant ASP.NET Core, SignalR, or Azure skill instead of overloading this one.
16	6. Validate with the actual device or emulator path whenever possible because editor-only success is not enough.
17
18	## References
19
20	- [references/patterns.md](references/patterns.md) - MRTK service architecture, OpenXR feature plugins, input action patterns, spatial awareness observers, and cross-cutting patterns for dependency injection, object pooling, and graceful degradation.
21	- [references/examples.md](references/examples.md) - Common HoloLens scenarios including spatial anchors, hand menus, spatial mapping physics, eye tracking, remote rendering, voice commands, QR code tracking, and shared multi-user experiences.
22
23	## Deliver
24
25	- clear boundaries between device code and backend services
26	- mixed-reality guidance grounded in current Microsoft tooling
27	- realistic validation expectations for MR scenarios
28
29	## Validate
30
31	- the chosen toolkit path is current enough for the project
32	- device-specific constraints are explicit
33	- backend and client responsibilities are not blurred

People who liked this also viewed

6 picks

Type