Uw unity feature scaffold
Skill IdoCohen560/claude-unity-game-studio/unity-ai-workflow/.claude/skills/uw-unity-feature-scaffold
AI-powered Unity game development studio for Claude Code - 49 agents, 120+ skills, and a full studio hierarchy that turns a single AI session into a coordinated game dev team. View more about me in my portfolio.
npx -y skills add IdoCohen560/claude-unity-game-studio --skill uw-unity-feature-scaffoldAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Create a complete feature module with folder structure, Assembly Definition (.asmdef), test assembly, and namespace. Use when adding a new feature, system, or module to a Unity project. Triggers on requests like "create a new feature", "scaffold a module", "add a combat system", "I need a health system", "set up inventory", "create a new module for X", "add a new system", "new feature folder", or any task requiring new folders, assemblies, or namespaces for a gameplay feature — even when the user just names a system they want to build from scratch. Reads ProjectConfig.yaml for folder_strategy and MCP availability.
SKILL.md
5.1 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
Unity Feature Scaffold
Generate a feature module with folders, assembly definitions, and a starter class based on docs/ProjectConfig.yaml.
Before You Start
- Read
docs/ProjectConfig.yamlfor:project_name— derive root namespace by converting to PascalCase (e.g.,"my cool game"→MyCoolGame)folder_strategy—"feature-based"or"type-based"architecture_pattern—"so-first"or"di-first"(informs post-scaffold next steps)mcp.unity_mcp— iftrue, callrefresh_unityafter creating files
- Ask the user for the feature name (PascalCase, e.g.,
Combat,PlayerMovement,Inventory). - Derive the namespace:
{RootNamespace}.{FeatureName}(e.g.,MyCoolGame.Combat). - Confirm the namespace with the user before generating files.
Folder Structures
Feature-based (folder_strategy: "feature-based"):
Assets/_Project/Features/{FeatureName}/
├── Scripts/
│ ├── {RootNamespace}.{FeatureName}.asmdef
│ └── {FeatureName}Manager.cs
├── Data/
└── Tests/
└── {RootNamespace}.{FeatureName}.Tests.asmdef
Type-based (folder_strategy: "type-based"):
Assets/_Project/Scripts/{FeatureName}/
├── {RootNamespace}.{FeatureName}.asmdef
└── {FeatureName}Manager.cs
Assets/_Project/Tests/{FeatureName}/
└── {RootNamespace}.{FeatureName}.Tests.asmdef
Assembly Definition Templates
Feature asmdef
File: {RootNamespace}.{FeatureName}.asmdef
{
"name": "{RootNamespace}.{FeatureName}",
"rootNamespace": "{RootNamespace}.{FeatureName}",
"references": [
"GUID:{CoreAsmdefGUID}"
],
"includePlatforms": [],
"excludePlatforms": [],
"allowUnsafeCode": false,
"overrideReferences": false,
"precompiledReferences": [],
"autoReferenced": true,
"defineConstraints": [],
"versionDefines": [],
"noEngineReferences": false
}
Test asmdef
File: {RootNamespace}.{FeatureName}.Tests.asmdef
{
"name": "{RootNamespace}.{FeatureName}.Tests",
"rootNamespace": "{RootNamespace}.{FeatureName}.Tests",
"references": [
"GUID:{FeatureAsmdefGUID}",
"UnityEngine.TestRunner",
"UnityEditor.TestRunner"
],
"includePlatforms": [
"Editor"
],
"excludePlatforms": [],
"allowUnsafeCode": false,
"overrideReferences": true,
"precompiledReferences": [
"nunit.framework.dll"
],
"autoReferenced": false,
"defineConstraints": [
"UNITY_INCLUDE_TESTS"
],
"versionDefines": [],
"noEngineReferences": false
}
GUID references: Read the GUID from the target .asmdef.meta file (the guid field on line 2). Use GUID: prefix for robustness against renames. Fall back to the string name (e.g., "{RootNamespace}.Core") if the .meta file isn't accessible.
Starter File
File: {FeatureName}Manager.cs
using UnityEngine;
namespace {RootNamespace}.{FeatureName}
{
public class {FeatureName}Manager : MonoBehaviour
{
}
}
This is a minimal entry point. The actual class name and base type should be adjusted to fit the feature — not every feature needs a MonoBehaviour manager.
Cross-Feature References
When Feature B depends on Feature A, add Feature A's asmdef GUID to Feature B's references array. Read the GUID from Feature A's .asmdef.meta file — never modify .meta files directly.
Keep dependencies one-directional. If two features need to communicate bidirectionally, extract shared interfaces or event channels into {RootNamespace}.Core (see uw-scriptable-object-arch for event channel patterns).
After Scaffolding
- Write tests: Use
uw-unity-test-runner— the test asmdef is already configured. - Add architecture patterns: Use
uw-scriptable-object-arch(SO-first) oruw-dependency-injection(DI-first) based onProjectConfig.yaml → architecture_pattern. - Create editor tools: Use
uw-unity-editor-toolsfor custom inspectors or editor windows alongside the feature.
Rules
- All scripts must live inside an
.asmdef. - All paths start with
Assets/_Project/to avoid Asset Store conflicts. - Never create, modify, or delete
.metafiles — Unity generates them automatically. - Asmdef file names use dot notation:
{RootNamespace}.{FeatureName}.asmdef(perNAMING_CONVENTIONS.md). - If
ProjectConfig.yaml → mcp.unity_mcpistrue, callrefresh_unityafter creating files. Otherwise, instruct the user to return to Unity Editor for auto-refresh.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.