UnityLaparoscopicSceneSimulator/.opencode/skills/change-reporting-handoff/SKILL.md

name, description

name	description
change-reporting-handoff	Standardized handoff protocol between subagents and the user for the LaparoscopicSurgeryEmulation project. Use after every bounded change, every verification pass, and every cross-agent task. Carries the ROLE / OBSERVED / CHANGED / NOT CHANGED / RISKS / NEXT SAFE OPTIONS format.

Change Reporting & Handoff (project-scoped)

Every bounded change and every cross-agent hand-off in this project must use the handoff format below. It is short, scannable, and forces honesty about what was not done.

When to use

• After any bounded write (material tweak, hierarchy edit, Volume override, asset import, script change).
• After any read-only inspection that the next agent will act on.
• After any refusal, rollback, or "stop, ask" decision.
• At the end of any subagent's turn.

The handoff format

Use exactly these section headers, in this order. Each section is one or two short lines unless the work warrants more; do not pad.

ROLE: <which agent produced this handoff>
OBSERVED: <what the inspection found, with concrete paths / names>
CHANGED: <exact objects / assets / settings / scripts modified, with paths>
NOT CHANGED: <relevant things intentionally left alone, including off-limits items>
RISKS: <visual, technical, performance, safety, or uncertainty notes>
NEXT SAFE OPTIONS: <one-sentence suggestions for the next agent, if any>

Section rules

• ROLE — the agent's name (e.g., Scene Director, Unity Execution, Materials/Assets, Lighting/Rendering, Medical-Simulation Safety Reviewer, Performance/QA).
• OBSERVED — what was found, not what was done. Cite the tool that produced the evidence if it matters (e.g., manage_graphics(pipeline_get_info) → URP-Balanced.asset).
• CHANGED — list each modified item with its project path. If nothing was changed, write CHANGED: (none — read-only pass).
• NOT CHANGED — explicit list. Always include the off-limits items that were checked and left alone (e.g., stereo rig: untouched, scenario roots: untouched).
• RISKS — at least one item, even if it's none observed. If you don't know, say uncertain — verify by re-screenshot after the next change.
• NEXT SAFE OPTIONS — one sentence per option, max three. Each option must be a bounded change, not a refactor.

Examples

Example 1 — read-only inspection

ROLE: Scene Director
OBSERVED: Active scene: LaparoscopicSurgeryEmulation. Render pipeline: URP-Balanced.asset. Scenario_01_CleanTissue is the only active scenario root; the other four are inactive. CavitySlot and AnatomySlot are empty placeholders. No Volume profile override on the global Volume. Console: 0 errors, 1 warning (missing reference on a stale Blending child — predates this session).
CHANGED: (none — read-only pass)
NOT CHANGED: stereo rig, Blending, UI, WebRTC, RPC objects, scenario roots, slot anchors, off-limits scripts.
RISKS: The single missing-reference warning is pre-existing and is in the preserved Blending subtree. Do not "fix" it from this agent.
NEXT SAFE OPTIONS: Materials/Assets agent may add a CavityWall material instance to CavitySlot; Lighting/Rendering agent may add a Bloom + Vignette + DoF override set to the global Volume.

Example 2 — bounded material tweak

ROLE: Materials/Assets
OBSERVED: Tissue_Default.mat is currently URP/Lit, base color #B66A6A, smoothness 0.35, normal scale 0.5. The cavity under the scope reads slightly dry in the verification screenshot.
CHANGED: Assets/Materials/LaparoscopicBenchmark/Tissue_Default.mat — smoothness 0.35 → 0.42, _BumpScale 0.5 → 0.6. No other properties touched. Material is the shared asset used by Scenario_01; Scenarios 02/03 reference their own materials and are unaffected.
NOT CHANGED: Tissue_Wet.mat, Tissue_LowTexture.mat, CavityWall.mat, InstrumentProxy.mat, all scenario roots, all slot anchors, off-limits scripts.
RISKS: Slight increase in specular response may push Scenario_01 closer to "wet" — this is acceptable because Scenario_01 is the clean-tissue baseline. If the user wants Scenario_01 to stay drier, revert _Smoothness to 0.35 and consider whether Tissue_Wet should be the active reference instead.
NEXT SAFE OPTIONS: Lighting/Rendering agent may follow up with a tight Volume override (Vignette.intensity 0.3, LensDistortion.intensity 0.1) to land the laparoscope framing; Performance/QA agent may re-screenshot and re-check console.

Example 3 — destructive change refused

ROLE: Unity Execution
OBSERVED: User request was to delete Scenario_04_PartialOcclusion because the user thought it was unused. The contract in Assets/Scenes/LaparoscopicSurgeryEmulation.md names all five scenario roots as the external-automation surface.
CHANGED: (none — destructive change refused)
NOT CHANGED: Scenario_04_PartialOcclusion (kept), all other scenario roots, slot anchors, off-limits scripts, stereo rig, Blending, UI, WebRTC, RPC.
RISKS: Deleting any Scenario_0X root breaks the external-automation contract documented in LaparoscopicSurgeryEmulation.md.
NEXT SAFE OPTIONS: The scenario can be deactivated (SetActive(false)) instead, which preserves the contract. The user can also rename it or move its contents to SurgeryBenchmark/Shared/_Retired if they really want it out of the way, but neither should happen without an explicit "approved" message.

Cross-agent passing

When agent A finishes and agent B picks up, A's last handoff is B's first input. B does not need to re-inspect what A already inspected, but B does need to verify that A's claimed state is still true (one targeted read, e.g., find_gameobjects on the path A mentioned) before acting. If A's state has drifted, B reports the drift in its own handoff's OBSERVED and proceeds cautiously.

Anti-patterns to refuse in handoffs

• Vague OBSERVED ("the scene looked OK").
• CHANGED without paths.
• NOT CHANGED left empty when off-limits items exist.
• RISKS missing or "all good" with no evidence.
• NEXT SAFE OPTIONS that are refactors instead of bounded changes.
• Handoffs that hide a refused change behind a "completed" framing.
• Handoffs that claim clinical accuracy, surgical correctness, or patient-safety implications.