feat: add the migrate-birp-to-urp skill

[ziyiunity]

Adds migrate-birp-to-urp — planning, executing, and troubleshooting a project's move from the Built-in Render Pipeline to URP: materials, shaders, lighting, baked GI and probes, and post-processing. Six reference files, roughly 1,650 lines of domain content preserved verbatim.

How it was adapted

The skill was written for an agent that drove the Editor through its own built-in tools. Here it drives the Editor through the Unity CLI (unity command eval against the project's com.unity.pipeline package), so it works in any agent that can run a shell. The domain content is untouched — all six reference files are byte-identical apart from the changes below.

• Render-pipeline detection is now two snippets: one reading GraphicsSettings.defaultRenderPipeline, and one walking every Quality level via QualitySettings.GetRenderPipelineAssetAt(i). The per-level check matters — a project can be switched in Graphics settings while a Quality level still points somewhere else, which is a common reason a migration looks half-applied.
• Scene capture goes through a RenderTexture to PNG, documented in references/capturing-the-editor.md, so the agent can look at the result rather than infer it.
• The exposure-validation helper was a method taking a host-supplied result object. It is now a statement block that accumulates its findings and returns them.

Two things worth knowing for anyone adapting a similar skill:

• Extension methods don't work through eval, because they resolve through using and eval compiles a statement block rather than a file. camera.GetUniversalAdditionalCameraData() became GetComponent<UniversalAdditionalCameraData>(), and .FirstOrDefault(…) became System.Linq.Enumerable.FirstOrDefault(seq, pred). The skill documents this so neither form gets reintroduced.
• Class-shaped snippets stay project files. The references include a sealed class MaterialSnapshot and [MenuItem] entry points; a class declaration cannot be flattened into a statement block. Those are saved under Assets/Editor/, compiled, then invoked through a one-line eval. For a migration that route is also the more robust one — it survives the domain reloads that URP installation and material conversion trigger, which a long eval payload does not.

unity command defaults to a 30 second timeout, which URP installation will outlast. The skill treats that as a phase boundary rather than telling the agent to raise the timeout.

Verification

Every snippet was compile-checked against Unity 6000.5.7f1 with URP 17.5 by prefixing if (true) return "OK";, which type-checks the whole block without executing it. A deliberately broken snippet was run as a control and correctly failed with CS0103, so the passes are real rather than an unreachable-code artifact.

Confirmed to compile: UniversalRenderPipelineAsset, UniversalRendererData, UniversalAdditionalCameraData, UnityEngine.Rendering.Volume, RenderSettings, SerializedObject, QualitySettings.GetRenderPipelineAssetAt, and the static-LINQ rewrites.

Review ask

Two questions, and the second is the more valuable one: is the guidance still accurate for current URP, and should a skill of this shape exist at all? If your read is that it's obsolete, that's the most useful answer you can give.

---

Found by running a real migration, and fixed here

I ran this skill end to end against a fresh Built-in project — five materials on Standard, Standard (Specular setup), Legacy Shaders/Diffuse and Particles/Standard Unlit, plus a particle system and a directional light. It completed: URP assigned in Graphics settings and on all six Quality levels, 5/5 materials on URP shaders, and Built-in vs URP captures within 1–2/255 mean RGB.

One finding came out of that run, and it's the kind that passes review by eye, so it's worth a reviewer's attention specifically.

The 2D upgrader silently hijacks Standard materials

MaterialUpgrader.FetchAllUpgradersForPipeline returns the 2D provider set alongside the 3D one, and two upgraders claim Standard at equal priority. On a 3D project that means a plain Standard material can convert to Universal Render Pipeline/2D/Mesh2D-Lit-Default instead of Universal Render Pipeline/Lit.

What makes it nasty: nothing throws, and the material does not render magenta. The only way to notice is to read shader.name back. In my run two of five materials landed on the 2D shader.

The skill now says to verify every converted material's shader name against the intended target, and to restore-and-retry with a 3D-filtered upgrader list if any landed on a 2D/ shader. The manual conversion pattern in references/implementation-patterns.md names its target shader explicitly, so it can't be hijacked — that's now stated as the reason to prefer it when this happens.

Measured on Unity 6000.5.8f1.

Reviewer question: is this the expected behaviour of the converter, or a bug worth filing against URP? I've documented it as behaviour to defend against, but someone on the rendering side would know whether it should be fixed upstream instead.

Also: a minimum-Editor-version note in Step 0

Step 0 now states that the CLI's Editor-side integration requires Unity 6000.3 or newer, and describes the symptom to expect on an older Editor so the agent reports the version requirement instead of debugging the CLI. This skill is the one most likely to meet it — someone migrating off the Built-in pipeline is, by definition, often on an older Editor.