Smart Cricket Scores & Matches

View saved version →

---
name: compare-player-profiles
description: Compare Cricket Explorer player biographies, reported roles, and batting or bowling styles when the user asks how selected players differ or wants a profile comparison. Use successful model-visible player details; do not use for career-statistics rankings, recent form, fantasy selection, or deciding who is the better performer.
---

# Compare Player Profiles

Build a comparison that helps the user understand the players' reported backgrounds and playing styles.

## Inputs and retrieval

1. Identify the players the user wants to compare. Resolve their identities from supplied IDs, returned player rows, or the latest `widgetState.modelContent.selectedPlayer`; confirm ambiguous names through a widget selection.
2. Reuse successful `structuredContent.selectedPlayer` detail responses already present in the conversation. For each missing profile with a known ID, call `open-cricket-explorer` with `reason`, `initialPanel: "players"`, and `playerId`.
3. Check each returned profile against the requested identity. Treat null selections and failed lookups as unresolved; do not substitute an unrelated list entry or interpret an opaque ID as proof of identity.
4. If an ID is unknown, open the Players panel with `reason` and `initialPanel: "players"`, then ask the user to select that player. Read the next model-visible selection. A name is not a supported search argument.
5. Retain the returned profiles and their IDs in the conversation as selections change. Widget state carries one selected player, not a history or a comparison collection. Do not claim access to the widget's local cache or call its app-only `get-cricket-data` tool.

## Compare the evidence

1. Align the reported fields: `country`, `role`, `battingStyle`, `bowlingStyle`, `dateOfBirth`, and `placeOfBirth`. Show unavailable values as unknown, including normalized text such as `Unknown country` or `Unknown player`.
2. Describe the differences in roles and styles using the reported labels. Explain unfamiliar labels briefly when useful, without turning a style into a claim about skill, tactics, success, or current team selection.
3. Keep country, birthplace, and nationality distinct. Do not fill missing country or role values from a name, flag, birthplace, or personal recollection.
4. Preserve source dates. Calculate ages only if requested and the birth dates and comparison date are trustworthy; include that comparison date.
5. State that the app supplies no career totals, averages, rankings, recent performances, or head-to-head statistics. Avoid declaring a better player from biographical fields.

## Deliverable

Provide a compact comparison table followed by the most useful supported similarities and differences. Distinguish missing fields from actual differences, and name any player whose lookup remains unresolved.

Describe the profiles as reported by CricketData and potentially cached for up to 24 hours. Keep any user-supplied facts separate from app-returned fields.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: cricket-results-digest
description: Produce a concise roundup of reported completed Cricket Explorer matches when the user asks for a series results digest, a recap of selected matches, or a shareable catch-up. Aggregate only returned match records; do not invent ball-by-ball narratives, standings, player performances, or complete tournament coverage.
---

# Cricket Results Digest

Organize the reported outcomes of a defined set of matches into a readable catch-up.

## Inputs and retrieval

1. Resolve the requested scope: one series, selected matches, or a stated date/team subset of returned rows. Reuse matches already present in model-visible tool results or `widgetState.modelContent.selectedMatch`.
2. For a series, use `structuredContent.selectedSeries.matches`. If only its summary or ID is visible, call `open-cricket-explorer` with `reason`, `initialPanel: "series"`, and the supplied or observed `seriesId`. Widget state alone does not contain that fixture list.
3. For missing individual details with known IDs, call `open-cricket-explorer` with `reason`, `initialPanel: "matches"`, and `matchId`. Check each returned `selectedMatch`; a null selection is an unresolved lookup.
4. If no entity ID is known, open the relevant panel with `reason` and `initialPanel`, then ask the user to select the series or match. Use its next model-visible selection. Do not invent search, date-filter, team-filter, or pagination arguments.
5. Keep `get-cricket-data` and Load more actions in the widget. Do not assume its local lists, filters, or cache are accessible to the model. Label a digest from a first-page list as covering returned rows only, including incomplete pagination when reported.

## Assemble the roundup

1. Deduplicate by match ID and keep a single coherent snapshot per match. Apply requested filters only where the returned fields support them. Disclose gaps or unresolved lookups.
2. Use `matchEnded` to identify records reported as completed, and read their `status` and `matchWinner`. Separate ongoing, upcoming, or contradictory records from confirmed entries in the digest. Treat `state` as derived context rather than proof of a final result.
3. Preserve draws, ties, abandonments, and no-results as stated. A missing winner does not mean a draw, and lower or higher innings totals alone do not establish an outcome or victory margin.
4. Summarize the reported status and relevant innings totals. Preserve innings labels, null scores, and `matchType: "unknown"`. Prefer `runs`, `wickets`, and `overs` over the derived score summary, which can render missing wickets as zero.
5. Sort by trustworthy match dates when useful, without inventing dates or years. If the ordering cannot be established, use a labeled source order.
6. Add only supported aggregate observations. A tally may count reported wins within this returned set; label it that way and keep unknown outcomes separate. Do not call it a series score, standings table, or complete tournament tally without evidence of coverage and the applicable competition rules.

## Deliverable

Provide a compact table of match, format, reported result, and relevant scores, followed by a short shareable recap if requested. Include a brief coverage note and identify omitted or unresolved records.

Describe the digest as a snapshot of CricketData records potentially cached for up to 24 hours. Tool response timestamps do not establish when upstream results were last updated. Keep player contributions, turning points, tactical causes, and ball-by-ball narratives outside the recap unless separately supplied by the user.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: explain-cricket-score
description: Explain the score, innings, overs notation, and reported result of a specific Cricket Explorer match when the user asks what the displayed score means or wants help following it. Use model-visible match data; do not trigger for general cricket rules without a match context or for ball-by-ball analysis.
---

# Explain Cricket Score

Turn one reported match snapshot into an explanation suited to the user's familiarity with cricket.

## Inputs and retrieval

1. Resolve the requested match from returned `structuredContent.selectedMatch`, a returned match row, or the latest `widgetState.modelContent.selectedMatch`. Use only context actually visible to the model.
2. If details are needed and an ID is supplied or observed, call `open-cricket-explorer` with `reason`, `initialPanel: "matches"`, and `matchId`. Read the returned `selectedMatch`; treat a null selection as a failed detail lookup.
3. If the identity is ambiguous, open the Matches panel with `reason` and `initialPanel: "matches"`, then ask the user to select the match. Use its next model-visible selection. Never invent IDs or pass names as IDs.
4. Keep `get-cricket-data` for the widget runtime. The model-facing tool has no search, pagination, or refresh-bypass arguments.

## Explain the snapshot

1. Identify the reported match type and status. Treat `matchType: "unknown"` as unavailable. Use `matchEnded`, `matchWinner`, and the status together; flag contradictions instead of inventing an outcome.
2. Explain each relevant `scoreLines` entry using its `inning`, `runs`, `wickets`, and `overs`. Prefer these fields to the derived `summary`: missing wickets can appear as zero in that summary, so preserve a null wicket count as unknown.
3. Decode runs and wickets, then explain overs as completed overs plus legal balls. For example, `18.4` means 18 overs and four balls, not 18.4 decimal overs. Treat missing or malformed overs as unavailable.
4. Explain the reported result or current position in plain language. Use the status for targets, leads, trails, and victory margins; totals alone may omit innings, revised targets, or other match conditions.
5. If the user requests a run rate, calculate it only from a valid runs value and unambiguous six-ball overs notation: convert whole overs and zero through five extra balls into legal balls, then divide runs by balls divided by six. Label the result as a calculation from this snapshot. Leave the rate unresolved for zero balls or unsupported notation.
6. Keep tactical explanations, player performances, partnerships, remaining-ball calculations, and causes of a result outside the evidence unless the user supplies supporting information.

## Deliverable

Lead with the reported result or position, explain the score notation, and connect it to what the user can understand from this snapshot. Scale detail to their question; use an innings table when several innings need comparison. Mark missing or conflicting values explicitly.

Describe data as reported by CricketData and potentially cached for up to 24 hours. A response timestamp records the tool response, not the upstream score's observation time. Reopening a match does not establish a fresh live score. If no usable score is returned, explain the available status and identify the missing score data.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: fixture-time-planner
description: Convert Cricket Explorer fixture start times into one or more local time zones and produce a copyable agenda when the user asks when matches start where they live, across cities, or after a date change. Require trustworthy GMT timestamps and resolved time zones; do not create calendar events, reminders, or guessed start or finish times.
---

# Fixture Time Planner

Turn returned fixture start timestamps into an agenda with explicit dates, time zones, and day changes.

## Inputs and retrieval

1. Reuse the requested match rows from tool results or `widgetState.modelContent.selectedMatch`. For a series, use returned `structuredContent.selectedSeries.matches`; the selected series in widget state contains no fixture list.
2. If details are missing but an ID is known, call `open-cricket-explorer` with `reason` and either `initialPanel: "matches"` plus `matchId`, or `initialPanel: "series"` plus `seriesId`. Check the returned selection rather than assuming the lookup succeeded.
3. If no ID is known, open the appropriate panel with `reason` and `initialPanel`, ask the user to select the entity, and use its next model-visible ID. Do not invent IDs or call the widget-only `get-cricket-data` tool.
4. Resolve the destination time zone or zones from the request. Use IANA names such as `Europe/London` and `Australia/Sydney`. Ask about ambiguous cities or abbreviations such as CST; language, country, and current device offsets do not establish a time zone for a future fixture.

## Convert the timestamps

1. Use `dateTimeGmt` as the source instant. Interpret an offset-free timestamp in that field as UTC; honor an explicit offset when supplied. Require a full calendar date and time. Never manufacture midnight from `date` or infer a missing year.
2. Use the bundled [scripts/convert_fixtures.py](scripts/convert_fixtures.py) when local Python execution is available. It uses Python 3.9 or later and the system's IANA time-zone database through `zoneinfo`, with no third-party Python packages.
3. Extract the returned rows into a temporary JSON array containing their `id`, `name`, `date`, and `dateTimeGmt`. Resolve the helper path from this skill directory. For example, run from this directory:

   ```bash
   python3 scripts/convert_fixtures.py --input /tmp/cricket-fixtures.json --timezone Europe/London --timezone Australia/Sydney
   ```

4. Read the helper's JSON result. Use `utcStart` and each `localStarts` entry's `dateTime`, `timeZone`, `abbreviation`, and `dateShiftDays`. Keep rows marked `missing` or `invalid` unresolved. Invalid destination zones fail the command instead of silently substituting another zone.
5. If the helper cannot run, use another available standard time-zone facility with date-specific IANA rules. If no reliable conversion facility is available, retain the source timestamps and explain that local conversion is unresolved. Do not guess daylight-saving offsets.
6. Sort valid instants chronologically, deduplicate match IDs, and preserve each local calendar date. Show the numeric offset alongside the zone name when a repeated clock time could be ambiguous.

## Deliverable

Provide a copyable table of fixture, UTC start, and a dated local start for each requested time zone. Highlight local day changes and list unresolved fixtures separately, preserving a trustworthy source date only as an unconverted date.

Label times as reported starts from data potentially cached for up to 24 hours. A conversion establishes neither a fresh schedule nor a confirmed future start if status and timing conflict. Keep start times distinct from match duration or daily sessions; the app supplies no finish times or calendar-writing capability.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: series-following-plan
description: Build a practical shortlist of fixtures to follow from a Cricket Explorer series when the user wants a viewing plan around preferred teams, formats, dates, or available time. Use returned fixtures and stated preferences; do not promise streaming availability, complete coverage, reminders, or a match fitting wholly within a time window.
---

# Series Following Plan

Turn the available fixtures for one series into a small, prioritized plan based on the user's interests and availability.

## Inputs and retrieval

1. Identify the requested series and reuse stated team, format, date-window, and availability preferences. Ask for missing preferences only when they materially affect the shortlist; an unfiltered fixture overview needs no availability interview.
2. Obtain an actual fixture list from returned `structuredContent.selectedSeries.matches`. The selected series in `widgetState.modelContent` is a summary and does not include matches.
3. If only a series summary or its ID is available, call `open-cricket-explorer` with `reason`, `initialPanel: "series"`, and the observed or supplied `seriesId`. Check that the returned `selectedSeries` matches the intended series and contains usable fixtures.
4. If no ID is known, open the Series panel with `reason` and `initialPanel: "series"`, ask the user to select the series, and use its next model-visible ID to retrieve details. Never turn a name into an invented ID.
5. Leave `get-cricket-data` calls and Load more actions to the widget. Do not assume its local fixture cache or all loaded list pages are visible to the model.

## Build the plan

1. Scope the plan to the returned series and fixture rows. Deduplicate by match ID. Compare the number of returned rows with `matchCount` when available, and disclose a mismatch; a matching count alone does not prove complete coverage.
2. Apply explicit team and format preferences to actual `teams`, `name`, and `matchType` fields. Treat missing or `unknown` values as unresolved, not as matches for a preference.
3. Assess timing from trustworthy `dateTimeGmt` values. Interpret offset-free timestamps in that GMT field as UTC. Resolve the user's time zone before assessing local availability, and use a reliable time-zone conversion facility. Keep date-only or malformed timing outside exact time-window decisions.
4. Check `matchStarted`, `matchEnded`, and status before describing a fixture as upcoming. Treat contradictory or stale-looking timing and status as uncertain. Responses may be cached for up to 24 hours.
5. Rank eligible fixtures by the user's expressed preferences. Explain each choice using supported facts such as team, format, date, or start-time fit. Avoid invented stakes, team form, rivalries, or broadcast access.
6. Describe a start time falling within a window as a start-time fit. The app provides no duration, finish time, daily Test schedule, weather forecast, or streaming schedule.

## Deliverable

Provide a compact shortlist with fixture, format, reported start time and time zone, and a reason for inclusion. Keep fixtures with unresolved timing in a separate brief note. Explain the scope and cache limitation once.

If no fixtures satisfy the constraints, show the nearest supported alternatives and which constraint each misses. Leave reminders, calendar events, subscriptions, and streaming arrangements uncreated; this workflow produces a plan in chat.

Referenced files: 1 — file references are metadata, not package contents.