nccgs 1.0.0

package/.claude/skills/urp-postprocessing/references/code-templates.md

@@ -0,0 +1,119 @@
+## Code Templates
+
+Each template is a snippet to run through the Editor's `eval` command. Hard stops `throw`,
+so the eval fails loudly; anything the caller needs to read is `return`ed.
+
+**`eval` compiles a statement block, not a file.** `using` directives are rejected there — the
+compiler reads `using UnityEngine;` as a resource-disposal statement and fails. So these
+templates fully qualify every type. If you instead save the code as a `.cs` file for the user
+to keep, add the usings back and drop the qualification.
+
+### Creating a Global Volume with Effects
+
+```csharp
+// Verify HDR is enabled on the URP Asset
+var urpAsset = UnityEngine.Rendering.Universal.UniversalRenderPipeline.asset;
+if (urpAsset == null) { throw new System.Exception("No UniversalRenderPipelineAsset active."); }
+if (!urpAsset.supportsHDR) { throw new System.Exception("HDR is disabled on the URP Asset. Enable it for Bloom/Tonemapping."); }
+
+var profile = UnityEngine.ScriptableObject.CreateInstance<UnityEngine.Rendering.VolumeProfile>();
+var assetPath = UnityEditor.AssetDatabase.GenerateUniqueAssetPath("Assets/Settings/PostProcessProfile.asset");
+UnityEditor.AssetDatabase.CreateAsset(profile, assetPath);
+
+// MUST set overrideState = true on each property
+var bloom = profile.Add<UnityEngine.Rendering.Universal.Bloom>();
+bloom.threshold.overrideState = true;
+bloom.threshold.value = 0.9f;
+bloom.intensity.overrideState = true;
+bloom.intensity.value = 1f;
+bloom.scatter.overrideState = true;
+bloom.scatter.value = 0.7f;
+
+var tonemapping = profile.Add<UnityEngine.Rendering.Universal.Tonemapping>();
+tonemapping.mode.overrideState = true;
+tonemapping.mode.value = UnityEngine.Rendering.Universal.TonemappingMode.ACES;
+
+var volumeObj = new UnityEngine.GameObject("Global Volume");
+var volume = volumeObj.AddComponent<UnityEngine.Rendering.Volume>();
+volume.isGlobal = true;
+volume.profile = profile;
+
+UnityEditor.Undo.RegisterCreatedObjectUndo(volumeObj, "Create Global Volume");
+UnityEditor.EditorUtility.SetDirty(profile);
+UnityEditor.AssetDatabase.SaveAssets();
+
+return "Created Global Volume with Bloom and ACES Tonemapping.";
+```
+
+### Enabling Post-Processing on Camera
+
+```csharp
+var cam = UnityEngine.Camera.main;
+if (cam == null) { throw new System.Exception("No Main Camera found."); }
+
+if (!cam.TryGetComponent<UnityEngine.Rendering.Universal.UniversalAdditionalCameraData>(out var data)) { throw new System.Exception("Missing UniversalAdditionalCameraData. Is URP active?"); }
+
+UnityEditor.Undo.RecordObject(data, "Enable Post-Processing");
+data.renderPostProcessing = true;
+UnityEditor.EditorUtility.SetDirty(data);
+return $"Post-processing enabled on '{cam.name}'.";
+```
+
+### Modifying an Existing Volume Profile
+
+```csharp
+var volumeObj = UnityEngine.GameObject.Find("Global Volume");
+if (volumeObj != null && volumeObj.TryGetComponent<UnityEngine.Rendering.Volume>(out var volume) && volume.profile != null)
+{
+    if (volume.profile.TryGet<UnityEngine.Rendering.Universal.Bloom>(out var bloom))
+    {
+        bloom.intensity.overrideState = true;
+        bloom.intensity.value = 2f;
+    }
+    UnityEditor.EditorUtility.SetDirty(volume.profile);
+}
+```
+
+### Making a change undoable through `eval`
+
+`Undo.RecordObject` alone does **not** produce an undo entry when the snippet runs through the
+Editor's `eval` command (measured: nothing appeared on the undo stack). `RecordObject` takes a
+*deferred* snapshot that Unity flushes at the end of an Editor event, and a snippet executed by
+the Pipeline server is outside that loop.
+
+Use the explicit group + immediate-snapshot + flush sequence instead, which does not rely on
+the event loop:
+
+```csharp
+UnityEditor.Undo.IncrementCurrentGroup();
+UnityEditor.Undo.SetCurrentGroupName("Set up post-processing");     // the label the user will see
+var group = UnityEditor.Undo.GetCurrentGroup();
+
+UnityEditor.Undo.RegisterCompleteObjectUndo(target, "Set up post-processing");   // immediate, not deferred
+// ... make the modification, and for a newly created object:
+// UnityEditor.Undo.RegisterCreatedObjectUndo(newObject, "Set up post-processing");
+UnityEditor.EditorUtility.SetDirty(target);
+
+UnityEditor.Undo.FlushUndoRecordObjects();         // force the snapshot out now
+UnityEditor.Undo.CollapseUndoOperations(group);    // one entry, not several
+
+return UnityEditor.Undo.GetCurrentGroupName();     // report the label back to confirm it landed
+```
+
+**Verify it landed rather than assuming.** The returned group name tells you the group exists;
+to confirm the entry is actually on the stack, have the user check `Edit > Undo <label>` in the
+menu — it should read your label.
+
+**If it still doesn't land, fall back to a scoped revert rather than dropping the guarantee.**
+Before modifying, read the current value of the field you're about to change and report it with
+a one-line snippet that restores it, so reverting is a single command:
+
+```csharp
+// captured before the change
+var previous = data.renderPostProcessing;         // report: previous = false
+// revert snippet to hand the user:
+//   data.renderPostProcessing = false;
+```
+
+Scene and prefab files are text-serialized, so version control is the last resort, not the
+first answer — offer the scoped revert before pointing at `git`.

package/.claude/skills/urp-postprocessing/references/effect-reference.md

@@ -0,0 +1,86 @@
+## Effect Reference
+
+**Bloom** (`Bloom`) — Glow on bright areas. Best with HDR rendering enabled on the URP Asset; works in SDR if `threshold` < 1.
+- `threshold` (MinFloatParameter, default 0.9, min 0) — brightness cutoff below which pixels don't bloom.
+- `intensity` (MinFloatParameter, default 0, min 0) — strength of the bloom effect.
+- `scatter` (ClampedFloatParameter, default 0.7, 0–1) — spread/diffusion of the glow.
+- `clamp` (MinFloatParameter, default 65472, min 0) — clamps pixel intensity to prevent artifacts.
+- `tint` (ColorParameter, default white) — color tint applied to bloom.
+- `highQualityFiltering` (BoolParameter, default false) — uses bicubic upsampling for smoother bloom.
+- `downscale` (BloomDownscaleMode: `Half`, `Quarter`) — resolution for bloom computation.
+- `maxIterations` (ClampedIntParameter, default 6, 2–8) — number of blur passes.
+
+**Tonemapping** (`Tonemapping`) — Maps HDR to display range. Requires HDR.
+- `mode` (TonemappingMode: `None`, `Neutral`, `ACES`) — `ACES` for cinematic, `Neutral` for minimal color shift.
+
+**Color Adjustments** (`ColorAdjustments`) — **WARNING: Class is `ColorAdjustments`, NOT `ColorGrading`.**
+- `postExposure` (FloatParameter, default 0) — exposure adjustment in EV units. Unbounded.
+- `contrast` (ClampedFloatParameter, default 0, -100–100).
+- `colorFilter` (ColorParameter, default white) — multiplied against the final color.
+- `hueShift` (ClampedFloatParameter, default 0, -180–180) — shifts all hues.
+- `saturation` (ClampedFloatParameter, default 0, -100–100).
+
+**Depth of Field** (`DepthOfField`)
+- `mode` (DepthOfFieldMode: `Off`, `Gaussian`, `Bokeh`).
+- Gaussian mode: `gaussianStart` (MinFloatParameter, default 10, min 0), `gaussianEnd` (MinFloatParameter, default 30, min 0), `gaussianMaxRadius` (ClampedFloatParameter, default 1, 0.5–1.5).
+- Bokeh mode: `focusDistance` (MinFloatParameter, default 10, min 0.1), `focalLength` (ClampedFloatParameter, default 50, 1–300), `aperture` (ClampedFloatParameter, default 5.6, 1–32), `bladeCount` (ClampedIntParameter, default 5, 3–9), `bladeCurvature` (ClampedFloatParameter, default 1, 0–1), `bladeRotation` (ClampedFloatParameter, default 0, -180–180).
+
+**Vignette** (`Vignette`)
+- `intensity` (ClampedFloatParameter, default 0, 0–1).
+- `smoothness` (ClampedFloatParameter, default 0.2, 0.01–1).
+- `color` (ColorParameter, default black).
+- `center` (Vector2Parameter, default (0.5, 0.5)).
+- `rounded` (BoolParameter, default false) — constrains vignette to circular shape.
+
+**Motion Blur** (`MotionBlur`)
+- `mode` (MotionBlurMode: `CameraOnly`, `CameraAndObjects`). `CameraAndObjects` requires per-object motion vectors.
+- `quality` (MotionBlurQuality: `Low`, `Medium`, `High`).
+- `intensity` (ClampedFloatParameter, default 0, 0–1).
+- `clamp` (ClampedFloatParameter, default 0.05, 0–0.2) — maximum velocity in screen fraction.
+
+**Film Grain** (`FilmGrain`)
+- `type` (FilmGrainLookup: `Thin1`, `Thin2`, `Medium1`–`Medium6`, `Large01`, `Large02`, `Custom`).
+- `intensity` (ClampedFloatParameter, default 0, 0–1).
+- `response` (ClampedFloatParameter, default 0.8, 0–1).
+- `texture` (NoInterpTextureParameter, default null) — required when `type` is `Custom`.
+
+**Chromatic Aberration** (`ChromaticAberration`)
+- `intensity` (ClampedFloatParameter, default 0, 0–1). Keep subtle (0.05–0.15) for realism.
+
+**Split Toning** (`SplitToning`)
+- `shadows` (ColorParameter, default grey).
+- `highlights` (ColorParameter, default grey).
+- `balance` (ClampedFloatParameter, default 0, -100–100).
+
+**Lens Distortion** (`LensDistortion`)
+- `intensity` (ClampedFloatParameter, default 0, -1–1). Negative = barrel, positive = pincushion.
+- `xMultiplier` (ClampedFloatParameter, default 1, 0–1).
+- `yMultiplier` (ClampedFloatParameter, default 1, 0–1).
+- `center` (Vector2Parameter, default (0.5, 0.5)).
+- `scale` (ClampedFloatParameter, default 1, 0.01–5).
+
+**White Balance** (`WhiteBalance`)
+- `temperature` (ClampedFloatParameter, default 0, -100–100). Negative = cool, positive = warm.
+- `tint` (ClampedFloatParameter, default 0, -100–100). Negative = green, positive = magenta.
+
+**Panini Projection** (`PaniniProjection`) — Only useful with camera FOV > 90.
+- `distance` (ClampedFloatParameter, default 0, 0–1).
+- `cropToFit` (ClampedFloatParameter, default 1, 0–1).
+
+**Lift Gamma Gain** (`LiftGammaGain`) — Each is `Vector4Parameter` (RGBA where A is intensity offset, defaults to (1,1,1,0)).
+- `lift` — affects shadows.
+- `gamma` — affects midtones.
+- `gain` — affects highlights.
+
+**Shadows Midtones Highlights** (`ShadowsMidtonesHighlights`) — Each `Vector4Parameter`, defaults to (1,1,1,0).
+- `shadows`, `midtones`, `highlights`.
+- Zone boundaries: `shadowsStart` (default 0), `shadowsEnd` (default 0.3), `highlightsStart` (default 0.55), `highlightsEnd` (default 1). All `MinFloatParameter`, min 0.
+
+**Color Curves** (`ColorCurves`) — All `TextureCurveParameter`.
+- `master`, `red`, `green`, `blue` — default linear (0,0)→(1,1).
+- `hueVsHue`, `hueVsSat`, `satVsSat`, `lumVsSat` — default empty, neutral at 0.5.
+
+**Channel Mixer** (`ChannelMixer`) — All `ClampedFloatParameter`, -200–200.
+- `redOutRedIn` (default 100), `redOutGreenIn` (default 0), `redOutBlueIn` (default 0).
+- `greenOutRedIn` (default 0), `greenOutGreenIn` (default 100), `greenOutBlueIn` (default 0).
+- `blueOutRedIn` (default 0), `blueOutGreenIn` (default 0), `blueOutBlueIn` (default 100).

package/.claude/skills/validate-urp-render-graph-renderer-feature/SKILL.md

@@ -0,0 +1,269 @@
+---
+name: validate-urp-render-graph-renderer-feature
+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.
+---
+# 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 `PassData` as transient per-recording data, not persistent state
+- avoiding partial initialization of pooled pass data objects
+
+### 4. Render Graph Descriptor Validation
+Check that:
+- the implementation does **not** create a new `TextureDesc` by default when an appropriate graph-derived descriptor can be used directly
+- when a texture should match the active render target, the descriptor is sourced from the relevant render graph resource first, such as:
+  - `resourceData.activeColorTexture.GetDescriptor(renderGraph)`
+  - or another appropriate existing graph-backed resource
+- only the fields that actually need to differ are modified after sourcing the descriptor
+- descriptor fields such as name, depth bits, format, and MSAA are intentionally preserved or intentionally overridden
+- any manual reconstruction of descriptor data is justified by a specific requirement
+
+Flag as an issue when:
+- the code creates a fresh `TextureDesc` without first attempting to reuse a graph-derived descriptor
+- width and height are manually copied into a new descriptor structure by default
+- `cameraTargetDescriptor` is used as the primary source when a render-graph-derived descriptor is available and more accurate
+- important properties such as MSAA, graphics format, or compatibility with the active render target are dropped accidentally
+- descriptor reconstruction is used as a convenience shortcut rather than a necessary divergence from the source resource
+
+Preferred rule:
+- **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.**
+
+Preferred pattern:
+1. get the descriptor from the relevant render graph resource
+2. modify only the fields that must change
+3. create the texture from that derived descriptor whenever possible
+
+Examples:
+
+#### Preferred
+```csharp
+RenderTextureDescriptor desc = resourceData.activeColorTexture.GetDescriptor(renderGraph);
+desc.depthBufferBits = 0;
+desc.name = "New name";
+// other desired paramters
+passData.targetTexture = renderGraph.CreateTexture(desc);
+```
+
+### 5. Manual Copy Pass Simplification
+Check that:
+- simple texture copy operations are not implemented as full custom raster passes when a built-in Render Graph helper is sufficient
+- passes that only read one texture and write it unchanged to another target are simplified where appropriate
+- the implementation prefers the most appropriate built-in helper for the target API/platform context
+- `AddCopyPass(...)` is not recommended by default if a more compatible `AddBlitPass(...)` overload should be preferred in the current environment
+
+Flag as an issue when:
+- a raster pass exists only to copy one texture into another
+- the pass uses no material and no custom processing
+- the render function only performs a simple blit/copy equivalent
+- the implementation uses a full custom raster pass where a built-in copy/blit helper would express the same behavior more directly
+
+Prefer:
+- the appropriate `AddBlitPass(...)` overload for straightforward copy-like operations when that is the recommended and more compatible path
+- `AddCopyPass(...)` only when it is explicitly appropriate and supported for the target API/platform context
+- a custom raster pass only when the copy requires additional logic or non-trivial behavior
+
+### 6. Manual Blit Pass Simplification
+Check that:
+- straightforward fullscreen material blits are not implemented as custom raster passes when `renderGraph.AddBlitPass(...)` would express the same behavior more directly
+- custom raster passes are only used for blits when additional logic or non-trivial behavior is actually required
+- simple source-to-destination material blits use the most direct render graph helper available
+
+Flag as an issue when:
+- a raster pass reads one source texture and writes one destination texture
+- the pass uses a material but no additional custom pass logic
+- the render function only performs a simple fullscreen blit
+- `renderGraph.AddBlitPass(...)` would provide an equivalent result more clearly
+
+Prefer:
+- `renderGraph.AddBlitPass(...)` for straightforward fullscreen material blits
+- a custom raster pass only when extra logic, multiple operations, conditional behavior, or special setup is actually required
+
+### 7. Global Resource Exposure
+Check that:
+- textures and buffers are not exposed globally unless explicitly requested or clearly required by a downstream consumer
+- when global exposure is required in a render graph pass, the implementation uses the appropriate render graph publication mechanism
+- direct command buffer global state mutation is not used as a substitute for render graph resource publication
+- global exposure is not extending resource lifetime unnecessarily or reducing aliasing opportunities without justification
+
+Flag as an issue when:
+- `SetGlobalTextureAfterPass` is used without a clear consumer
+- `context.cmd.SetGlobalTexture(...)` is used inside a render graph pass where render graph resource publication is the appropriate mechanism
+- global exposure is used as a convenience shortcut instead of explicit pass-to-pass wiring
+- hidden coupling is introduced unnecessarily
+- 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
+
+Prefer:
+- no global exposure by default
+- explicit resource wiring where possible
+- `builder.SetGlobalTextureAfterPass(...)` only when global publication is truly required in render graph
+- resource lifetimes that remain as local and short-lived as possible
+
+### 8. Renderer Feature Input Declaration
+Check that:
+- the `ScriptableRendererFeature` and its associated pass declare required pipeline inputs using `ConfigureInput(...)` when needed
+- the requested input flags match the feature’s intended behavior and visible resource usage
+- the pass does not rely on pipeline-provided inputs without declaring them when required by the target API pattern
+- unnecessary input requests are not declared by default, especially when they may introduce extra copies, intermediate resources, or avoidable pipeline work
+
+Flag as an issue when:
+- the feature’s pass uses or is clearly intended to use a pipeline-provided input but does not declare it with `ConfigureInput(...)`
+- `ConfigureInput(...)` requests inputs that the feature/pass does not appear to use
+- the declared input flags do not match the intended effect behavior
+- the effect description, code, and declared inputs imply conflicting requirements
+- unnecessary declared inputs may force extra copies, extra pass work, or other avoidable performance costs
+
+Classification guidance:
+- mark as a **confirmed issue** when the code clearly shows a required input is used but not declared
+- mark as a **likely issue** when the intended effect implies a required input but the visible code does not fully prove shader/resource usage
+- treat unnecessary input declarations as higher severity when they are likely to introduce additional copies or other measurable runtime cost
+
+## Guardrails
+The skill must:
+- avoid inventing unsupported APIs
+- distinguish **confirmed** issues from **likely** issues
+- prefer minimal targeted fixes over broad rewrites
+- explain why each issue matters
+- flag hidden coupling and unnecessary global state
+- state when the provided code is insufficient for full certainty
+
+## Non-Goals
+- guarantee runtime correctness
+- rewrite the entire renderer feature unless necessary
+- validate unrelated gameplay logic
+- validate shader internals unless directly relevant to pass wiring or binding
+
+## Evaluation Criteria
+A successful validation should:
+- catch real wiring and API issues
+- identify suspicious but plausible mistakes
+- provide actionable fixes
+- avoid false certainty
+- improve trust in generated render pass code
+
+## Notes for Future Expansion
+As new recurring issues are discovered, extend this checklist with additional rules such as:
+- pass ordering / injection point validation
+- resource lifetime and cleanup checks
+- read/write hazard detection
+- unnecessary copies or allocations
+- camera depth/color dependency validation
+- multi-pass dependency validation
+- override material correctness
+- pass configuration

package/.claude/skills/work/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: work
+description: Runs end-to-end Unity feature, bug-fix, refactor, tooling, content-integration, or other concrete project work. Routes by domain and risk, composes specialist roles, verifies independently, synchronizes records, and closes configured gates.
+allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, WebSearch, WebFetch
+---
+
+# Work
+
+Complete the approved outcome rather than stopping at a plan.
+
+## Route
+
+Read project policy and state, inspect Git status, and classify FAST, STANDARD, or CONTROLLED using [classification](references/classification.md). Identify affected domains before selecting roles from `../../nccgs/studio.json`.
+
+- FAST normally stays in the main session or uses one specialist.
+- STANDARD uses a context packet, an accountable implementer, and independent verification.
+- CONTROLLED adds the relevant decision owner and adversarial review.
+
+Read the [orchestration protocol](../../nccgs/protocols/orchestration.md) for multi-role work. Do not build a ceremonial management chain.
+
+## Contract
+
+Use [feature contracts](references/feature-contracts.md). Create or refresh a context packet through `/context-pack` for STANDARD or CONTROLLED work. Resolve Product Owner decisions that affect semantics, scope, canon, compatibility, dependencies, or irreversibility; continue safe independent nodes while decisions are pending.
+
+## Execute
+
+Build a dependency graph with one writer per path. Route distinct domains to their specialists. Use official Unity Skills for operation mechanics and `unity-cli` for connected Editor, tests, builds, and runtime evidence. Agents receive the context packet path and bounded ownership, not the entire chat or document set.
+
+Fix in-scope failures, inspect the final diff, and preserve unrelated work.
+
+## Verify and close
+
+Use [verification](references/verification.md) and the shared [evidence protocol](../../nccgs/protocols/evidence.md). Map objective evidence to requirements, run proportional regression, and separate PO gates. CONTROLLED work receives `/review` or `/evidence-review` from an independent role.
+
+Synchronize state and technical records, then run `/closure`. Report classification, roles/models used, changed files, evidence, blockers, PO gates, residual risk, and final state.
+

package/.claude/skills/work/references/classification.md

@@ -0,0 +1,41 @@
+# Task classification
+
+Use the lowest tier that safely covers the actual risk.
+
+## FAST
+
+Use when the intended behavior is unambiguous, impact is local, rollback is easy,
+and no durable contract changes.
+
+Examples: localized bug fix, safe refactor, editor utility, typo, missing reference,
+small visual correction, test repair that preserves intent.
+
+Minimum flow: inspect -> implement -> relevant test/verification -> diff -> report.
+
+## STANDARD
+
+Default for ordinary features and multi-file behavior changes with established
+design and architecture.
+
+Signals: new player-visible behavior, a meaningful requirement, several coordinated
+files, new tests/runtime scenario, or documentation/evidence that must persist.
+
+Flow: focused contract -> impact check -> implement -> automated/runtime evidence ->
+targeted regression -> docs/state sync -> closure.
+
+## CONTROLLED
+
+Use only when at least one material risk applies:
+
+- public or cross-system architecture contract;
+- save, serialization, network authority, protocol, or compatibility change;
+- package, service, platform, render-pipeline, or major project-setting decision;
+- broad or irreversible migration;
+- core gameplay design ambiguity or extensive blast radius;
+- security, commerce, account, privacy, or release-critical behavior.
+
+Flow adds explicit impact analysis, recorded decisions/ADR where durable, migration
+and rollback planning, full relevant verification, and independent review.
+
+File count alone does not make work CONTROLLED. Raise a tier when new facts expose
+risk; record the reason in state/closure.

package/.claude/skills/work/references/closure.md

@@ -0,0 +1,50 @@
+# Closure
+
+Keep state vocabulary exact:
+
+- IMPLEMENTED: change exists.
+- VERIFIED: required objective evidence passes.
+- VALIDATED: required subjective gates are accepted.
+- DONE: every configured closure gate is satisfied; waivers have explicit authority.
+
+## Canonical record and linked artifacts
+
+For persistent STANDARD/CONTROLLED work, write the canonical record at the path
+configured by `closure.canonical_record`, normally
+`.nccgs/closures/<feature-id>.md`. It is the single entry point for requirement
+coverage, implementation, evidence, documents, gates, waivers, and final state.
+
+The record may link additional project-required artifacts. Link them instead of
+copying their contents. Examples include an implementation report, register entry,
+manual evidence, migration log, recovery checklist, or deletion-safety gate.
+
+## Closure modes
+
+- **lean**: the canonical record is sufficient. Linked artifacts are optional and
+  cannot become blocking unless policy changes mode.
+- **linked**: artifacts with `required: true` must exist, be linked, and meet their
+  configured completion rule. Optional artifacts remain advisory.
+- **strict**: every declared artifact and checklist condition is blocking. A missing
+  item prevents DONE unless the PO records an explicit waiver and accepted risk.
+
+Unknown or missing mode is a configuration blocker for closure; do not silently
+assume lean in an already-migrated project.
+
+## Gate evaluation
+
+Before DONE:
+
+1. confirm implementation and objective verification;
+2. resolve applicable manual PO gates;
+3. inspect `closure.required_artifacts` and record each path, completion rule,
+   observed status, and waiver authority;
+4. ensure the canonical record links every required artifact;
+5. keep the final state below DONE while a blocking item remains.
+
+Update `.nccgs/state.md` to contain only current objective, active feature/tier,
+current phase, pending PO decisions, manual gates, closure blockers, last closure,
+and next candidate. Git and closure records hold history.
+
+Technical records may be synchronized autonomously. Canonical player-facing design
+changes require an accepted PO decision. If code and canon disagree, fix or escalate;
+never rewrite canon silently.

package/.claude/skills/work/references/feature-contracts.md

@@ -0,0 +1,32 @@
+# Focused feature contracts
+
+A feature contract records approved outcome and scope. Its context packet records the
+current working-set map; neither is a rewritten GDD.
+
+For meaningful STANDARD or CONTROLLED work, create or update
+`.nccgs/features/<feature-id>.md` from the scaffold template. Include only:
+
+- objective and approved player-facing intent;
+- relevant requirement IDs and links to canonical sections;
+- governing project policies and ADRs;
+- affected systems and expected files, without treating the list as immutable;
+- out-of-scope behavior;
+- objective acceptance and subjective gates;
+- verification and regression obligations;
+- open PO decisions.
+
+Create or refresh `.nccgs/context/<feature-id>.yaml` for the exact canonical sections,
+decision summaries, source revisions, ownership, and execution working set. Keep the
+contract stable across implementation while the context packet may change as the
+working set is discovered.
+
+Do not copy whole design or architecture documents. If discovery changes the working
+set, update the contract rather than loading unrelated sources.
+
+FAST work normally uses an in-memory contract. Persist it when the fix changes a
+meaningful requirement, spans sessions, needs a manual gate, or will benefit future
+debugging.
+
+Requirement IDs belong in `.nccgs/requirements.yaml` only for player-visible
+contracts, technical invariants, acceptance criteria, and cross-system dependencies.
+Do not assign IDs to private class structure or every documentation sentence.

package/.claude/skills/work/references/verification.md

@@ -0,0 +1,26 @@
+# Verification strategy
+
+Choose evidence that directly proves the requirement.
+
+| Evidence | Proves | Does not prove |
+|---|---|---|
+| Static/diff inspection | Structure and obvious policy conformance | Runtime behavior |
+| EditMode test | Deterministic logic/editor behavior | Full scene/player experience |
+| PlayMode test | Unity lifecycle and runtime integration | Subjective feel |
+| Unity CLI runtime inspection | Actual state, references, errors, deterministic transitions | Broad regression or subjective quality |
+| Build | Target compilation/packaging | Feature correctness by itself |
+| PO gate | Subjective intended experience | Technical regression coverage |
+
+For each acceptance criterion, classify evidence:
+
+- **PASS**: direct evidence demonstrates it;
+- **FAIL**: evidence contradicts it;
+- **NOT PROVEN**: no adequate evidence exists;
+- **PO GATE**: the criterion is intentionally subjective.
+
+Run regression based on changed contracts and downstream consumers. A local bug fix
+needs targeted regression; release or core contract work may justify a broader suite.
+
+When Unity is involved, use the relevant official Unity Skill and `unity-cli`. Prefer
+connected Editor observation/action/verification when available. Persist only useful
+evidence summaries; do not dump console walls into closure records.