building

Redbacks Cricket OS

A local-first operating system for a community cricket team: match planning, player records, coaching knowledge, and AI-assisted game preparation built around a Git repo.

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.

Hand-drawn tabletop hero image for Redbacks Cricket OS with a laptop match plan, scorecard, cricket ball, notebook, stats, knowledge, plans, and team Q&A elements. — A cricket team operations workspace: match plans, scorecards, notes, player knowledge, and team Q&A in one place.

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.

Hand-drawn diagram showing Redbacks moving from the captain's private memory to a shared team operating system with stats, knowledge, plans, and outputs. — The goal is to move team knowledge out of one person's head and into a shared system.

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

From the meeting dump 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.

From that 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: I come back to the session, drop in the scorecard and voice notes from the day. Out comes a post-match review, a plan for the next fixture, player-specific coaching points, and WhatsApp-ready messages for the group. All grounded in what actually happened.

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. The session-based workflow compresses what used to take a full evening into under an hour.

Hand-drawn workflow diagram showing raw match input becoming AI-assisted structure and then next match output. — AI is useful here because it compresses the capture-to-structure loop, not because it replaces cricket judgment.

What the OS Looks Like Now

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

Hand-drawn layer diagram of the Redbacks Cricket OS flowing downward from sources to stats, knowledge, plans, and outputs. — The repo keeps facts, methods, generated plans, and distributed outputs in separate layers.

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.

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

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

inbox/ is temporary capture, cleared regularly into the right folder.

The model is simple: 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 AI cowork part works well for the capture-to-structure loop. Raw notes become structured documents fast. Match-specific context gets generated without starting from scratch every time.

The limits showed up quickly. A single long session accumulates a lot of context. It gets unwieldy. I also have different captains running different tournaments, which means knowledge cannot live only in my session history. It needs to be portable and readable by someone else coming in cold.

Markdown files are also not infinitely scalable. At some point the flat file structure gets harder to query and maintain. At that stage, different layers of memory probably make sense: a lightweight database for stats, a vector index for knowledge, structured generation for plans. That is still roadmap.

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 is portability and shared ownership. Right now the OS depends heavily on one person holding the context. The goal is to move from “captain holds the team’s knowledge” to “the team has a shared model of itself.”

Hand-drawn roadmap showing input channels flowing into system memory, retrieval, an always-on agent, Q&A interface, team channels, and team outcomes. — The roadmap is an always-on team memory layer: capture the work, retrieve the context, and let captains, coaches, and players ask better questions.

That means making the records accessible and useful to other captains and the management group without requiring them to understand the repo structure. It probably means a lightweight interface over the knowledge layer at some point.