Redbacks Cricket OS

Redbacks is a community cricket team in Singapore. I captain the side.

This project is an attempt to build a proper operating system for the team: a structured, portable, Git-backed workspace for match preparation, player development, coaching knowledge, and post-match review.

The name sounds more technical than the core idea. Underneath the AI and repo structure, this is a normal improvement loop: capture what happened, understand the team’s strengths and gaps, decide what to change, share the plan, and review again after the next match. The system makes that loop easier to repeat.

The Problem Before

We had enough talent to be competitive. What we did not have was a shared model of what playing well looked like.

Every match felt reactive. No consistent game plan. No clarity on individual roles. When the game turned against us mid-innings, players were guessing what to adjust. The knowledge for how to fix it existed somewhere in the captain’s head. It did not compound anywhere useful.

The stats problem was separate but just as real. Scorecards were scattered across different apps and platforms. No single place to consolidate them. We used to maintain our own Excel, updated manually. That habit belonged to a pre-COVID era when we had more bandwidth to treat tasks like these as a hobby. Life moved on. The spreadsheet did not.

Then we had a streak of losses.

The Meeting That Started It

We got the core management group together. Talked through what was going wrong: the batting collapses, the bowling without a plan, the unclear roles, the fact that individual players did not know what their job was beyond “bat” or “bowl.”

After the meeting, I took the whole conversation and dumped it into a Claude session. Every discussion point, every observation, every role question.

That dump became the seed of the OS.

What the First Pass Built

The first version was not a polished system. It was a few of us using Claude and the usual ChatGPT-style workflows to turn a messy team conversation into something usable.

I would take the meeting notes, scorecards, WhatsApp context, and my own captain’s observations, put them into a Claude session, and work with it until the raw discussion became structured cricket material.

From that came role definitions. Who bats where and why. Who owns which bowling phase. What the keeper’s job is beyond catching. Clarity that had been in the air for seasons, finally written down.

Then came structured game plans. Not “let’s bat well.” Actual documents per match: ground conditions, boundary asymmetry, batting targets by over, bowling matchups by opposition strength, what we carry forward from last game, what we explicitly fix.

Then individual player plans. Each player gets a note on their current position in the XI, known weaknesses, what to work on before the next game, and a role-specific focus for the match ahead.

The workflow after each game was still very manual. I would come back to the session, drop in the scorecard and voice notes from the day, and prompt my way toward a post-match review, a plan for the next fixture, player-specific coaching points, and WhatsApp-ready messages for the group. A couple of team members were doing similar things in their own chats too. Useful, but fragmented.

That was the point where the project became obvious. The AI chats were helping, but the knowledge was trapped inside individual sessions. It did not yet live somewhere durable, portable, or readable by another captain coming in cold.

This is not anyone’s full-time job. The whole management group is doing this around work, family, and other commitments. A few hours a week at best. Even that early session-based workflow compressed what used to take a full evening into under an hour. The OS is the attempt to make that working pattern compound.

What the OS Looks Like Now

The project lives in a Git repo with a clear structure:

inbox/ is temporary capture. Match notes, screenshots, scorecards, Telegram snippets, and voice note transcripts land here first, then get cleared into the right place.

sources/ preserves raw input: scorecards, PDFs, screenshots, Telegram captures, voice note transcripts. Originals stay untouched.

stats/ holds canonical player records and match facts. Scorecards, match logs, player profiles, ground notes. These are factual records only. Analysis and conclusions stay out of here unless explicitly confirmed.

knowledge/ holds coaching playbooks, skill frameworks, drills, and templates. Batting, bowling, fielding, captaincy. Frameworks for post-match review and session planning. This is the team’s coaching library, separate from any single match.

plans/ generates match-specific and player-specific outputs from approved stats and relevant knowledge. Game plans, coaching session plans, individual development plans. Pre-match and post-match.

outputs/ holds what gets distributed: PDFs, WhatsApp-ready messages, images.

The model is simple: raw capture starts in inbox and sources. Facts live in stats. Methods live in knowledge. Generated plans draw from both. Outputs are the rendered version of what goes to players.

What I Am Learning

The first lesson came before the repo existed: AI is very good at the capture-to-structure loop. Raw notes become structured documents fast. Match-specific context gets generated without starting from scratch every time.

That was enough to prove the working pattern. A few people, using Claude and normal chat tools, could turn messy match discussion into role definitions, plans, reviews, and player messages much faster than before.

But the limits of that first round showed up quickly. A single long Claude or ChatGPT session accumulates a lot of context. It gets unwieldy. Useful decisions are buried in chat history. Prompts and outputs sit with whoever created them.

That becomes a real problem when different captains are running different tournaments. The team’s knowledge cannot live only in my session history, or in a few private chats across the management group. It needs to be portable, inspectable, and readable by someone else coming in cold.

The current version is a working first layer. Enough to run two tournaments, maintain player records for a full squad, generate consistent game plans, and do post-match reviews that actually carry forward. That is a meaningful step up from the scattered Excel and session-by-session improvisation that came before.

What Is Next

The more interesting problem now is portability and shared ownership. Right now the OS is a useful repo, but it still asks people to understand the folder structure, read Markdown, and know where the right context lives.

Markdown is a good first layer, but it is not infinitely scalable. As the records grow, the flat file structure will get harder to query and maintain. The next version probably needs different layers of memory: a lightweight database for stats, a retrieval layer for knowledge, and structured generation for plans and reviews.

The bigger goal is not just better storage. It is communication. Captains should be able to ask, “What did we learn last time at this ground?” Coaches should be able to pull up player focus areas. Players should be able to ask what their role is, what to work on, and what the plan means for them.

That is where the always-on agent idea comes in: a team memory layer connected to WhatsApp or another familiar channel, answering questions, reminding people, drafting updates, and turning the OS into something teammates can actually talk to.

More on that when it is real.