/validate-urp-render-graph-renderer-feature

name: validate-urp-render-graph-renderer-feature
description: Reviews a Unity 6 URP ScriptableRendererFeature that uses the Render Graph API, checking resource wiring, material binding, execution structure, and best practices. Use to validate a renderer feature.

Skill: Validate a Unity URP Render Graph Renderer Feature

Purpose

Review 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.

When to Use

Use this skill when:

• reviewing AI-generated Unity URP Render Graph renderer feature code
• validating a custom `ScriptableRendererFeature` before integrating it
• checking for common Render Graph resource wiring and pass setup mistakes
• diagnosing suspicious but plausible Render Graph pass implementations
• reviewing whether a custom raster/blit/copy pass uses the most appropriate Render Graph helper APIs

Inputs

The skill should expect:

• **Unity version**
• **URP version**
• **Render Graph renderer feature code to review**
• `ScriptableRendererFeature`
• associated pass code
• or both
• **Intended behavior**
• **Expected inputs/outputs**, if known
• **Optional constraints**
• project conventions
• required pass type
• known resources
• required material/shader properties

Output Format

The skill must return results in the following structure:

1. Validation Summary

A short overall assessment of the implementation.

2. Confirmed Issues

Concrete issues directly supported by the provided code.

3. Likely Issues / Risky Assumptions

Potential issues that depend on missing context or incomplete information.

4. Recommended Fixes

Minimal targeted fixes for each issue.

5. Corrected Snippets

Small corrected code snippets where useful.

6. Missing Information

Any information needed to validate the code with higher confidence.

Validation Checklist

1. Material Binding

Check that:

• materials are declared clearly
• serialized materials are exposed correctly when needed
• materials are passed into the pass correctly
• null handling exists where required
• declared materials are actually used
• **all required material inputs are bound before execution**
• **the primary input texture is explicitly bound when the shader expects one**
• auxiliary textures and parameter textures are also bound explicitly
• texture/property binding matches the shader’s expected property names

Flag as an issue when:

• a material is declared or passed but not actually used
• only secondary textures or parameters are bound while the main input texture is omitted
• the pass binds a mask/noise/auxiliary texture but fails to bind the primary color/input texture
• required shader properties are assumed to exist without being set
• property names are inconsistent or ambiguous
• the code relies on implicit main texture binding when explicit binding is required by the pass pattern

Prefer patterns where: 1. the material is created or assigned clearly 2. the primary source texture is bound explicitly 3. all auxiliary textures are bound explicitly 4. property names are consistent and intentional 5. null or missing-resource cases are handled or reported

2. Texture Resource Wiring

Check that:

• sampled/read textures, write targets, and auxiliary textures are clearly distinguished
• textures used with `UseTexture(...)` are appropriate for read access
• textures used with `SetRenderAttachment(...)` are appropriate as write targets
• source, destination, and auxiliary resources are not confused
• all expected textures are explicitly wired
• texture property names are explicit and consistent when materials are involved
• the implementation does not invent texture availability
• multi-texture resource usage is handled explicitly rather than implicitly

Flag as an issue when:

• a texture intended as an input/read resource is instead used as a write target without justification
• a destination/write target is confused with a sampled input
• auxiliary textures are used without being clearly sourced or wired
• a required texture resource is missing from the pass setup
• read/write resource roles are ambiguous or inconsistent

3. Execution Structure / Static Render Function

Check that:

• the render function is declared as `static`
• the execution structure matches the target pass type and API style
• pass data is wired correctly into execution
• resources are accessed in the correct stage
• execution logic is consistent with the intended render pass behavior
• every `PassData` field used by the render function is explicitly assigned during pass setup for the current recording
• the implementation does not rely on default values or previously assigned `PassData` state
• resource handles stored in `PassData` are assigned fresh for the current frame/pass recording and are not left dangling from prior usage

Flag as an issue when:

• the render function is not `static`
• the implementation uses an instance method where the API pattern expects a static render function
• pass data or required resources are accessed through instance state instead of the pass data/context provided to the static function
• execution flow does not match the expected render graph or pass execution pattern
• a `PassData` field is read in the render function but is not clearly assigned during pass setup
• only some `PassData` fields are reassigned while others may retain stale values from previous pooled usage
• a resource handle stored in `PassData` may survive from a previous frame or pass due to incomplete reassignment
• the implementation risks using a dangling or stale handle because pass data is not fully initialized each time it is recorded

Prefer:

• explicitly assigning every `PassData` field used by the pass during each `RecordRenderGraph(...)` call
• treating `PassDat