Exit Tracking Popup

When to invoke

After the agent has been on the page for a few seconds and is about to navigate away (or after a scroll-pattern that triggers exit-intent JS), a "Wait!" overlay appears trying to keep them. The dismiss controls are typically a small "x", a "no thanks" link, or Escape.

The matcher fires this skill when exit-intent markers are present and the page is not in initial-load.

Recipe

1. wait extra=200ms
2. try_each selectors=[ "[class*='exit-intent' i] button[aria-label*='close' i]", "[data-exit-intent] button[aria-label*='close' i]", "[class*='abandonment' i] button[aria-label*='close' i]", "[class*='discount-popup' i] button[aria-label*='close' i]", "[class*='exit-intent' i] button:has-text('No thanks')", "[class*='exit-intent' i] button:has-text('I'm not interested')", "[class*='abandonment' i] button.btn-close", "[data-exit-intent] button.dismiss", ] action=click on_success=stop timeout=1000ms
3. press_key key=Escape

Success criteria

• assert no_visible_element selector="[class*='exit-intent' i]" OR no_change_was_needed

When NOT to use

• The user is interested in the offer. Don't auto-dismiss.

Known failures

• Exit-intent popups that block scroll until clicked: dismissal must be clicking the visible close, not Escape.
• Exit-intent popups that DOM-remove themselves on second hover: the recipe runs while it's still attached; later state is fine.
• Exit-intent popups stacked behind other popups: dismiss newsletter/modal first, then exit-intent.

Related skills

• dismiss-newsletter-popup — sibling skill; matcher orders by signal strength
• handle-modal-dialog — generic dialog parent