StemCode for Unity Developers: AI Coding with C# and real project context.

Give StemCode durable repository instructions before asking it to edit.

Add an AGENTS.md file at the repository root for persistent project instructions. StemCode loads AGENTS.md or .agent/AGENTS.md from the workspace into the model context, so this is the right place for architecture boundaries, generated-file rules, coding conventions, validation expectations, and manual setup notes that should apply across sessions.

# Unity Project Instructions

This is a Unity project.

Important source and configuration paths:
- Assets/Scripts/
- Assets/
- Packages/
- ProjectSettings/
- *.asmdef
- *.cs

Generated or disposable paths — do not modify:
- Library/
- Temp/
- Obj/
- Logs/
- UserSettings/
- Build/
- Builds/

Follow these rules:
- This is a Unity C# project.
- Main gameplay scripts are under Assets/Scripts/.
- Use standard Unity C# conventions.
- Prefer components over large monolithic scripts.
- Do not modify Library/, Temp/, Obj/, Logs/, UserSettings/, or generated build output.
- Do not modify scene or prefab YAML manually unless specifically requested.
- Preserve existing serialized field names unless a rename is intentional.
- Check for Unity lifecycle implications when changing Awake, Start, Update, FixedUpdate, OnEnable, and OnDisable.
- Keep runtime and Editor-only code separated.
- Explain required Inspector setup after creating or changing a component.
- Avoid introducing packages unless they are necessary.
- Use the project's checked-in Unity CLI wrapper or exact Editor version for automated validation.
- After modifying C# code, check for likely Unity compilation errors and run relevant tests.

Validation:
- "<UnityEditor>" -batchmode -projectPath . -runTests -testPlatform EditMode -testResults TestResults/editmode.xml -logFile -
- "<UnityEditor>" -batchmode -projectPath . -runTests -testPlatform PlayMode -testResults TestResults/playmode.xml -logFile -
- Use the same Unity build or test wrapper used by CI when available

Commit the file with the project so the same instructions are reviewable and shared by everyone using StemCode in the repository.

Use repository-aware AI without replacing the tools your stack already needs.

StemCode works best when it can understand the repository around a task, inspect related files, use code intelligence where available, run the project's normal validation commands, and review the final diff before you accept a change.

Install StemCode and open the project root.

Install StemCode separately from Unity, then launch it from the Unity project root. Keep using the Unity Editor for scene authoring, Inspector work, profiling, Play Mode, package management, and platform builds.

cd your-project
stemcode
/init

Keep StemCode at the repository root so project instructions, source, configuration, tests, and Git history are visible from one workspace.

Give the agent Unity source and settings without flooding it with generated files.

A useful Unity workspace includes authored assets, C# code, package manifests, and project settings. Unity also produces large generated directories that usually add noise to repository search.

Assets/Scripts/
Assets/
Packages/
ProjectSettings/
*.asmdef
*.cs

Library/
Temp/
Obj/
Logs/
UserSettings/
Build/
Builds/

Add generated paths to Git ignore rules or .stemcode/.stemcodeignore so repository search stays focused.

Use C# language intelligence alongside Unity-aware repository search.

Unity C# projects benefit from definitions, references, diagnostics, and symbol navigation. A C# language server can complement repository search when gameplay code is spread across assemblies and packages.

/lsp refresh
/lsp

Use the Unity Editor executable as the project CLI.

Unity does not require a separate project CLI package: the Editor executable accepts command-line arguments for unattended imports, tests, custom build methods, and CI. Use the exact Editor version declared by the project and keep its machine-specific path in an environment variable or repository script instead of hard-coding it into prompts.

Replace <UnityEditor> with the Editor executable for the project’s installed Unity version. Keep custom build entry points in Editor code, make them deterministic, and prefer a checked-in wrapper script such as scripts/unity-test or scripts/unity-build so StemCode and CI invoke the same command.

Separate C# implementation from Editor-owned scene and asset work.

Ask StemCode to change scripts and text configuration precisely, then use the Unity Editor for visual authoring and validation. Be cautious with serialized YAML and binary assets.

Use Unity tests and project compilation as the source of truth.

Prefer the checked-in Unity CLI wrapper or CI command used by the project. If none exists yet, start from Unity batch mode and Test Framework commands, then commit a small wrapper so local developers, StemCode, and CI share one validation path.

After C# edits, confirm that Unity imports and recompiles cleanly, then run the smallest relevant Edit Mode or Play Mode tests and exercise the affected scene in the Editor. Build or platform validation should follow the project’s existing automation.

Run the smallest relevant validation first. If it passes, run the broader project checks and review the final diff.

Keep longer-lived architecture context alongside your project instructions.

Use AGENTS.md for concise rules the agent should follow on every task. Keep longer architecture notes, domain context, and workflow references in repository-level StemCode memory so both stay reviewable and versionable.

This is a Unity C# project.
Main gameplay scripts are under Assets/Scripts/.
Use standard Unity C# conventions.
Prefer components over large monolithic scripts.
Do not modify Library/, Temp/, Obj/, Logs/, UserSettings/, or generated build output.
Do not modify scene or prefab YAML manually unless specifically requested.
Preserve existing serialized field names unless a rename is intentional.
Check for Unity lifecycle implications when changing Awake, Start, Update, FixedUpdate, OnEnable, and OnDisable.
Keep runtime and Editor-only code separated.
Explain required Inspector setup after creating or changing a component.
Avoid introducing packages unless they are necessary.
Use the project's checked-in Unity CLI wrapper or exact Editor version for automated validation.
After modifying C# code, check for likely Unity compilation errors and run relevant tests.

Review the change in terms of your stack, not only the generated code.

Ask StemCode to inspect its own diff and check the integration points that are easiest to miss in a repository-wide change.

- Unity lifecycle and execution-order regressions
- lost serialized references or renamed serialized fields
- runtime versus Editor assembly boundaries
- per-frame allocations and unnecessary Update work
- event subscription and cleanup symmetry
- required Inspector or scene setup
- Edit Mode or Play Mode test coverage
- Unity CLI or CI validation results

Common setup questions.

Does Unity have a command-line workflow?

Yes. The Unity Editor executable accepts command-line arguments such as -batchmode, -projectPath, -runTests, -testPlatform, -testResults, and -executeMethod. Use the project’s exact Editor version and preferably wrap the command in a checked-in script.

Can StemCode control the Unity Editor directly?

The normal repository workflow focuses on project files and commands. Direct Editor actions require an appropriate Unity editor integration or MCP tool; keep visual scene and Inspector work in Unity unless such tooling is intentionally connected.

Should Library be indexed?

Usually no. Library is generated and can be very large. Keep Assets, Packages, and ProjectSettings visible and ignore generated Unity directories.

Can it edit scenes and prefabs?

Unity scenes and many prefabs are serialized text when text serialization is enabled, but they are easy to damage with blind edits. Prefer Editor-driven changes unless the repository already reviews those files as source and the requested change is well scoped.

Put StemCode to work in a real repository.

Install StemCode, open the project you already work in, and begin with a repository-understanding task before asking the agent to change code. That gives the model better context and keeps the workflow reviewable.

npm install -g stemcode
cd your-project
stemcode