Unity Level Design Patterns skill.

• Outcome: Review
• Latest audit: Sep 10, 2026 · 11:47 PM UTC
• Version: 0.1.0

Overview

The skill is a Unity level-design helper, but its editor scripts can silently delete or overwrite existing scene work without confirmation or undo support.

Review this skill before installing into a real Unity project. Use it first in a disposable scene or a version-controlled branch, because its menu commands can remove existing lights, reflection probes, baked lighting, Player objects, and terrain data without a confirmation dialog or reliable Undo support.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (4)

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/LightingSetup.cs:17
• Finding: Overbroad and Irreversible Lighting Object Deletion## Vulnerability Details **File Location**: `scripts/LightingSetup.cs`, lines 17-28 **Vulnerability Type**: Unsafe destructive editor operation **Risk Level**: Medium ### Vulnerable Code ```csharp // Remove all lights var lights = Object.FindObjectsOfType<Light>(); foreach (var light in lights) { if (light.gameObject.name.Contains("Sun") || light.gameObject.name.Contains("Light")) Object.DestroyImmediate(light.gameObject); } // Remove reflection probes var probes = Object.FindObjectsOfType<ReflectionProbe>(); foreach (var probe in probes) Object.DestroyImmediate(probe.gameObject); ``` ### Technical Analysis `ClearAllLighting` permanently deletes complete GameObjects using `Object.DestroyImmediate` without registering the operation with Unity's Undo system or requesting user confirmation. Light selection is based on broad, case-sensitive substring matching against `"Sun"` and `"Light"`, rather than verifying that an object was created and is owned by this tool. The method also deletes every discovered reflection-probe GameObject without any ownership check. Because the entire GameObject is destroyed, unrelated components, scripts, children, and project-specific configuration attached to matching objects are removed as well. This is an unsafe editor-coding practice rather than privilege escalation: the command operates with the permissions of the Unity Editor user and does not obtain additional system privileges. ### Attack Path 1. A scene contains customized light objects whose names include `"Sun"` or `"Light"`, or contains reflection probes. 2. Those GameObjects contain valuable components, child objects, or scene configuration unrelated to this skill. 3. The user invokes `Level Design/Lighting/Clear Lighting`, either directly or as part of a workflow. 4. The method scans the scene and immediately destroys all matching light GameObjects and all reflection-probe GameObjects. ...[truncated 603 chars]
• Remediation: ## Remediation Suggestions - Replace `Object.DestroyImmediate` with `Undo.DestroyObjectImmediate` for editor-initiated deletion. - Require explicit confirmation before bulk removal, using `EditorUtility.DisplayDialog`. - Track tool-created objects with a dedicated marker component, stable identifier, or parent hierarchy. - Delete only objects proven to be owned by the tool rather than relying on name substrings. - Consider removing only the intended `Light` or `ReflectionProbe` component when deleting the complete GameObject is unnecessary. - Register all created replacement objects with `Undo.RegisterCreatedObjectUndo`. - Mark the affected scene dirty and document the exact deletion scope before execution.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/SceneSetupWizard.cs:142
• Finding: Scene Setup Irreversibly Deletes All Existing Directional Lights## Vulnerability Details **File Location**: `scripts/SceneSetupWizard.cs`, lines 142-148 **Vulnerability Type**: Unsafe destructive editor operation **Risk Level**: Medium ### Vulnerable Code ```csharp // Clear existing lights var existingLights = Object.FindObjectsOfType<Light>(); foreach (var light in existingLights) { if (light.type == LightType.Directional) Object.DestroyImmediate(light.gameObject); } ``` ### Technical Analysis The scene-setup workflow removes every discovered directional-light GameObject before creating its own light. It does not distinguish tool-generated lights from user-created or package-managed lights. The use of `Object.DestroyImmediate` bypasses Unity Undo registration, and no confirmation or preview of affected objects is presented. Destruction applies to the complete GameObject, not only its `Light` component. Consequently, other components and child objects attached to a directional-light object may also be lost. The operation exceeds the minimum modification necessary to configure scene lighting. ### Attack Path 1. A Unity scene contains one or more customized directional-light GameObjects. 2. A directional-light GameObject also contains project-specific components, scripts, metadata, or children. 3. The user invokes a quick scene-setup command that calls `SetupLighting`. 4. The method discovers every active directional light and destroys each complete GameObject immediately. 5. A replacement light is created, but the deleted custom configuration and attached objects are not preserved. 6. The user cannot reliably reverse the deletion through Unity Undo because the operation was not registered. ### Impact Assessment The issue may destroy all active directional-light objects and any associated components or hierarchy in the open scene. The scope is the Unity scene available to the current editor process. No additional privileges are acquired, but project i ...[truncated 44 chars]
• Remediation: ## Remediation Suggestions - Use `Undo.DestroyObjectImmediate` instead of `Object.DestroyImmediate`. - Restrict removal to directional lights created by this tool, identified through a marker component or tracked hierarchy. - Prompt the user before replacing existing lighting and list the number of objects that will be affected. - Prefer modifying or disabling an existing suitable directional light rather than deleting its GameObject. - If only the light must be removed, preserve the GameObject and unrelated attached components. - Register newly created lights through `Undo.RegisterCreatedObjectUndo`. - Group replacement operations into a single Unity Undo group so the complete setup can be reverted atomically.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/SceneSetupWizard.cs:211
• Finding: Scene Wizard Irreversibly Deletes an Existing Player Object by Name## Vulnerability Details **File Location**: `scripts/SceneSetupWizard.cs`, lines 211-214 **Vulnerability Type**: Unsafe destructive editor operation **Risk Level**: Medium ### Vulnerable Code ```csharp // Check if player already exists var existingPlayer = GameObject.Find("Player"); if (existingPlayer != null) Object.DestroyImmediate(existingPlayer); ``` ### Technical Analysis The wizard treats any active GameObject named `Player` as disposable, without determining whether it was created by this tool. It then destroys the complete object immediately and without Unity Undo registration or user confirmation. Name-based ownership is unreliable because `Player` is a conventional name used by many projects. A matching object can contain a customized controller, inventory, networking state, child hierarchy, camera, or other project-specific components. All of these are removed with the parent GameObject. ### Attack Path 1. A project contains a customized active GameObject named `Player`. 2. The user runs a basic or themed scene-setup command that creates a player controller. 3. `CreatePlayerController` locates the existing object solely by name. 4. The complete existing player hierarchy is destroyed immediately. 5. The wizard creates a minimal replacement player that does not preserve the deleted configuration. 6. Since the deletion was not registered with the Unity Undo system, restoration may require version control or backup recovery. ### Impact Assessment The issue can cause loss of the active scene's existing player object, attached gameplay components, and child hierarchy. It operates only with the current user's Unity Editor access and does not grant elevated operating-system privileges.
• Remediation: ## Remediation Suggestions - Do not infer tool ownership from the generic object name `Player`. - Add a dedicated marker component to player objects generated by the wizard. - If an unrelated player already exists, offer the user choices to reuse it, create another object, or explicitly replace it. - Use `Undo.DestroyObjectImmediate` for any confirmed replacement. - Register the replacement player and its child camera with `Undo.RegisterCreatedObjectUndo`. - Preserve or migrate relevant configuration when replacing a tool-owned player. - Group creation and deletion into one atomic Undo operation.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/PlayerSetup.cs:15
• Finding: Controller Setup Commands Irreversibly Delete an Existing Tagged Player## Vulnerability Details **File Location**: `scripts/PlayerSetup.cs`, lines 15-18, 55-58, and 96-99 **Vulnerability Type**: Unsafe destructive editor operation **Risk Level**: Medium ### Vulnerable Code The FPS controller setup contains: ```csharp // Remove existing player var existing = GameObject.FindWithTag("Player"); if (existing != null) Object.DestroyImmediate(existing); ``` The third-person controller setup repeats the same operation: ```csharp // Remove existing player var existing = GameObject.FindWithTag("Player"); if (existing != null) Object.DestroyImmediate(existing); ``` The top-down controller setup also repeats it: ```csharp // Remove existing player var existing = GameObject.FindWithTag("Player"); if (existing != null) Object.DestroyImmediate(existing); ``` ### Technical Analysis All three controller-creation commands locate an existing object through the standard Unity `Player` tag and destroy the complete GameObject immediately. A tag identifies gameplay purpose, not ownership by this editor tool. Therefore, an unrelated customized player can be deleted even when it was created manually or by another package. The operation does not request confirmation and does not call `Undo.DestroyObjectImmediate`. The replacement controller is a basic prototype and does not preserve scripts, serialized configuration, children, cameras, inventory objects, networking components, or other data from the deleted player. `GameObject.FindWithTag` returns one matching active object, so behavior can also be ambiguous in scenes containing multiple tagged player objects. ### Attack Path 1. A scene contains a customized active GameObject tagged `Player`. 2. The user invokes any of the FPS, third-person, or top-down controller creation menu commands. 3. The command finds one active object carrying the `Player` tag. 4. It immediately destroys that object's complete hierarchy. 5 ...[truncated 544 chars]
• Remediation: ## Remediation Suggestions - Use a marker component or generated-object identifier instead of the generic `Player` tag to establish ownership. - Prompt the user before replacing an unrelated tagged player. - Offer non-destructive alternatives such as selecting the existing player, creating a uniquely named prototype, or adding only missing components. - Replace `Object.DestroyImmediate` with `Undo.DestroyObjectImmediate` after explicit confirmation. - Register all created parent and child objects through Unity's Undo API. - Preserve existing serialized settings and child objects when converting between controller types. - Validate scenes containing multiple `Player`-tagged objects and require the user to select the intended target.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (10)

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The menu action deletes Light and ReflectionProbe scene objects immediately via DestroyImmediate, based only on object name matching, and provides no confirmation, undo registration, or scope limitation. In an editor automation skill, this can cause unintended permanent scene modification and data loss if invoked accidentally or against scenes containing important objects with matching names.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: Multiple lighting setup commands call ClearAllLighting as a hidden side effect, so choosing a preset silently destroys existing lights and probes before applying new settings. In the Unity level-design context this is more dangerous because these editor menu items are meant for rapid iteration and may be used on valuable in-progress scenes, making accidental destructive changes likely.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: Clearing baked lighting removes generated lighting data immediately without confirmation or undo, which can discard time-consuming bake results and disrupt scene state. While not an exploit in the classic sense, it is a destructive editor operation that can cause material workflow and asset loss when triggered unintentionally.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: This editor action destroys any existing object tagged "Player" immediately when the menu item is invoked, with no confirmation, undo registration, or validation that the object was created by this tool. In a Unity Editor workflow, that can cause accidental loss of scene content or prefab state and is especially risky because it targets by a broad tag rather than a tool-owned marker.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: This menu action has the same unsafe behavior: it finds any object tagged "Player" and deletes it immediately. Because scene-authoring tools are often run interactively by designers, an overly broad destructive action can unintentionally remove legitimate work and disrupt the project.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: This top-down setup routine also performs unconditional deletion of the current Player-tagged object without user acknowledgement. In the context of a level-design automation skill, destructive editor operations are more dangerous because they may be triggered during routine prototyping and can silently overwrite intended scene setup.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The wizard enumerates existing lights and immediately destroys all directional light GameObjects, which can irreversibly modify an open scene without informed user consent. In an editor automation tool this is more dangerous because artists may run it on valuable scenes, causing data loss or disruption to lighting setups.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The code finds any object named "Player" and destroys it immediately, regardless of whether it was created by this tool, which can delete legitimate scene content unexpectedly. In a level-design skill this is especially risky because "Player" is a common object name, making accidental destructive edits likely during normal editor use.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The flagged code overwrites the entire terrain heightmap via SetHeights with no confirmation, undo registration, or backup path. In a Unity Editor automation skill, this can cause accidental irreversible loss of level-design work if invoked on the wrong terrain or with unexpected parameters, making it a real safety issue even though it is not a traditional exploit primitive.

Missing User Warnings

Low

• Confidence: 90% confidence
• Finding: This code creates a new asset at a fixed project path via AssetDatabase.CreateAsset, which modifies user project data. Although the method name implies scene setup and there are internal comments, there is no confirmation prompt or user-facing disclosure at the point of the write describing that a project asset will be created.

Static analysis

No suspicious patterns detected.