Update to Unity

{
  "description": "Use when the user wants to review or validate a Unity 6+ URP ScriptableRendererFeature that uses the Render Graph API. Checks for correctness issues - resource wiring, material binding, execution structure, descriptor usage, global resource exposure, and Render Graph best practices.",
  "included_files": [],
  "name": "validate-urp-render-graph-renderer-feature",
  "skill_md_contents": "---\nname: validate-urp-render-graph-renderer-feature\ndescription: Use when the user wants to review or validate a Unity 6+ URP ScriptableRendererFeature that uses the Render Graph API. Checks for correctness issues - resource wiring, material binding, execution structure, descriptor usage, global resource exposure, and Render Graph best practices.\n---\n# Skill: Validate a Unity URP Render Graph Renderer Feature\n\n## Purpose\nReview a Unity 6+ URP Render Graph `ScriptableRendererFeature` and its associated pass implementation for correctness issues related to material binding, resource wiring, render graph texture creation, static render function structure, global resource exposure, and API/version usage.\n\n## When to Use\nUse this skill when:\n- reviewing AI-generated Unity URP Render Graph renderer feature code\n- validating a custom `ScriptableRendererFeature` before integrating it\n- checking for common Render Graph resource wiring and pass setup mistakes\n- diagnosing suspicious but plausible Render Graph pass implementations\n- reviewing whether a custom raster/blit/copy pass uses the most appropriate Render Graph helper APIs\n\n## Inputs\nThe skill should expect:\n- **Unity version**\n- **URP version**\n- **Render Graph renderer feature code to review**\n  - `ScriptableRendererFeature`\n  - associated pass code\n  - or both\n- **Intended behavior**\n- **Expected inputs/outputs**, if known\n- **Optional constraints**\n  - project conventions\n  - required pass type\n  - known resources\n  - required material/shader properties\n\n## Output Format\nThe skill must return results in the following structure:\n\n### 1. Validation Summary\nA short overall assessment of the implementation.\n\n### 2. Confirmed Issues\nConcrete issues directly supported by the provided code.\n\n### 3. Likely Issues / Risky Assumptions\nPotential issues that depend on missing context or incomplete information.\n\n### 4. Recommended Fixes\nMinimal targeted fixes for each issue.\n\n### 5. Corrected Snippets\nSmall corrected code snippets where useful.\n\n### 6. Missing Information\nAny information needed to validate the code with higher confidence.\n\n## Validation Checklist\n\n### 1. Material Binding\nCheck that:\n- materials are declared clearly\n- serialized materials are exposed correctly when needed\n- materials are passed into the pass correctly\n- null handling exists where required\n- declared materials are actually used\n- **all required material inputs are bound before execution**\n- **the primary input texture is explicitly bound when the shader expects one**\n- auxiliary textures and parameter textures are also bound explicitly\n- texture/property binding matches the shader’s expected property names\n\nFlag as an issue when:\n- a material is declared or passed but not actually used\n- only secondary textures or parameters are bound while the main input texture is omitted\n- the pass binds a mask/noise/auxiliary texture but fails to bind the primary color/input texture\n- required shader properties are assumed to exist without being set\n- property names are inconsistent or ambiguous\n- the code relies on implicit main texture binding when explicit binding is required by the pass pattern\n\nPrefer patterns where:\n1. the material is created or assigned clearly\n2. the primary source texture is bound explicitly\n3. all auxiliary textures are bound explicitly\n4. property names are consistent and intentional\n5. null or missing-resource cases are handled or reported\n\n### 2. Texture Resource Wiring\nCheck that:\n- sampled/read textures, write targets, and auxiliary textures are clearly distinguished\n- textures used with `UseTexture(...)` are appropriate for read access\n- textures used with `SetRenderAttachment(...)` are appropriate as write targets\n- source, destination, and auxiliary resources are not confused\n- all expected textures are explicitly wired\n- texture property names are explicit and consistent when materials are involved\n- the implementation does not invent texture availability\n- multi-texture resource usage is handled explicitly rather than implicitly\n\nFlag as an issue when:\n- a texture intended as an input/read resource is instead used as a write target without justification\n- a destination/write target is confused with a sampled input\n- auxiliary textures are used without being clearly sourced or wired\n- a required texture resource is missing from the pass setup\n- read/write resource roles are ambiguous or inconsistent\n\n### 3. Execution Structure / Static Render Function\nCheck that:\n- the render function is declared as `static`\n- the execution structure matches the target pass type and API style\n- pass data is wired correctly into execution\n- resources are accessed in the correct stage\n- execution logic is consistent with the intended render pass behavior\n- every `PassData` field used by the render function is explicitly assigned during pass setup for the current recording\n- the implementation does not rely on default values or previously assigned `PassData` state\n- resource handles stored in `PassData` are assigned fresh for the current frame/pass recording and are not left dangling from prior usage\n\nFlag as an issue when:\n- the render function is not `static`\n- the implementation uses an instance method where the API pattern expects a static render function\n- pass data or required resources are accessed through instance state instead of the pass data/context provided to the static function\n- execution flow does not match the expected render graph or pass execution pattern\n- a `PassData` field is read in the render function but is not clearly assigned during pass setup\n- only some `PassData` fields are reassigned while others may retain stale values from previous pooled usage\n- a resource handle stored in `PassData` may survive from a previous frame or pass due to incomplete reassignment\n- the implementation risks using a dangling or stale handle because pass data is not fully initialized each time it is recorded\n\nPrefer:\n- explicitly assigning every `PassData` field used by the pass during each `RecordRenderGraph(...)` call\n- treating `PassData` as transient per-recording data, not persistent state\n- avoiding partial initialization of pooled pass data objects\n\n### 4. Render Graph Descriptor Validation\nCheck that:\n- the implementation does **not** create a new `TextureDesc` by default when an appropriate graph-derived descriptor can be used directly\n- when a texture should match the active render target, the descriptor is sourced from the relevant render graph resource first, such as:\n  - `resourceData.activeColorTexture.GetDescriptor(renderGraph)`\n  - or another appropriate existing graph-backed resource\n- only the fields that actually need to differ are modified after sourcing the descriptor\n- descriptor fields such as name, depth bits, format, and MSAA are intentionally preserved or intentionally overridden\n- any manual reconstruction of descriptor data is justified by a specific requirement\n\nFlag as an issue when:\n- the code creates a fresh `TextureDesc` without first attempting to reuse a graph-derived descriptor\n- width and height are manually copied into a new descriptor structure by default\n- `cameraTargetDescriptor` is used as the primary source when a render-graph-derived descriptor is available and more accurate\n- important properties such as MSAA, graphics format, or compatibility with the active render target are dropped accidentally\n- descriptor reconstruction is used as a convenience shortcut rather than a necessary divergence from the source resource\n\nPreferred rule:\n- **Do not create a new `TextureDesc` unless a graph-derived descriptor cannot be used directly or the texture must intentionally diverge from the source resource.**\n\nPreferred pattern:\n1. get the descriptor from the relevant render graph resource\n2. modify only the fields that must change\n3. create the texture from that derived descriptor whenever possible\n\nExamples:\n\n#### Preferred\n```csharp\nRenderTextureDescriptor desc = resourceData.activeColorTexture.GetDescriptor(renderGraph);\ndesc.depthBufferBits = 0;\ndesc.name = \"New name\";\n// other desired paramters\npassData.targetTexture = renderGraph.CreateTexture(desc);\n```\n\n### 5. Manual Copy Pass Simplification\nCheck that:\n- simple texture copy operations are not implemented as full custom raster passes when a built-in Render Graph helper is sufficient\n- passes that only read one texture and write it unchanged to another target are simplified where appropriate\n- the implementation prefers the most appropriate built-in helper for the target API/platform context\n- `AddCopyPass(...)` is not recommended by default if a more compatible `AddBlitPass(...)` overload should be preferred in the current environment\n\nFlag as an issue when:\n- a raster pass exists only to copy one texture into another\n- the pass uses no material and no custom processing\n- the render function only performs a simple blit/copy equivalent\n- the implementation uses a full custom raster pass where a built-in copy/blit helper would express the same behavior more directly\n\nPrefer:\n- the appropriate `AddBlitPass(...)` overload for straightforward copy-like operations when that is the recommended and more compatible path\n- `AddCopyPass(...)` only when it is explicitly appropriate and supported for the target API/platform context\n- a custom raster pass only when the copy requires additional logic or non-trivial behavior\n\n### 6. Manual Blit Pass Simplification\nCheck that:\n- straightforward fullscreen material blits are not implemented as custom raster passes when `renderGraph.AddBlitPass(...)` would express the same behavior more directly\n- custom raster passes are only used for blits when additional logic or non-trivial behavior is actually required\n- simple source-to-destination material blits use the most direct render graph helper available\n\nFlag as an issue when:\n- a raster pass reads one source texture and writes one destination texture\n- the pass uses a material but no additional custom pass logic\n- the render function only performs a simple fullscreen blit\n- `renderGraph.AddBlitPass(...)` would provide an equivalent result more clearly\n\nPrefer:\n- `renderGraph.AddBlitPass(...)` for straightforward fullscreen material blits\n- a custom raster pass only when extra logic, multiple operations, conditional behavior, or special setup is actually required\n\n### 7. Global Resource Exposure\nCheck that:\n- textures and buffers are not exposed globally unless explicitly requested or clearly required by a downstream consumer\n- when global exposure is required in a render graph pass, the implementation uses the appropriate render graph publication mechanism\n- direct command buffer global state mutation is not used as a substitute for render graph resource publication\n- global exposure is not extending resource lifetime unnecessarily or reducing aliasing opportunities without justification\n\nFlag as an issue when:\n- `SetGlobalTextureAfterPass` is used without a clear consumer\n- `context.cmd.SetGlobalTexture(...)` is used inside a render graph pass where render graph resource publication is the appropriate mechanism\n- global exposure is used as a convenience shortcut instead of explicit pass-to-pass wiring\n- hidden coupling is introduced unnecessarily\n- a globally exposed texture may be kept alive longer than necessary due to downstream `UseGlobalTexture(...)` or `UseAllGlobalTextures()` usage, increasing memory pressure or reducing aliasing opportunities\n\nPrefer:\n- no global exposure by default\n- explicit resource wiring where possible\n- `builder.SetGlobalTextureAfterPass(...)` only when global publication is truly required in render graph\n- resource lifetimes that remain as local and short-lived as possible\n\n### 8. Renderer Feature Input Declaration\nCheck that:\n- the `ScriptableRendererFeature` and its associated pass declare required pipeline inputs using `ConfigureInput(...)` when needed\n- the requested input flags match the feature’s intended behavior and visible resource usage\n- the pass does not rely on pipeline-provided inputs without declaring them when required by the target API pattern\n- unnecessary input requests are not declared by default, especially when they may introduce extra copies, intermediate resources, or avoidable pipeline work\n\nFlag as an issue when:\n- the feature’s pass uses or is clearly intended to use a pipeline-provided input but does not declare it with `ConfigureInput(...)`\n- `ConfigureInput(...)` requests inputs that the feature/pass does not appear to use\n- the declared input flags do not match the intended effect behavior\n- the effect description, code, and declared inputs imply conflicting requirements\n- unnecessary declared inputs may force extra copies, extra pass work, or other avoidable performance costs\n\nClassification guidance:\n- mark as a **confirmed issue** when the code clearly shows a required input is used but not declared\n- mark as a **likely issue** when the intended effect implies a required input but the visible code does not fully prove shader/resource usage\n- treat unnecessary input declarations as higher severity when they are likely to introduce additional copies or other measurable runtime cost\n\n## Guardrails\nThe skill must:\n- avoid inventing unsupported APIs\n- distinguish **confirmed** issues from **likely** issues\n- prefer minimal targeted fixes over broad rewrites\n- explain why each issue matters\n- flag hidden coupling and unnecessary global state\n- state when the provided code is insufficient for full certainty\n\n## Non-Goals\n- guarantee runtime correctness\n- rewrite the entire renderer feature unless necessary\n- validate unrelated gameplay logic\n- validate shader internals unless directly relevant to pass wiring or binding\n\n## Evaluation Criteria\nA successful validation should:\n- catch real wiring and API issues\n- identify suspicious but plausible mistakes\n- provide actionable fixes\n- avoid false certainty\n- improve trust in generated render pass code\n\n## Notes for Future Expansion\nAs new recurring issues are discovered, extend this checklist with additional rules such as:\n- pass ordering / injection point validation\n- resource lifetime and cleanup checks\n- read/write hazard detection\n- unnecessary copies or allocations\n- camera depth/color dependency validation\n- multi-pass dependency validation\n- override material correctness\n- pass configuration\n"
}