Before calling any timing failure a flake, diff the PR for changed timing constants. The test was not flaky: the PR raised the debounce delay past the test's wait budget, so the first attempt fails every time. Match the test's wait to the new debounce value, or better, stop asserting on wall-clock timing at all.

```text
the agent treated a debounce-timing failure as a flake  -  the debounce value had changed in the PR under test
```

## Steps

1. Diff the PR for timing constants first: search the changed files for debounce, delay, wait, timeout, and setTimeout values, and note any that grew or were introduced.

   Expected: You find the changed constant, e.g. a debounce raised from 150ms to 400ms.

2. Compare the new debounce value against what the test actually waits for before asserting. If the test waits less than the new delay, the failure is deterministic, not flaky.

   Expected: The numbers make the cause obvious: test waits 200ms, debounce now needs 400ms.

3. Prove it by rerunning the test against the old debounce value (temporarily restore it). It should pass consistently, confirming the constant is the cause.

   Expected: Green on the old value, red on the new value, every run.

4. Fix the test by waiting on the element or state the debounce produces, not on a fixed sleep - use the framework's wait-for helper keyed to the debounced outcome.

   Expected: The test waits for the actual UI state and passes regardless of the debounce value.

5. Add a guard to the agent's triage checklist: before labeling a timing failure a flake, it must list every timing constant the PR changed.

   Expected: The agent's triage notes name the debounce change instead of saying flake.

## Use this when

- an agent says flake but the failure started exactly when a PR landed
- a test fails on first attempt with timing-sensitive assertions after a UI change
- debounce, throttle, or delay values appear anywhere in the PR diff

## Not for this skill when

- the failure happens with no code change at all (that is a real flake)
- the test is slow for everyone and no timing constant changed (that is a perf regression)
- you are tuning the debounce value itself for product reasons

## Variant phrasings

- agent said flaky but the debounce delay changed in the PR
- test started failing right after someone changed the debounce constant
- how to tell a real flake from a timing constant change in the PR under test

## Why it happens

Debounce exists to swallow rapid input by waiting for a quiet period before firing. A test that sleeps a fixed 200ms and then asserts the debounced result passes only while the debounce stays under 200ms. When the PR raises the debounce to 400ms, the assertion runs before the debounced action fires, so the test fails deterministically. The agent sees pass-on-old-code and fail-on-new-code and reaches for the flake label, but nothing is intermittent: the timing budget just no longer covers the delay.

## Edge cases

- If the debounce value is read from config or a feature flag, the test should read the same config instead of hardcoding a wait.
- Some frameworks debounce with requestAnimationFrame counts instead of milliseconds; the same logic applies - assert on the outcome, not the clock.
- If the test genuinely needs a fixed wait, define it as a named constant next to the debounce value so the two stay in sync.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5jgxtj5xjKxENGrCgrqT5g