unity-script-roles

Classify Unity script responsibilities into MonoBehaviour, ScriptableObject, or plain C# services.

Updated Jan 30, 2026
One-click install
npx skills add https://github.com/Rayzerrek/dotfiles --skill unity-script-roles-rayzerrek
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: unity-script-roles
Source: https://github.com/Rayzerrek/dotfiles/tree/main/.pi/agent/skills/unity-skills/skills/script-roles
Command: npx skills add https://github.com/Rayzerrek/dotfiles --skill unity-script-roles-rayzerrek

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps prevent Unity codebases from becoming overly dependent on MonoBehaviour by clarifying which classes should be MonoBehaviour, ScriptableObject, plain C# services, presenters, state nodes, or installers.

Core Features & Use Cases

  • It recommends the most suitable role for each script based on responsibility, dependencies, and runtime needs.
  • It helps split gameplay systems into clearer boundaries so configuration, logic, presentation, and bootstrapping stay separate.
  • It is useful when deciding whether a class should live in Unity-facing code or remain engine-agnostic for easier testing and reuse.

Quick Start

Use this skill to review my Unity classes and tell me the best role for each one with a brief reason.

Frequently Asked Questions about unity-script-roles

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
When should I use a MonoBehaviour versus a plain C# class in Unity?

ScriptableObject is best suited for data configuration, while MonoBehaviour handles runtime gameplay logic. Classifying scripts into the correct role ensures configuration, presentation, and bootstrapping stay separated across your architecture.

How do I decide between MonoBehaviour, ScriptableObject, and installer when planning Unity architecture?

Assign roles based on each class's responsibilities, dependencies, and runtime needs. Installers handle bootstrap concerns, ScriptableObjects manage configuration, and presenters or state nodes split specific gameplay logic boundaries.

How do I split responsibilities across Unity scripts to keep logic engine-agnostic?

Review your classes and assign the most suitable role for each based on its dependencies. Moving gameplay logic to plain C# services or presenters keeps it engine-agnostic for easier testing and reuse outside Unity.

Why does my Unity codebase become overly dependent on MonoBehaviour?

Over-dependency happens when classes lack clear role boundaries. Assigning specific responsibilities to ScriptableObjects, plain C# services, state nodes, or installers prevents MonoBehaviour from absorbing configuration, logic, and bootstrap concerns simultaneously.

Can I use plain C# services and state nodes for Unity gameplay architecture?

Yes, plain C# services and state nodes are recommended for gameplay logic that does not require Unity lifecycle callbacks. This keeps runtime logic engine-agnostic for easier testing and reuse.