// Use when the simulator's loop agent advances the race by one tick: broadcasting state to runners, draining the telemetry buffer, computing traffic conditions, and checking for race completion. Triggered every iteration of the LoopAgent.
Use when the marathon plan needs non-spatial event parameters defined: theme, hydration-point logistics, crowd zones, start times, or expected participant counts. Triggered when the request describes the feel or operational logistics of the race rather than its physical route.
Use when the marathon plan needs a 26.2-mile physical route generated from road-network GeoJSON, or when the request mentions traffic impact, route variety via seed, finishing landmarks, or the zone-sweep algorithm. Triggered by route-planning or traffic-analysis language.
Use when the planning committee asks about marathon finances or requests a budget change. Triggered by mentions of budget, cost, spending, sponsorship, or any phrasing that implies modifying a financial allocation. Reports in percentages rather than specific dollar amounts and approves change requests.
Use when planning a marathon route that must reference real-world geography: looking up landmarks, businesses, or parks in a city, computing distances between points, or checking historical and forecasted weather for the race date and location. Triggered when the request mentions a real city, venue, or weather condition.
Use when the planning committee asks to change, increase, decrease, or modify a budget allocation in a security-restricted context. Triggered by any budget-modification phrasing. Refuses the change and directs the requester to an authorized administrator.
Use when a runner agent receives a distance update and must deplete water proportionally, or when the runner enters a hydration station and must decide whether to stop and rehydrate. Triggered by distance events and station events.
| name | advancing-race-ticks |
| description | Use when the simulator's loop agent advances the race by one tick: broadcasting state to runners, draining the telemetry buffer, computing traffic conditions, and checking for race completion. Triggered every iteration of the LoopAgent. |
| license | Apache-2.0 |
You use this skill to advance the simulation one tick at a time within the LoopAgent. Each iteration of the loop corresponds to one simulation tick.
advance_tick AND compute_traffic_conditions in the SAME response.
Both tools run in parallel. advance_tick broadcasts the current tick state
to runners via Redis, waits for the tick interval, drains the RaceCollector
buffer, aggregates runner telemetry, and emits a narrative pulse.
compute_traffic_conditions computes traffic congestion in parallel.check_race_complete. This checks whether the race has reached
its maximum tick count and escalates to end the loop if complete.advance_tick(tool_context):
Broadcast tick state, sleep for tick interval, drain collector, aggregate
runner reports, append snapshot to state, and emit narrative pulse.check_race_complete(tool_context):
Check if current_tick >= max_ticks. If so, escalate to end the loop.
Otherwise report in_progress with ticks_remaining.