agentleFS
Postpartum-genushyacinthus29Postpartum-genushyacinthus29/dotnet-skills/skills/dotnet-mixed-reality/SKILL.md

dotnet-mixed-reality

Skill13 starsChanged 8 months agoMITView on GitHub

Work on C# and .NET-adjacent mixed-reality solutions around HoloLens, MRTK, OpenXR, Azure services, and integration boundaries where .NET participates in the stack.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use MRTK and OpenXR guidance intentionally, and verify current toolkit status before choosing a package or template path.

    line 21
  2. Distinctive:

    Treat performance, input, and spatial UX as core constraints, not polish items.

    line 22
  3. Distinctive:

    When .NET mostly lives on the backend for a mixed-reality product, route that backend work through the relevant ASP.NET Core, SignalR, or …

    line 23

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Mixed Reality with .NET

Trigger On

  • building or integrating mixed-reality solutions with C#
  • working on HoloLens, MRTK, Azure mixed-reality services, or OpenXR-related code
  • reviewing how .NET services support a mixed-reality client

Workflow

  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.
  2. Separate engine-side concerns, device capability concerns, and backend service integration so the system boundary stays understandable.
  3. Use MRTK and OpenXR guidance intentionally, and verify current toolkit status before choosing a package or template path. See references/patterns.md for established architecture patterns.
  4. Treat performance, input, and spatial UX as core constraints, not polish items.
  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.
  6. Validate with the actual device or emulator path whenever possible because editor-only success is not enough.

References

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

Deliver

  • clear boundaries between device code and backend services
  • mixed-reality guidance grounded in current Microsoft tooling
  • realistic validation expectations for MR scenarios

Validate

  • the chosen toolkit path is current enough for the project
  • device-specific constraints are explicit
  • backend and client responsibilities are not blurred

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.