I’m a huge cricket fan and an unapologetic analytics nerd, and I kept running into the same wall: I’d ask ChatGPT a real cricket question and get a vague, often-wrong answer. Cricinfo sits on the largest repository of cricket data in the world, and even their own AI tool can’t query it well. The data exists; it’s just trapped behind a website and an opaque internal API that no agent can navigate.
So I built cricinfo to be agent-first from the ground up. The whole idea is that I can hand an agent this CLI and ask the kind of question that isn’t scoped to one player or one league: something cross-cutting that needs data stitched together from a dozen places. The agent figures out the syntax on its own. It’s so self-describing that the bundled skill isn’t even really necessary; when something genuinely isn’t covered, the agent just hits the Cricinfo API directly, and if I see that happen often I add a proper subcommand for it.
Solving the part that makes Cricinfo’s API hard
The reason a clean CLI didn’t already exist is that Cricinfo’s API is genuinely annoying to consume. A player’s record isn’t sitting at one endpoint; it’s smeared across many paginated pages that you have to walk and aggregate yourself. Two pieces of engineering make that disappear:
- Automatic traversal with cursor-based pagination. The CLI walks the undocumented endpoints and follows pagination cursors for you, so a single command quietly fetches and assembles what would otherwise be a dozen manual requests.
- Goroutine parallelism. Because so many queries fan out into many page fetches, it parallelizes them with goroutines and aggregates the results, which is what keeps it fast despite doing a lot of work under the hood. Type safety in Go made wrangling the API’s inconsistent shapes into clean, reliable output genuinely pleasant.
On top of the raw endpoints, I built aggregated commands that don’t exist in Cricinfo’s API at all: single commands that fan out across six or seven endpoints and stitch everything into one view. matches match-stats is the one I lean on most: one call gives me the score, who’s at the crease, how many balls they’ve faced, their runs and strike rate, and the two bowlers operating from each end. It’s the same philosophy I apply everywhere. If I keep asking the same cross-cutting question, I bake it into the CLI so the aggregation happens once and the agent gets a single clean command. live-view and matchup-history were born the same way.
A command tree that mirrors how you think about cricket
Drill from a family into exactly what you want:
matches:list,live,live-view,status,scorecard,situation,innings,partnerships,deliveries(ball-by-ball),plays,fow(fall of wickets),matchupandmatchup-historyplayers:profile,career,stats,batting,bowling,innings,deliveries,dismissals,match-stats,news, andmap-historyteams:roster,leaders,records,scores,statisticsleagues/seasons/standings/competitions: navigate a tournament’s structure, calendars, events, standings (including a dedicatedstandings orange-cap), broadcasts, officials, and oddssearch: find the league, team, player, or match (and its opaque ID) to begin withanalysis:bowling,batting,dismissals,partnerships, scoped to a match, season, or league
The live side is the fun part: because it reaches the same data that powers the broadcast, you can pull pitch maps, boundary zones, and ball-by-ball deliveries for a game in progress. It’s the kind of shot-tracking detail that usually only lives inside Cricinfo’s own live page.
Built by agents, while I watched the match
Most of this was built autonomously by a small multi-agent system, and watching it happen was half the joy. I ran a two-role loop: a discovery agent hammered the raw Cricinfo endpoints to reverse-engineer how the syntax worked and which awkward pagination was needed to aggregate a given stat, then handed its findings to an implementation agent that turned them into type-safe, working commands. The discovery agent surfaced genuinely good command ideas I wouldn’t have thought to add (competitions, partnerships, dismissals, ball-by-ball deliveries) purely from exploring what the API could do.
It’s the same autonomous-loop instinct behind my Rust→Go port: set up the right division of labor and verification, then let agents run. The whole time, I was mostly just watching a cricket match, asking questions about it, and folding the good ones straight into the CLI.
Humans and agents in the same breath
Like the rest of my tooling, it’s dual-mode: readable text by default for a human at a terminal, and --format json / --format jsonl (with --all-fields) for anything programmatic. It ships as a single Go binary over npm as cricinfo-cli-go, installing a prebuilt platform binary where one exists and falling back to a local Go build otherwise. A tag-driven GitHub Actions pipeline builds the cross-platform binaries and publishes the GitHub release and npm package together. I open-sourced it so other cricket nerds can give their agents the cricket access the official tools don’t.