race-condition

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.

Use when a runner agent needs to manage athletic performance during a race tick: accelerating, braking, or reading current vitals (speed, energy, hydration, exhaustion). Triggered every tick the runner is active.

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 simulator finishes its race-tick loop and must wrap up: compiling final results from tick snapshots, stopping the RaceCollector, and reporting outcomes to other agents. Triggered once per simulation, after the last tick.

Use when the simulator receives a validated plan from the planner and must initialize the race: parsing the plan, spawning runner agents, starting the telemetry collector, and firing the start gun. Triggered once per simulation, before the first tick.

Use when running the simulator-with-failure test variant and the pre-race phase begins. The prepare_simulation tool intentionally raises RuntimeError to exercise the ADK and SimulationCommunicationPlugin tool_error callback path. Not intended for production simulations.

Use when an agent renders rich UI back to a client surface (cards, dashboards, forms, modals) using the A2UI v0.8.0 declarative protocol. Required whenever the response should display structured components rather than plain text, or whenever the validate_and_emit_a2ui tool is in scope.

Guides the developer workflow for contributing to Race Condition. Use when setting up pre-commit hooks, running tests before a PR, understanding code style requirements, or preparing a contribution.

Guides deployment of Race Condition to a GCP project. Use when deploying to the cloud, setting up infrastructure with Terraform, or troubleshooting a deployment. This is for cloud deployment -- for local development, use the getting-started skill instead.

Explains the Race Condition architecture, the design decisions behind it, and where to read code first. Use when the developer asks how something works, wants a tour, or wants to understand the system before changing it.

Guides setup of the Race Condition project from clone to running simulation. Use when the developer wants to get the project running locally, install dependencies, configure GCP credentials, or troubleshoot startup issues.