agentleFS
nowsprintingnowsprinting/unity-coding-skills/skills/unity-yaml-editing-guide/SKILL.md

unity-yaml-editing-guide

Skill20 starsChanged 26 days agoUnlicenseView on GitHub

Provides guidelines for directly editing Unity YAML-serialized asset files for Unity projects. Make sure to use this skill whenever creating, editing, or modifying simple YAML asset files (ScriptableObjects, Materials, etc.) via Edit/Write tools without going through the Unity Editor. This includes adjusting ScriptableObject field values, modifying material shader properties, or any task that results in direct changes to allowlisted Unity YAML asset files. Even for small edits or one-line value changes, load this skill to ensure Unity asset-YAML conventions are followed.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 0 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Never directly edit .unity or .prefab files: Use edit-scene skill — those carry GameObject/Prefab-instance structure that is unsafe to …

    line 21
  2. Very specific:

    Verify the file starts with %YAML 1.1 before editing: If it does not, the project is in Binary or Mixed serialization mode and the asset …

    line 35
  3. Very specific:

    Before editing any .asset or .mat file (header, m_Script, class-typed contents, or unfamiliar field): Read …

    line 59

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Guide for directly editing Unity YAML-serialized asset files for Unity projects.

Rules

  • Edit only the following allowlist of simple YAML asset types. Other YAML assets (AnimationClip, AnimatorController, Texture2D, Mesh, AudioClip, LightingDataAsset, etc.) carry binary-derived data or complex internal structure — open them in Unity Editor instead.
    • ScriptableObject (MonoBehaviour, class ID 114) — files *.asset
    • Material (Material, class ID 21) — files *.mat
  • Never directly edit .unity or .prefab files. Use edit-scene skill — those carry GameObject/Prefab-instance structure that is unsafe to author by hand.
  • Never touch .meta files. Unity owns .meta content (GUIDs, importer settings); hand-edits corrupt asset references project-wide.
  • Preserve the mandatory two-line header exactly. Lines 1–2 must be %YAML 1.1 and %TAG !u! tag:unity3d.com,2011: — these are not stylistic, and Unity will fail to load the asset if they drift.
  • Preserve the document marker. --- !u!<classID> &<fileID> — for ScriptableObject use --- !u!114 &11400000, for Material use --- !u!21 &2100000 (canonical local anchors).
  • Keep the canonical preamble field order at the top of the mapping. For ScriptableObject (MonoBehaviour:), the order is m_ObjectHideFlags → m_CorrespondingSourceObject → m_PrefabInstance → m_PrefabAsset → m_GameObject → m_Enabled → m_EditorHideFlags → m_Script → m_Name → m_EditorClassIdentifier. User fields come after.
  • Keep m_Name in sync with the filename (without the .asset / .mat extension) — a mismatch confuses Unity's importer and Resources.Load-style lookups.
  • Cross-file object references need all three keys — {fileID: N, guid: <32-hex>, type: T} where type: 2 is a project asset and type: 3 is a script. Local references use {fileID: N} matching an &N anchor in the same file; {fileID: 0} means null.
  • Quote strings only when they contain non-ASCII characters, and escape every non-ASCII code point as \uXXXX inside double quotes — plain ASCII stays unquoted. Match how Unity itself emits the file.
  • Use 2-space indent, LF line endings, UTF-8 without BOM, and a trailing newline at EOF. Tabs, CRLF, or a BOM round-trip badly when Unity re-saves the file.
  • Do not add comments, YAML aliases (*name), extra tags, or chomping indicators (|, >). Unity's YAML parser drops or rejects them, and re-save would strip cosmetic formatting anyway — don't bother polishing what Unity will normalize.
  • After editing, let Unity re-import the asset (focus the Editor) and confirm successful import using get_unity_compilation_result. Review the diff Unity produces on next save to confirm the edit was accepted as intended.

Gotchas

  • Verify the file starts with %YAML 1.1 before editing. If it does not, the project is in Binary or Mixed serialization mode and the asset must not be hand-edited — open it in the Unity Editor instead.
  • Never invent an m_Script GUID. Copy from an existing asset of the same ScriptableObject type, or look up the script's .cs.meta file — fabricated GUIDs detach the asset from its script.
  • Auto-property backing fields appear literally as <PropertyName>k__BackingField. Do not rename them to the property name — the serialized name is the C# compiler's backing-field symbol.
  • Use Unity's scalar forms, not generic YAML forms — bools as 0 / 1 (never true / false), enums and ints bare, floats as plain decimals, Vector3 as {x: 0, y: 0, z: 0} flow style, Quaternion as {x: 0, y: 0, z: 0, w: 1}, Color as {r: 1, g: 1, b: 1, a: 1}.

Scalar quick-reference

TypeFormExample
bool0 / 1m_Enabled: 1
int / enumbare integer<Cost>k__BackingField: 1
floatplain decimalm_Glossiness: 0.5
ASCII stringunquotedm_Name: DryPrinciple
non-ASCII stringdouble-quoted, \uXXXX escapes"DRY\u539F\u5247"
Vector3flow mapping{x: 0, y: 0, z: 0}
Quaternionflow mapping{x: 0, y: 0, z: 0, w: 1}
Colorflow mapping{r: 1, g: 1, b: 1, a: 1}
local refflow mapping{fileID: 11400000}
cross-file refflow mapping{fileID: 11400000, guid: <32-hex>, type: 2}
null refflow mapping{fileID: 0}
list of refsblock sequence with - bulletsone - {fileID: ...} per line

Resources

  • Before editing any .asset or .mat file (header, m_Script, class-typed contents, or unfamiliar field): Read ${CLAUDE_SKILL_DIR}/resources/asset-yaml-format.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.