Prompt 1

Create the UI mockups before writing code.

I want to build a live odds widget for a betting website using odds-api.net.

Before writing code, create three UI mockups for an NBA moneyline odds widget.

Goal:
Design a compact widget that can sit inside a betting website and show upcoming games, teams, start times, bookmaker odds, and the best available price.

Requirements:
- Show upcoming NBA games.
- Focus on moneyline odds only for this first version.
- Use decimal odds.
- Use Australian sportsbooks/bookmakers in the mock data.
- Make the best available odds easy to identify.
- Keep the widget compact enough to embed on a betting website.
- Include clear states for:
  - loading
  - live/updating
  - no games available
  - stale or disconnected data
- Do not add unrelated betting tips, predictions, or extra analytics yet.
- Create three different visual options.
- Keep the UI clean, readable, and practical.

After creating the mockups:
1. Recommend the strongest option.
2. Explain why it is the best fit for a live odds widget.
3. List the exact fields the coding agent should build from the chosen mockup.

Prompt 2

Turn the selected mockup into a working odds widget with mock data.

Use the selected UI mockup/reference image to build a working live odds widget.

For this stage, use mock odds-api.net data only.

Goal:
Create the frontend and service structure for a live odds widget that can later switch from mock data to real odds-api.net data.

Requirements:
- Match the selected mockup closely.
- Only fill in the fields shown in the design.
- Use decimal odds.
- Use Australian sportsbooks/bookmakers in the sample data.
- Show upcoming NBA moneyline markets.
- Include:
  - event ID
  - home team
  - away team
  - start time
  - bookmaker
  - selection/team
  - decimal odds
  - best available odds per selection
  - last updated timestamp
- Use the odds-api.net MCP or existing project integration pattern if available.
- Use mock data first so no API credits are used during layout and interaction testing.
- Structure the code so the data source can be swapped to real odds-api.net calls later.
- Add a simple live update simulation so odds can change on screen.
- Add a visible status for connected, updating, stale, and disconnected states.
- Do not place bets.
- Do not scrape sportsbooks.
- Do not add arbitrage calculations.
- Keep the code simple and easy to extend.

Before writing code:
1. Inspect the project structure.
2. Identify where the widget should live.
3. List the files you plan to create or modify.
4. Then implement the widget.

After implementing:
- Run relevant tests or linting if available.
- If no tests exist, add a small test for the odds grouping/best-price display logic.
- Show me how to run the widget locally.

Prompt 3

Switch to real data, add fair odds highlighting, and validate it works.

We have a working live odds widget using mock odds-api.net data.

Now switch it to real odds-api.net data and add fair odds value highlighting.

Goal:
Use real upcoming events and odds from odds-api.net, stream or refresh live updates, and highlight prices where the best available odds are greater than the fair odds value.

Requirements:
- Do not rewrite the widget unless absolutely necessary.
- Replace mock data with real odds-api.net requests.
- API keys must come from environment variables. Do not hardcode secrets.
- Use the odds-api.net MCP, package, SDK, or cleanest existing integration pattern in the project.
- Pull upcoming NBA events first.
- Pull moneyline odds from available bookmakers.
- Use decimal odds only.
- Include the fair odds field if available from odds-api.net.
- For each selection:
  - identify the best available bookmaker price
  - compare best available odds against fair odds
  - highlight the price when best available odds are greater than fair odds
- Make the value highlight clear but not misleading.
- Label it as a potential value opportunity, not a guaranteed profitable bet.
- Keep showing last updated timestamps.
- Add stale data handling:
  - show when odds have not updated recently
  - show when the stream disconnects
  - reconnect or fall back to polling if the existing project pattern supports it
- Validate the request flow:
  - upcoming events request
  - odds snapshot request
  - streaming or refresh request
- Add logging for request count, events loaded, odds entries loaded, stream updates, stale data, and errors.
- Add basic error handling for missing API keys, empty events, empty odds, malformed responses, rate limits, and stream failures.
- Do not place bets.
- Do not add arbitrage detection yet.
- Do not add a full betting strategy.

After implementing:
1. Run tests or linting.
2. Confirm the widget renders real events.
3. Confirm odds update live or refresh correctly.
4. Spot-check at least one displayed price against the source data.
5. Explain any limitations or places where the widget can still break.