Unity YAML Editing

Before calling any skill in this module: if you are about to call a skill with parameters guessed from its name or description, STOP — read this file (or fetch its schema via GET /skills/recommend?includeSchema=true) first. If you already have the parameter definitions from recommend/schema, you may proceed straight to dryRun.

Triggers

• Hand-editing YAML when REST cannot reach
• Fixing m_Script GUIDs or broken fileID references
• Fixing .meta files or merge conflicts
• REST 无法触达时手编 YAML、修复 m_Script GUID 或断裂 fileID 引用、修复 .meta 文件或合并冲突

YAML Editing - Safe Hand-Edit Rules

Advisory module. This is operational guidance for directly editing Unity serialized YAML text when the REST skills (and the Editor itself) cannot do the job. Hand-editing YAML is the last resort, not a shortcut.

Mode: Documentation only — no REST skills to gate; load freely under any operating mode (Approval / Auto / Bypass).

When To Load / When NOT

Prefer REST first. For normal object/asset work, use the REST skills — they keep serialization valid for you:

• GameObjects / components → gameobject_*
• Prefabs → prefab_*
• ScriptableObjects → scriptableobject_*
• Scenes → scene_*
• Importers → importer_*
• Graphics / rendering → graphics_*

Only hand-edit YAML when REST cannot reach, i.e. one of:

1. Compile failure — a script fails to compile, so the Editor cannot deserialize the component. Editor/REST APIs are unavailable; the only level left is the YAML text.
2. .meta files — no REST skill touches .meta; GUID and importer fields live only in text.
3. Hidden ProjectSettings fields — many ProjectSettings/*.asset fields have no public API or REST surface.
4. Merge conflicts — REST runs sequentially and cannot perform a 3-way merge of .unity / .prefab.

If none of these apply, stop and use REST. Do not hand-edit YAML for convenience.

Core Concepts

• Object block / anchor: every serialized object is a block headed by --- !u!<classID> &<fileID>. <classID> is the Unity type id (e.g. 1 = GameObject, 4 = Transform, 114 = MonoBehaviour). <fileID> is the object's anchor, unique within this file.
• GUID vs fileID:
  • GUID = asset-level identity, a 32-char hex string, stored in the asset's .meta. Identifies the whole asset (a script, prefab, texture, ...).
  • fileID = sub-object identity inside a file (a specific component, the specific MonoBehaviour script class, ...).
• Serialized reference: a cross-object/asset reference is {fileID: N, guid: H, type: T}. guid is omitted for same-file references ({fileID: N}).
• m_Script: a MonoBehaviour points at its script via m_Script: {fileID: 11500000, guid: <scriptGUID>, type: 3}. fileID: 11500000 is the conventional MonoScript fileID; guid is the .cs file's GUID from its .meta; type: 3 means the reference targets an asset on disk. A wrong guid/fileID here is exactly what produces a "missing script / missing component".

Coverage Scenarios

1. Reference / fileID repair

When: a script was renamed or moved, so a prefab/scene m_Script guid/fileID no longer resolves; or a compile failure left a component as Missing and you must locate, delete, or re-point it at the YAML level (the Editor cannot deserialize a broken component, so REST/Editor API is unavailable).

How: read the script's current GUID from its .cs.meta. In the prefab/scene, find the offending m_Script: {fileID: 11500000, guid: ..., type: 3} and set guid to the correct value (keep fileID: 11500000, type: 3). To delete a Missing component, remove its whole --- !u!114 &<fileID> block and the matching {component: {fileID: <fileID>}} entry under the owner GameObject's m_Component list — leaving one without the other corrupts the file.

Danger: deleting the object block but not its m_Component reference (or vice versa) breaks the GameObject; changing a fileID that other objects reference orphans those references.