Mobile and games
Unity C# rules file
Unity agents love GameObject.Find and LINQ inside Update. This file forbids both, pins the editor version you already have, and keeps tests out of the player build.
Change this stack in the generator
The files
Same rules, wrapped for each tool. Use the file your editor lists. Legacy files are there for older builds.
CursorUse this.cursor/rules/project.mdc
---description: "Project rules for C#, Unity, Unity Test Framework, Unity Package Manager. Generated by RulePaste."alwaysApply: true--- # Project rules Stack: C#, Unity, Unity Test Framework, Unity Package Manager. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - This is a Unity project. Do not run npm, pip, or cargo at the project root.- Add packages in the Package Manager or `Packages/manifest.json`.- Run tests from the Test Runner. Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## C# - Leave nullable reference types enabled. Do not silence the compiler with `!` unless the value was just checked.- Await `Task` and `ValueTask`. No `.Result`, `.Wait()`, or `async void`, except the event shape a framework requires.- Match the file's namespace style. Public members are PascalCase. Private fields match the repo, usually `_camelCase`.- Do not catch `Exception` and ignore it. ## Unity - Target the editor version in `ProjectSettings/ProjectVersion.txt`. Do not upgrade the editor as a side effect.- Wire references with `[SerializeField]`. Do not use `GameObject.Find`, `FindObjectOfType`, or `SendMessage` in new code.- Cache components in `Awake` or `OnEnable`. Do not call `GetComponent` inside `Update`.- No per-frame allocations in `Update` or `FixedUpdate`: no new collections, LINQ, or string concatenation.- Move physics bodies in `FixedUpdate` through the `Rigidbody`. Do not set `transform.position` on a simulated object.- Use the async style already in the project (coroutines, `Awaitable`, or UniTask). Do not add UniTask if it is not installed.- Do not edit generated `.csproj` files or anything under `Library/`, `Temp/`, or `Obj/`. Keep scene YAML edits limited to the objects you meant to change.- Put tests in a test assembly definition, not in a runtime folder that ships in the player. ## Unity Test Framework - Prefer Edit Mode tests for logic. Use Play Mode only when the behavior needs a running scene.- Keep tests in an assembly definition that references the code under test and the test runner. Do not ship tests in the player build.- Create the smallest objects the test needs and clean them up. Do not depend on a scene that the test did not load. ## Unity packages - Add packages through the Package Manager or `Packages/manifest.json`. Do not run npm or pip at the project root.- Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. Install
- Create `.cursor/rules/` in the project root if it does not exist.
- Save this file as `.cursor/rules/project.mdc`. The `.mdc` extension and the frontmatter are required. A plain `.md` file in that folder is ignored.
- Commit it. Open a new Cursor chat. Check Settings, Rules, and confirm the rule is listed as Always Apply.
- Keep a single rule under a few hundred lines. Split later files by topic and set `alwaysApply: false` plus `globs` when a rule is only for some files.
Cursor (legacy)Legacy.cursorrules
# Project rules Stack: C#, Unity, Unity Test Framework, Unity Package Manager. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - This is a Unity project. Do not run npm, pip, or cargo at the project root.- Add packages in the Package Manager or `Packages/manifest.json`.- Run tests from the Test Runner. Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## C# - Leave nullable reference types enabled. Do not silence the compiler with `!` unless the value was just checked.- Await `Task` and `ValueTask`. No `.Result`, `.Wait()`, or `async void`, except the event shape a framework requires.- Match the file's namespace style. Public members are PascalCase. Private fields match the repo, usually `_camelCase`.- Do not catch `Exception` and ignore it. ## Unity - Target the editor version in `ProjectSettings/ProjectVersion.txt`. Do not upgrade the editor as a side effect.- Wire references with `[SerializeField]`. Do not use `GameObject.Find`, `FindObjectOfType`, or `SendMessage` in new code.- Cache components in `Awake` or `OnEnable`. Do not call `GetComponent` inside `Update`.- No per-frame allocations in `Update` or `FixedUpdate`: no new collections, LINQ, or string concatenation.- Move physics bodies in `FixedUpdate` through the `Rigidbody`. Do not set `transform.position` on a simulated object.- Use the async style already in the project (coroutines, `Awaitable`, or UniTask). Do not add UniTask if it is not installed.- Do not edit generated `.csproj` files or anything under `Library/`, `Temp/`, or `Obj/`. Keep scene YAML edits limited to the objects you meant to change.- Put tests in a test assembly definition, not in a runtime folder that ships in the player. ## Unity Test Framework - Prefer Edit Mode tests for logic. Use Play Mode only when the behavior needs a running scene.- Keep tests in an assembly definition that references the code under test and the test runner. Do not ship tests in the player build.- Create the smallest objects the test needs and clean them up. Do not depend on a scene that the test did not load. ## Unity packages - Add packages through the Package Manager or `Packages/manifest.json`. Do not run npm or pip at the project root.- Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. Install
- Save as `.cursorrules` in the project root only if you are on an older Cursor build that still lists this file.
- Current Cursor uses `.cursor/rules/*.mdc`. If you keep both, they will drift unless you regenerate them together.
Claude CodeUse thisCLAUDE.md
# Project rules Stack: C#, Unity, Unity Test Framework, Unity Package Manager. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - This is a Unity project. Do not run npm, pip, or cargo at the project root.- Add packages in the Package Manager or `Packages/manifest.json`.- Run tests from the Test Runner. Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## C# - Leave nullable reference types enabled. Do not silence the compiler with `!` unless the value was just checked.- Await `Task` and `ValueTask`. No `.Result`, `.Wait()`, or `async void`, except the event shape a framework requires.- Match the file's namespace style. Public members are PascalCase. Private fields match the repo, usually `_camelCase`.- Do not catch `Exception` and ignore it. ## Unity - Target the editor version in `ProjectSettings/ProjectVersion.txt`. Do not upgrade the editor as a side effect.- Wire references with `[SerializeField]`. Do not use `GameObject.Find`, `FindObjectOfType`, or `SendMessage` in new code.- Cache components in `Awake` or `OnEnable`. Do not call `GetComponent` inside `Update`.- No per-frame allocations in `Update` or `FixedUpdate`: no new collections, LINQ, or string concatenation.- Move physics bodies in `FixedUpdate` through the `Rigidbody`. Do not set `transform.position` on a simulated object.- Use the async style already in the project (coroutines, `Awaitable`, or UniTask). Do not add UniTask if it is not installed.- Do not edit generated `.csproj` files or anything under `Library/`, `Temp/`, or `Obj/`. Keep scene YAML edits limited to the objects you meant to change.- Put tests in a test assembly definition, not in a runtime folder that ships in the player. ## Unity Test Framework - Prefer Edit Mode tests for logic. Use Play Mode only when the behavior needs a running scene.- Keep tests in an assembly definition that references the code under test and the test runner. Do not ship tests in the player build.- Create the smallest objects the test needs and clean them up. Do not depend on a scene that the test did not load. ## Unity packages - Add packages through the Package Manager or `Packages/manifest.json`. Do not run npm or pip at the project root.- Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. Install
- Save as `CLAUDE.md` in the project root. `.claude/CLAUDE.md` also works if you want the root left clear.
- Commit it. Start a new Claude Code session. The file loads at session start, not in the middle of an old one.
- When the file gets long, move a topic into `.claude/rules/<topic>.md`. Add a `paths` list only if that topic should load for certain files.
Windsurf / DevinUse this.devin/rules/project.md
---trigger: always_ondescription: "Project rules for C#, Unity, Unity Test Framework, Unity Package Manager. Generated by RulePaste."--- # Project rules Stack: C#, Unity, Unity Test Framework, Unity Package Manager. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - This is a Unity project. Do not run npm, pip, or cargo at the project root.- Add packages in the Package Manager or `Packages/manifest.json`.- Run tests from the Test Runner. Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## C# - Leave nullable reference types enabled. Do not silence the compiler with `!` unless the value was just checked.- Await `Task` and `ValueTask`. No `.Result`, `.Wait()`, or `async void`, except the event shape a framework requires.- Match the file's namespace style. Public members are PascalCase. Private fields match the repo, usually `_camelCase`.- Do not catch `Exception` and ignore it. ## Unity - Target the editor version in `ProjectSettings/ProjectVersion.txt`. Do not upgrade the editor as a side effect.- Wire references with `[SerializeField]`. Do not use `GameObject.Find`, `FindObjectOfType`, or `SendMessage` in new code.- Cache components in `Awake` or `OnEnable`. Do not call `GetComponent` inside `Update`.- No per-frame allocations in `Update` or `FixedUpdate`: no new collections, LINQ, or string concatenation.- Move physics bodies in `FixedUpdate` through the `Rigidbody`. Do not set `transform.position` on a simulated object.- Use the async style already in the project (coroutines, `Awaitable`, or UniTask). Do not add UniTask if it is not installed.- Do not edit generated `.csproj` files or anything under `Library/`, `Temp/`, or `Obj/`. Keep scene YAML edits limited to the objects you meant to change.- Put tests in a test assembly definition, not in a runtime folder that ships in the player. ## Unity Test Framework - Prefer Edit Mode tests for logic. Use Play Mode only when the behavior needs a running scene.- Keep tests in an assembly definition that references the code under test and the test runner. Do not ship tests in the player build.- Create the smallest objects the test needs and clean them up. Do not depend on a scene that the test did not load. ## Unity packages - Add packages through the Package Manager or `Packages/manifest.json`. Do not run npm or pip at the project root.- Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. Install
- Create `.devin/rules/` and save this file as `.devin/rules/project.md`. Devin Desktop (formerly Windsurf) prefers this path. `.windsurf/rules/` still works as a fallback.
- `trigger: always_on` loads it in every chat. Keep the file under 12,000 characters or it can be truncated with no error.
- Commit it and start a new chat. If you also keep `.windsurfrules`, make sure the two files do not disagree.
Windsurf (legacy)Legacy.windsurfrules
# Project rules Stack: C#, Unity, Unity Test Framework, Unity Package Manager. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - This is a Unity project. Do not run npm, pip, or cargo at the project root.- Add packages in the Package Manager or `Packages/manifest.json`.- Run tests from the Test Runner. Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## C# - Leave nullable reference types enabled. Do not silence the compiler with `!` unless the value was just checked.- Await `Task` and `ValueTask`. No `.Result`, `.Wait()`, or `async void`, except the event shape a framework requires.- Match the file's namespace style. Public members are PascalCase. Private fields match the repo, usually `_camelCase`.- Do not catch `Exception` and ignore it. ## Unity - Target the editor version in `ProjectSettings/ProjectVersion.txt`. Do not upgrade the editor as a side effect.- Wire references with `[SerializeField]`. Do not use `GameObject.Find`, `FindObjectOfType`, or `SendMessage` in new code.- Cache components in `Awake` or `OnEnable`. Do not call `GetComponent` inside `Update`.- No per-frame allocations in `Update` or `FixedUpdate`: no new collections, LINQ, or string concatenation.- Move physics bodies in `FixedUpdate` through the `Rigidbody`. Do not set `transform.position` on a simulated object.- Use the async style already in the project (coroutines, `Awaitable`, or UniTask). Do not add UniTask if it is not installed.- Do not edit generated `.csproj` files or anything under `Library/`, `Temp/`, or `Obj/`. Keep scene YAML edits limited to the objects you meant to change.- Put tests in a test assembly definition, not in a runtime folder that ships in the player. ## Unity Test Framework - Prefer Edit Mode tests for logic. Use Play Mode only when the behavior needs a running scene.- Keep tests in an assembly definition that references the code under test and the test runner. Do not ship tests in the player build.- Create the smallest objects the test needs and clean them up. Do not depend on a scene that the test did not load. ## Unity packages - Add packages through the Package Manager or `Packages/manifest.json`. Do not run npm or pip at the project root.- Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. Install
- Save as `.windsurfrules` in the project root if your build still asks for that filename.
- This file is always on and cannot be scoped. Prefer `.devin/rules/project.md` on current builds.
GitHub CopilotUse this.github/copilot-instructions.md
# Project rules Stack: C#, Unity, Unity Test Framework, Unity Package Manager. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - This is a Unity project. Do not run npm, pip, or cargo at the project root.- Add packages in the Package Manager or `Packages/manifest.json`.- Run tests from the Test Runner. Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## C# - Leave nullable reference types enabled. Do not silence the compiler with `!` unless the value was just checked.- Await `Task` and `ValueTask`. No `.Result`, `.Wait()`, or `async void`, except the event shape a framework requires.- Match the file's namespace style. Public members are PascalCase. Private fields match the repo, usually `_camelCase`.- Do not catch `Exception` and ignore it. ## Unity - Target the editor version in `ProjectSettings/ProjectVersion.txt`. Do not upgrade the editor as a side effect.- Wire references with `[SerializeField]`. Do not use `GameObject.Find`, `FindObjectOfType`, or `SendMessage` in new code.- Cache components in `Awake` or `OnEnable`. Do not call `GetComponent` inside `Update`.- No per-frame allocations in `Update` or `FixedUpdate`: no new collections, LINQ, or string concatenation.- Move physics bodies in `FixedUpdate` through the `Rigidbody`. Do not set `transform.position` on a simulated object.- Use the async style already in the project (coroutines, `Awaitable`, or UniTask). Do not add UniTask if it is not installed.- Do not edit generated `.csproj` files or anything under `Library/`, `Temp/`, or `Obj/`. Keep scene YAML edits limited to the objects you meant to change.- Put tests in a test assembly definition, not in a runtime folder that ships in the player. ## Unity Test Framework - Prefer Edit Mode tests for logic. Use Play Mode only when the behavior needs a running scene.- Keep tests in an assembly definition that references the code under test and the test runner. Do not ship tests in the player build.- Create the smallest objects the test needs and clean them up. Do not depend on a scene that the test did not load. ## Unity packages - Add packages through the Package Manager or `Packages/manifest.json`. Do not run npm or pip at the project root.- Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. Install
- Create `.github/` if needed and save this file as `.github/copilot-instructions.md`.
- Commit it. Copilot picks up repository instructions for Chat and, on supported plans, code review and the cloud agent.
- For rules that should only affect some files, add `.github/instructions/<name>.instructions.md` with `applyTo` frontmatter instead of growing this file.
Codex + AGENTS.mdAGENTS.md
# Project rules Stack: C#, Unity, Unity Test Framework, Unity Package Manager. Follow these rules on every task. If a rule disagrees with existing code, match the code and mention the difference. If a rule disagrees with a direct user instruction, follow the user. ## Working agreement - Read the files you will change before editing them. Do not invent the project layout from memory.- Change only what the task needs. No drive-by refactors, renames, or formatting of untouched lines.- Match the patterns already in the repo over a generic style guide.- Do not add dependencies, config files, or abstractions the task did not ask for.- Do not commit secrets, and do not paste `.env` values, tokens, or private keys into code or chat.- If a requirement is ambiguous, choose the smallest reading, state that assumption, and continue. ## Commands - This is a Unity project. Do not run npm, pip, or cargo at the project root.- Add packages in the Package Manager or `Packages/manifest.json`.- Run tests from the Test Runner. Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## C# - Leave nullable reference types enabled. Do not silence the compiler with `!` unless the value was just checked.- Await `Task` and `ValueTask`. No `.Result`, `.Wait()`, or `async void`, except the event shape a framework requires.- Match the file's namespace style. Public members are PascalCase. Private fields match the repo, usually `_camelCase`.- Do not catch `Exception` and ignore it. ## Unity - Target the editor version in `ProjectSettings/ProjectVersion.txt`. Do not upgrade the editor as a side effect.- Wire references with `[SerializeField]`. Do not use `GameObject.Find`, `FindObjectOfType`, or `SendMessage` in new code.- Cache components in `Awake` or `OnEnable`. Do not call `GetComponent` inside `Update`.- No per-frame allocations in `Update` or `FixedUpdate`: no new collections, LINQ, or string concatenation.- Move physics bodies in `FixedUpdate` through the `Rigidbody`. Do not set `transform.position` on a simulated object.- Use the async style already in the project (coroutines, `Awaitable`, or UniTask). Do not add UniTask if it is not installed.- Do not edit generated `.csproj` files or anything under `Library/`, `Temp/`, or `Obj/`. Keep scene YAML edits limited to the objects you meant to change.- Put tests in a test assembly definition, not in a runtime folder that ships in the player. ## Unity Test Framework - Prefer Edit Mode tests for logic. Use Play Mode only when the behavior needs a running scene.- Keep tests in an assembly definition that references the code under test and the test runner. Do not ship tests in the player build.- Create the smallest objects the test needs and clean them up. Do not depend on a scene that the test did not load. ## Unity packages - Add packages through the Package Manager or `Packages/manifest.json`. Do not run npm or pip at the project root.- Do not commit `Library/`, `Temp/`, `Obj/`, `Logs/`, or `UserSettings/`. ## Testing expectations - When you fix a bug, add a test that fails before the fix and passes after, in the repo's current test style.- When you change behavior a caller can observe, update or add a test for that behavior.- Do not test private helpers, framework internals, or third-party libraries. ## Code style - Keep strict type and lint settings on. Do not weaken them to get a green build.- No new `any`, and no empty catch blocks. Prefer `unknown` and narrowing. Handle every fallible call.- Give exported functions an explicit type when the inferred type is not obvious.- Follow the repo formatter. Do not hand-format files the formatter owns.- Do not add comments that restate the code.- Comment only a constraint, invariant, or tradeoff the code itself cannot show.- No file-header banners and no changelog comments. ## Safety - Never commit `.env`, keystores, or credential files. When a new variable is required, add an empty placeholder to the example env file.- Do not disable authentication, authorization, or TLS checks to make a test pass.- Do not force-push, `reset --hard`, drop a database, or delete a directory tree unless the user asked for that exact action.- Do not edit vendored or generated output (`node_modules`, `dist`, `.next`, `vendor`, `Library`, `.godot`). Change the source and regenerate. ## Done when - The change does what was asked and nothing extra.- New or changed behavior is covered at the level in Testing expectations.- The commands in this file that apply to the touched files have been run, or you say which command you could not run.- The diff has no unrelated files, lockfile churn, or secrets. Install
- Save as `AGENTS.md` in the project root. Codex, Cursor, Copilot CLI, Devin, and many other agents look for this name.
- The file is plain Markdown. Do not add frontmatter.
- In a monorepo, add a nested AGENTS.md next to a service that needs different commands. Do not leave an empty `AGENTS.override.md` beside it. Codex treats that empty file as the instructions for the folder.
- Commit it and start a new agent session.
What each section does
Working agreement
The habits that keep an agent from rewriting the repo while it solves a small task.
Commands
The install, dev, test, and lint commands for this stack, so the agent runs the project's tools instead of guessing.
C#
Nullable reference types and async that is actually awaited.
Unity
Keeps gameplay code out of Find and Update allocations, and keeps generated project files untouched.
Unity Test Framework
Edit Mode tests in their own assembly, with Play Mode only when a scene is required.
Unity packages
Adds Unity packages the way the editor expects.
Testing expectations
How much test coverage this project wants from the agent, separate from which test runner is installed.
Code style
How strict the types, lint, and comments should be. This is the knob most people actually want to change.
Safety
Hard stops: secrets, destructive git commands, and generated folders.
Done when
The checklist the agent should satisfy before it calls the task finished.
Questions
Does this upgrade my Unity editor?
No. The rule says to target the version in ProjectSettings/ProjectVersion.txt and not to upgrade it as a side effect.
Where do tests go?
In an assembly definition referenced by the test runner, not in a runtime folder that is included in the player.
Related stacks
Newsletter
Stack notes, occasionally
A short email when a tool changes its rules filename or a new stack page ships. No product drip. If this form is not connected yet, your address is not stored.