diff --git a/.agents/skills/uloop-wait-for-pause-point/SKILL.md b/.agents/skills/uloop-wait-for-pause-point/SKILL.md index d899a4f0ff..42eacca8be 100644 --- a/.agents/skills/uloop-wait-for-pause-point/SKILL.md +++ b/.agents/skills/uloop-wait-for-pause-point/SKILL.md @@ -1,6 +1,6 @@ --- name: uloop-wait-for-pause-point -description: "Standard paused-frame proof for Unity PlayMode/E2E gameplay verification. Whenever you verify behavior driven by simulate-* input, physics, or UI events, pause at least one representative state transition with a pause point and inspect the frozen frame like an IDE breakpoint. simulate-* Success=true, action logs, screenshots, sleeps/retries, and final durable state supplement but do not replace this paused-frame proof." +description: "An alternative to IDE breakpoints. Temporarily pauses Unity and then inspects a specific frozen frame. Use this during bug investigations or PlayMode/E2E testing to examine variable states at specific frames or verify whether particular code has been executed." --- ## Quick Check Template @@ -42,7 +42,7 @@ Use `Generation`, `EnabledAtUtc`, and the hit sequence fields from the hit or st ## When To Use - Use this as the standard frame proof for state-changing PlayMode/E2E simulated input, physics, or UI transitions. -- Pause at least one representative transition per E2E pass, even if durable state, logs, or screenshots can later confirm the final result. +- Consider a pause point during E2E passes when transition-frame evidence would add confidence, even if durable state, logs, or screenshots can later confirm the final result. - Use this before reaching for `Time.timeScale`, sleeps, repeated polling, or after-the-fact `execute-dynamic-code`; those checks can supplement the paused-frame proof, but they are not substitutes. - If the value you need is a method local, an intermediate calculation, or a branch reason that `execute-dynamic-code` cannot reach, add a focused `Debug.Log` immediately before the marker and read it with `get-logs` while paused. Do not count the breakpoint check complete until the matching log has been read. - Good pause points include after input is consumed, a command is accepted, a state mutation is committed, an evaluation step resolves, a tracked value changes, a UI/domain state syncs, or a success/failure/end condition is entered. diff --git a/.claude/skills/uloop-wait-for-pause-point/SKILL.md b/.claude/skills/uloop-wait-for-pause-point/SKILL.md index d899a4f0ff..42eacca8be 100644 --- a/.claude/skills/uloop-wait-for-pause-point/SKILL.md +++ b/.claude/skills/uloop-wait-for-pause-point/SKILL.md @@ -1,6 +1,6 @@ --- name: uloop-wait-for-pause-point -description: "Standard paused-frame proof for Unity PlayMode/E2E gameplay verification. Whenever you verify behavior driven by simulate-* input, physics, or UI events, pause at least one representative state transition with a pause point and inspect the frozen frame like an IDE breakpoint. simulate-* Success=true, action logs, screenshots, sleeps/retries, and final durable state supplement but do not replace this paused-frame proof." +description: "An alternative to IDE breakpoints. Temporarily pauses Unity and then inspects a specific frozen frame. Use this during bug investigations or PlayMode/E2E testing to examine variable states at specific frames or verify whether particular code has been executed." --- ## Quick Check Template @@ -42,7 +42,7 @@ Use `Generation`, `EnabledAtUtc`, and the hit sequence fields from the hit or st ## When To Use - Use this as the standard frame proof for state-changing PlayMode/E2E simulated input, physics, or UI transitions. -- Pause at least one representative transition per E2E pass, even if durable state, logs, or screenshots can later confirm the final result. +- Consider a pause point during E2E passes when transition-frame evidence would add confidence, even if durable state, logs, or screenshots can later confirm the final result. - Use this before reaching for `Time.timeScale`, sleeps, repeated polling, or after-the-fact `execute-dynamic-code`; those checks can supplement the paused-frame proof, but they are not substitutes. - If the value you need is a method local, an intermediate calculation, or a branch reason that `execute-dynamic-code` cannot reach, add a focused `Debug.Log` immediately before the marker and read it with `get-logs` while paused. Do not count the breakpoint check complete until the matching log has been read. - Good pause points include after input is consumed, a command is accepted, a state mutation is committed, an evaluation step resolves, a tracked value changes, a UI/domain state syncs, or a success/failure/end condition is entered. diff --git a/Packages/src/Editor/CliOnlyTools~/PausePoint/Skill/SKILL.md b/Packages/src/Editor/CliOnlyTools~/PausePoint/Skill/SKILL.md index d899a4f0ff..42eacca8be 100644 --- a/Packages/src/Editor/CliOnlyTools~/PausePoint/Skill/SKILL.md +++ b/Packages/src/Editor/CliOnlyTools~/PausePoint/Skill/SKILL.md @@ -1,6 +1,6 @@ --- name: uloop-wait-for-pause-point -description: "Standard paused-frame proof for Unity PlayMode/E2E gameplay verification. Whenever you verify behavior driven by simulate-* input, physics, or UI events, pause at least one representative state transition with a pause point and inspect the frozen frame like an IDE breakpoint. simulate-* Success=true, action logs, screenshots, sleeps/retries, and final durable state supplement but do not replace this paused-frame proof." +description: "An alternative to IDE breakpoints. Temporarily pauses Unity and then inspects a specific frozen frame. Use this during bug investigations or PlayMode/E2E testing to examine variable states at specific frames or verify whether particular code has been executed." --- ## Quick Check Template @@ -42,7 +42,7 @@ Use `Generation`, `EnabledAtUtc`, and the hit sequence fields from the hit or st ## When To Use - Use this as the standard frame proof for state-changing PlayMode/E2E simulated input, physics, or UI transitions. -- Pause at least one representative transition per E2E pass, even if durable state, logs, or screenshots can later confirm the final result. +- Consider a pause point during E2E passes when transition-frame evidence would add confidence, even if durable state, logs, or screenshots can later confirm the final result. - Use this before reaching for `Time.timeScale`, sleeps, repeated polling, or after-the-fact `execute-dynamic-code`; those checks can supplement the paused-frame proof, but they are not substitutes. - If the value you need is a method local, an intermediate calculation, or a branch reason that `execute-dynamic-code` cannot reach, add a focused `Debug.Log` immediately before the marker and read it with `get-logs` while paused. Do not count the breakpoint check complete until the matching log has been read. - Good pause points include after input is consumed, a command is accepted, a state mutation is committed, an evaluation step resolves, a tracked value changes, a UI/domain state syncs, or a success/failure/end condition is entered.