> For the complete documentation index, see [llms.txt](https://momon-wonder.gitbook.io/comprehensive-rules-1.0.0/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://momon-wonder.gitbook.io/comprehensive-rules-1.0.0/abilities-and-game-state/11-abilities-trigger-queue-and-continuous-effects/11-2-triggering-and-the-queue.md).

# 11.2 Triggering and the Queue

11.2.1 When an event satisfies a Triggered Ability’s condition, that Ability triggers but does not interrupt the event or current Ability.

11.2.2 Finish the current turn-based action or Ability, then perform State-Based Conditions.

11.2.3 Collect every trigger waiting from a completed event. A trigger can enter the Queue only once for each event that satisfies it unless its text says otherwise. Preserve the creating event's chronological position for its trigger group. A successful Effect-Based Summon creates the package in Section 9.3 at that Summon event's position, with the event's waiting triggers processed as part of its On Summon processing. Apply Section 11.3 to triggers from the same event.

11.2.4 The Trigger Queue resolves first in, first out within the pending event order. Resolve each Ability completely before moving to the next pending work. A pending Effect-Based Summon package retains its successful Summon event's position under Section 9.3; it is not placed behind all ordinary triggers regardless of when they occurred. Once that package is reached, complete its On Summon processing, Snatch Check, State-Based Conditions, and post-Snatch processing before resuming later pending event groups or packages. The package's current processing Queue is distinct from later deferred work; its ordinary triggers use the existing FIFO rule. No package interrupts an Ability already resolving. In sanctioned play, the Missed Trigger Remedy in the PROCEDURE AND PENALTY GUIDE may place a restored trigger at the front as an express tournament-remedy exception.

11.2.5 If new events occur while an Ability resolves, finish that Ability and perform State-Based Conditions. Preserve their chronological order and append each ordinary event's trigger group or successful Summon event's package at that event's position, after pending work that was already waiting before those events. Apply [Section 11.3](/comprehensive-rules-1.0.0/abilities-and-game-state/11-abilities-trigger-queue-and-continuous-effects/11-3-simultaneous-triggers.md) within a same-event trigger group. Do not extract ordinary triggers from later events and process them ahead of an earlier Summon package. If a package is already being processed, ordinary triggers generated during its current On Summon or post-Snatch processing use that processing Queue; nested Summon packages remain deferred until the current package finishes and retain their own chronological positions among the other deferred work. Later ordinary event groups already deferred outside the package do not join its current processing Queue.

11.2.6 Continue processing the Trigger Queue and pending Summon packages in the event order defined above and in Section 9.3 until both are empty before advancing to the next turn step.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://momon-wonder.gitbook.io/comprehensive-rules-1.0.0/abilities-and-game-state/11-abilities-trigger-queue-and-continuous-effects/11-2-triggering-and-the-queue.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.