Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问许可证需确认审计通过

unity-reusable-systemsUnity reusable systems 搜索

Agent Skill

unity-reusable-systems 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

306

周安装

13

GitHub Stars

2

下载量

107
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:unity-reusable-systems(Unity reusable systems 搜索)
来源仓库:https://github.com/eyenpi/unity-systems-skills
仓库路径:skills/unity-reusable-systems
安装命令:
npx skills add https://github.com/eyenpi/unity-systems-skills --skill unity-reusable-systems
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/eyenpi/unity-systems-skills --skill unity-reusable-systems

简介

unity-reusable-systems 用于查找、检索和筛选相关信息。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词或任务场景快速定位候选结果。
  • 支持可复用系统设计模式的资源检索。
  • 安装前需确认权限范围、维护状态及是否涉及联网或文件操作。
  • 建议参考原始 README 了解具体应用场景与使用限制。

SKILL.md

Unity Reusable Systems

Build every gameplay system as a self-contained UPM package. Data lives in ScriptableObjects, behavior lives in small single-responsibility MonoBehaviours, and systems talk through SO Event Channels — never direct references.

Target: Unity 6+ / C# 11.

The Rules

ALWAYSNEVER
One system = one UPM packageCreate a "shared contracts" package with interfaces
Data in ScriptableObjects, behavior in MonoBehavioursPut data and behavior in the same class
MonoBehaviour [SerializeField] only for SO refs, component refs, scene refs, UnityEvents[SerializeField] primitives (float, int, bool, string, LayerMask, enum, AnimationCurve) directly on MonoBehaviours — these belong in an SO Config asset
SO Event Channels for cross-system communicationUse singletons, service locators, or static managers
One assembly definition per folder (Runtime, Editor, Tests)Ship without assembly definitions
Version Defines for optional cross-package awarenessUse #if defines without versionDefines in asmdef
Define Constraints for conditional integration assembliesCreate hard dependencies between gameplay packages
Small MonoBehaviours with [RequireComponent]God classes that handle input + logic + rendering
ScriptableVariable for shared runtime statePublic static fields or global state holders
RuntimeSet for tracking active instancesFindObjectsOfType or singleton registries
Awaitable with destroyCancellationToken for asyncCoroutines for new async work
[SerializeReference] for polymorphic serialized dataDeep inheritance hierarchies
Composition: many small components on one GameObjectOne MonoBehaviour doing everything
Interfaces only at package boundaries when SO Events can't solve itInterfaces inside a single package
Tests using ScriptableObject.CreateInstance in Edit ModeSkipping tests because "it's just a SO"
Editor menu item that generates a fully-wired sample sceneShipping a package without a one-click working demo scene
Generate docs/packages/<package-name>.md with full integration surfaceCreate a package without documenting its public events, variables, and interfaces
Read all docs/packages/*.md before designing a new packageDesign a new package without checking what existing packages expose

Where Does This Code Belong?

  • Data or config? → ScriptableObject
  • Needs MonoBehaviour lifecycle? → MonoBehaviour
  • Editor-only tooling? → Editor/ folder (EditorWindow / PropertyDrawer)
  • Pure logic, no Unity deps? → Plain C# class in Runtime/
  • Otherwise → MonoBehaviour

How Should Systems Communicate?

  • Same package, same GameObject/parent-child? → C# event/delegate
  • Same package, different GameObjects? → SO Event Channel
  • Cross-package, sharing runtime state? → ScriptableVariable
  • Cross-package, always installed together? → SO Event Channel
  • Cross-package, optionally installed? → Version Defines + SO Event Channel or bridge package

Integration Discovery

Before designing a new package, read every file in docs/packages/*.md. These documents describe the integration surface of each existing package — their event channels, ScriptableVariables, RuntimeSets, and interfaces.

Discovery steps:

  1. Read all docs/packages/*.md files. If the folder doesn't exist, this is the first package — skip to step 4.
  2. List every event channel, ScriptableVariable, RuntimeSet, and interface from existing packages that is relevant to the new package.
  3. Produce an Integration Plan as part of the new package design:

- Listen to — existing events the new package should subscribe to (via Version Defines) - Publish — new events the new package should raise for others to consume - Read/Write — existing ScriptableVariables the new package should use - Expose — new ScriptableVariables the new package should create for shared state - Implement — existing interfaces the new package should implement - Bridge needed? — whether a Bridge Package is required for complex cross-package logic - Suggested changes to existing packages — checklist of Version Defines, listeners, or asmdef updates other packages could add to become aware of the new package

  1. After building the package, generate docs/packages/<package-name>.md (see Package Integration Doc below).

MonoBehaviour Field Rule

A MonoBehaviour's [SerializeField] fields must only be references — never raw config values.

Allowed on a MonoBehaviour:

  • SO references: config SOs, event channels, ScriptableVariables, RuntimeSets
  • Component / GameObject references (scene wiring)
  • UnityEvents (designer-hookable callbacks)

Belongs in an SO Config asset instead:

  • Primitives and value types: float, int, bool, string, enum
  • Unity structs: LayerMask, Color, AnimationCurve, Vector2/3
  • Arrays/lists of the above

WRONG — config on the component:

public class GroundDetector2D : MonoBehaviour
{
    [SerializeField] private LayerMask groundLayers;   // config!
    [SerializeField] private float boxWidth = 0.9f;    // config!
    [SerializeField] private float castDistance = 0.1f; // config!
}

RIGHT — config in an SO, component holds one reference:

[CreateAssetMenu(menuName = "Platformer2D/Ground Detection Config")]
public class GroundDetectionConfig : ScriptableObject
{
    public LayerMask groundLayers;
    public float boxWidthMultiplier = 0.9f;
    public float castDistance = 0.1f;
}

[RequireComponent(typeof(Collider2D))]
public class GroundDetector2D : MonoBehaviour
{
    [SerializeField] private GroundDetectionConfig config; // one SO ref
}

Core SO Patterns

SO Config

A ScriptableObject holding only serialized fields — designer-tunable settings. Every primitive you'd put on a MonoBehaviour belongs here instead.

[CreateAssetMenu(menuName = "Combat/Weapon Config")]
public class WeaponConfig : ScriptableObject
{
    public float baseDamage = 10f;
    public float critMultiplier = 2f;
    public LayerMask hitLayers;
    public float attackRange = 1.5f;
}

ScriptableVariable<T>

Shared runtime state as an asset. Any component can read/write. Resets on play mode exit.

public abstract class ScriptableVariable<T> : ScriptableObject
{
    [SerializeField] private T initialValue;
    [System.NonSerialized] private T runtimeValue;

    public T Value
    {
        get => runtimeValue;
        set => runtimeValue = value;
    }

    private void OnEnable() => runtimeValue = initialValue;
}

// Concrete types for the serializer:
[CreateAssetMenu(menuName = "Variables/Float")]
public class FloatVariable : ScriptableVariable<float> { }

SO Event Channel

Fire-and-forget broadcast. Publishers and subscribers share an asset reference — never each other.

[CreateAssetMenu(menuName = "Events/Game Event")]
public class GameEvent : ScriptableObject
{
    private readonly List<Action> listeners = new();

    public void Raise()
    {
        for (int i = listeners.Count - 1; i >= 0; i--)
            listeners[i]?.Invoke();
    }

    public void Subscribe(Action listener) => listeners.Add(listener);
    public void Unsubscribe(Action listener) => listeners.Remove(listener);
}

Create one concrete SO per payload type (void, float, int, Vector3, DamageInfo, etc.). Generic SO base classes are not directly serializable — always create concrete leaf types.

GameEventListener

Bridges SO Event Channels to the scene via UnityEvent. Designers wire responses in the Inspector.

public class GameEventListener : MonoBehaviour
{
    [SerializeField] private GameEvent gameEvent;
    [SerializeField] private UnityEvent response;

    private void OnEnable() => gameEvent.Subscribe(OnEventRaised);
    private void OnDisable() => gameEvent.Unsubscribe(OnEventRaised);

    private void OnEventRaised() => response.Invoke();
}

RuntimeSet<T>

Self-registering collection of active instances. Replaces FindObjectsOfType.

public abstract class RuntimeSet<T> : ScriptableObject
{
    private readonly List<T> items = new();
    public IReadOnlyList<T> Items => items;

    public void Add(T item) { if (!items.Contains(item)) items.Add(item); }
    public void Remove(T item) => items.Remove(item);
}

Component Composition

One entity, multiple focused components. Each MonoBehaviour references SOs — never raw config.

[RequireComponent(typeof(HealthComponent))]
public class Mover : MonoBehaviour
{
    [SerializeField] private FloatVariable moveSpeed; // ScriptableVariable
    public void Move(Vector3 direction) =>
        transform.Translate(direction * moveSpeed.Value * Time.deltaTime);
}

public class WeaponController : MonoBehaviour
{
    [SerializeField] private WeaponConfig config;  // SO Config
    [SerializeField] private GameEvent onAttack;    // SO Event Channel
    public void Attack() => onAttack.Raise();
}

Package Structure

com.{company}.{system}/
├── package.json
├── Runtime/
│   ├── {Company}.{System}.asmdef
│   ├── Components/          # MonoBehaviours
│   ├── Data/                # ScriptableObjects (config, definitions)
│   ├── Events/              # SO Event Channels
│   └── Variables/           # ScriptableVariables, RuntimeSets
├── Editor/
│   ├── {Company}.{System}.Editor.asmdef
│   └── SampleSceneGenerator.cs
├── Tests/
│   └── Editor/
│       └── {Company}.{System}.Tests.asmdef
└── Samples~/
    └── BasicUsage/

Runtime asmdef — use versionDefines for optional cross-package awareness:

{
  "name": "MyStudio.Inventory",
  "rootNamespace": "MyStudio.Inventory",
  "references": [],
  "versionDefines": [
    {
      "name": "com.mystudio.crafting",
      "expression": "1.0.0",
      "define": "MYSTUDIO_CRAFTING"
    }
  ]
}

Sample Scene Generator (Required)

Every package must include Editor/SampleSceneGenerator.cs with menu item Tools/{Company}/{System}/Create Sample Scene. The generator must:

  1. Create a new scene
  2. Instantiate all SO assets (config, event channels, variables, runtime sets) into a data folder
  3. Create GameObjects with all components attached
  4. Wire every [SerializeField] — SO references, event channels, variables
  5. Press Play → system works without manual setup

Package Integration Doc

Every package must have a project-level integration doc at docs/packages/<package-name>.md. Generate this as the final step of package creation. If the docs/packages/ directory doesn't exist, create it.

Required sections:

# <package-name> — Integration Surface

## Event Channels

| Event | Payload Type | Raised When | Suggested Listeners |
|-------|-------------|-------------|---------------------|
| `OnX` | `void` / concrete type | Description of trigger | Systems that should react |

## ScriptableVariables

| Variable | Type | Purpose |
|----------|------|---------|
| `VarName` | `FloatVariable` / concrete type | What this variable represents |

## RuntimeSets

| Set | Item Type | Purpose |
|-----|-----------|---------|
| `SetName` | `ComponentType` | What instances this set tracks |

## Interfaces (Package Boundary)

| Interface | Purpose | When to Implement |
|-----------|---------|-------------------|
| `IName` | What contract it defines | When another package should implement it |

## Assembly & Version Define

- **Assembly:** `{Company}.{System}`
- **Package ID:** `com.{company}.{system}`
- **Version Define symbol:** `{COMPANY}_{SYSTEM}`

## Integration Examples

- **SystemA** → listen to `OnX`, do Y
- **SystemB** → read `VarName`, display Z

Omit any section that has no entries (e.g., if the package exposes no interfaces, omit "Interfaces"). Never omit Event Channels or Assembly & Version Define — every package has at least one event and an assembly.

Testing

Test asmdef in Tests/Editor/:

{
  "name": "MyStudio.Inventory.Tests",
  "references": ["MyStudio.Inventory", "UnityEngine.TestRunner", "UnityEditor.TestRunner"],
  "includePlatforms": ["Editor"],
  "overrideReferences": true,
  "precompiledReferences": ["nunit.framework.dll"],
  "testAssemblies": true
}

Create SO instances in code, test, destroy. Never depend on asset files:

[TestFixture]
public class FloatVariableTests
{
    private FloatVariable variable;

    [SetUp]
    public void SetUp() => variable = ScriptableObject.CreateInstance<FloatVariable>();

    [TearDown]
    public void TearDown() => Object.DestroyImmediate(variable);

    [Test]
    public void Value_AfterSet_ReturnsNewValue()
    {
        variable.Value = 42f;
        Assert.AreEqual(42f, variable.Value);
    }
}

Edit Mode unless you need MonoBehaviour lifecycle or physics. Edit Mode tests are faster and more reliable.

New Package Checklist

Before shipping any package, verify:

  • Read all docs/packages/*.md and produce an Integration Plan before designing
  • package.json with correct name, version, unity (6000.0+), displayName
  • Runtime/ with {Company}.{Package}.asmdef — zero external references
  • Editor/ with Editor-only asmdef (if any editor code exists)
  • Tests/Editor/ with test asmdef using overrideReferences and testAssemblies
  • Samples~/ with at least one importable sample
  • Editor menu item under Tools/{Company}/{System}/Create Sample Scene that generates a fully-wired demo scene — all SO assets instantiated, all components on GameObjects, all event channels and variables assigned, playable on first run
  • CHANGELOG.md following SemVer
  • All SOs have [CreateAssetMenu] with organized menu paths
  • All MonoBehaviours use [RequireComponent] where applicable
  • No [SerializeField] primitives on MonoBehaviours — all config in SO assets
  • SO Event Channels for every output event (no direct subscriber lists)
  • ScriptableVariables for any shared runtime state
  • RuntimeSets for any "all active X" queries
  • Version Defines in asmdef for any optional package awareness
  • No FindObjectsOfType, no singletons, no static mutable state
  • Generate docs/packages/<package-name>.md with all events, variables, RuntimeSets, interfaces, and integration examples

Reference Files

For deeper details — extended code, edge cases, and advanced patterns:

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude

32.54%
按下载量换算35

Codex

31.8%
按下载量换算34

Cursor

19.44%
按下载量换算21

Gemini CLI

8.45%
按下载量换算9

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills