dev-create-feature

Implements new Unity C# features using interface-first architecture and layered folder conventions.

Updated Apr 13, 2026
One-click install
npx skills add https://github.com/Unity-UPM-Packages/Antigravity-skills --skill dev-create-feature-unity-upm-packages
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dev-create-feature
Source: https://github.com/Unity-UPM-Packages/Antigravity-skills/tree/main/.agents/skills/dev-create-feature
Command: npx skills add https://github.com/Unity-UPM-Packages/Antigravity-skills --skill dev-create-feature-unity-upm-packages

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Adding new gameplay systems or framework features to a Unity project often leads to tangled MonoBehaviours, duplicated logic, and untestable code. This Skill enforces a structured implementation workflow that separates pure C# logic from Unity engine coupling, keeping features testable and UPM-package-ready. ## Core Features & Use Cases - Layer Classification: Forces an explicit Framework vs Domain decision before coding, applying interface-first design for reusable systems and concrete classes for gameplay logic. - Structured Execution Sequence: Guides implementation through contracts, data models, pure logic, MonoBehaviour view bridges, and dependency wiring via a Bootstrapper, ServiceLocator, or VContainer. - Anti-Pattern Enforcement: Rejects public fields, FindObjectOfType lookups, and logic-in-Update patterns in favor of serialized private fields and event-driven design. - Use Case: When asked to add an inventory system, the Skill produces an IInventorySystem interface, a plain C# InventorySystem implementation, an InventoryView MonoBehaviour bridge, a GameBootstrapper for wiring, and EditMode tests. ## Quick Start Ask the AI to implement a new feature such as an inventory system following the Core-Domain Split architecture with tests.

Frequently Asked Questions about dev-create-feature

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

FAQPage Schema
How do I structure a new feature in a Unity C# project?▼

Classify the feature as Framework or Domain first, then create contracts or concrete classes, plain C# data models, pure logic without MonoBehaviour, a thin view bridge, and a Bootstrapper for wiring. Place files under Scripts/Core, Scripts/Systems, Scripts/Views, and Scripts/Bootstrap.

When should I use interfaces versus concrete classes in Unity?▼

Use interfaces for highly reusable Framework systems like Save, Audio, UI, or Ads. Use concrete classes for game-specific Domain logic such as Grid, Movement, or Weapons, reserving interfaces only when mocking is required for tests.

Do I need a dependency injection framework like VContainer in Unity?▼

No. Start with a manual Bootstrapper MonoBehaviour that constructs and wires systems in Awake. Add a simple ServiceLocator only for cross-scene lookup, and migrate to VContainer only when the Bootstrapper grows beyond roughly 15 systems.

How do I make Unity code testable without MonoBehaviour?▼

Write game logic as plain C# classes with no UnityEngine imports beyond data types, then wrap them in thin MonoBehaviour views that only handle lifecycle and visuals. This allows EditMode tests to cover happy-path and edge-case behavior directly.

Can this architecture be extracted into a UPM package?▼

Yes. Keep the Runtime assembly free of dependencies on frameworks like VContainer or UniRx, providing only the interface and implementation. Consumer projects write their own LifetimeScope or Bootstrapper to register your system.