Pit Crew

Landing
Plan Mode
Connectivity

Inspiration

Small software teams often have a strange problem: the plan lives in one place, while the reality of the project lives somewhere else.

A team might have tasks, dependencies, owners, and deadlines written down, but once development starts, the real story becomes scattered across branches, commits, pull requests, and changed files.

Someone may mark a task as complete while its pull request is still open. Two teammates may unknowingly modify the same files. A task may depend on another task that is still unfinished.

That inspired Pit Crew, a project-aware development companion built around one central question:

$$ \boxed{\text{Does what we are building still match what we planned to build?}} $$

Instead of being another chatbot that developers constantly need to prompt, Pit Crew maintains project context in the background and surfaces useful changes, risks, and inconsistencies when they matter.

How we built it

We designed Pit Crew around three separate layers of project information:

$$ \text{Project Context} = \text{Planned State} + \text{Observed Activity} + \text{Derived State} $$

1. Planned State

This represents what the team explicitly intends to do:

tasks
owners
priorities
dependencies
milestones
deadlines
must-have vs. optional features

2. Observed Activity

This represents factual development activity from GitHub:

commits
pushes
branches
pull requests
merges
changed files

3. Derived State

This is Pit Crew's interpretation of the relationship between the plan and the actual development activity.

For example:

$$ \text{Plan says Complete} \;+\; \text{PR still open} \;\Longrightarrow\; \text{Possible plan/reality mismatch} $$

Keeping these layers separate was important. GitHub events remain factual history, while Pit Crew's conclusions can be recomputed or corrected by a teammate.

On the backend, GitHub webhooks are verified, deduplicated, normalized, and stored as a persistent event history. We also backfill existing repository activity so connecting Pit Crew to an existing project does not mean starting with an empty timeline.

Our backend stack uses TypeScript, Node.js, Hono, PostgreSQL, and Zod, calling the GitHub REST API directly.

One of the features we focused on was file collision detection.

For two active branches $$A$$ and $$B$$, let:

$$ F(A) = {\text{files changed by branch } A} $$

and

$$ F(B) = {\text{files changed by branch } B} $$

Pit Crew computes:

$$ C = F(A) \cap F(B) $$

$$ C \neq \varnothing $$

then the two branches modify at least one common file, so Pit Crew surfaces a collision-risk warning.

Importantly, we do not claim that this guarantees a merge conflict. It simply means the branches overlap and deserve attention.

We also use short task IDs such as:

PC-12

A branch named pc-12-auth-api or a PR titled PC-12 Add auth routes is linked to that task automatically, with no AI needed.

Building Pit Crew with Pit Crew

We didn't just build Pit Crew; we built it while Pit Crew watched. From the first hours of the hackathon, we connected our own repository, so every branch, commit and pull request we made became part of Pit Crew's event history. By the end, the dashboard was showing the actual story of how we built it.

That turned development into a feedback loop:

$$ \text{Plan} \;\longrightarrow\; \text{Build} \;\longrightarrow\; \text{Signals} \;\longrightarrow\; \text{Adjust} \;\longrightarrow\; \text{Plan} $$

Plan. We wrote our brief and task list in Pit Crew itself, with owners, dependencies, must-have vs. optional scope, and our submission deadline as the target.
Build. We named branches and PRs with task keys (pc-3-github-webhook-ingestion, PC-3 GitHub webhook ingestion), so our own work linked to our own tasks automatically.
Signals. Pit Crew compared our plan with our repository and told us where they disagreed:
- Collision risks when two of us were editing the same files on different branches, e.g. [which branches and files, and what you did about it].
- Possibly blocked warnings when someone started work that depended on an unfinished task, e.g. [example].
- Plan vs. reality mismatches when a task was still "not started" in the plan but already had merged code, or the other way round, e.g. [example].
- Deadline pressure as milestones got close with must-have tasks still showing no activity, e.g. [example].
Adjust. Instead of silently editing the plan, we reviewed Pit Crew's suggested changes, such as reprioritizing a blocking task or pushing optional scope past the MVP, and accepted or rejected them. Each accepted change created a new plan version, so the history of our decisions stayed intact.

Formally, every accepted suggestion moved us to the next plan version:

$$ \text{Plan version } (n+1) = \text{Plan version } n + \text{accepted changes} $$

while rejected suggestions stayed in the timeline as recorded decisions.

The errors and risks Pit Crew raised about itself became our to-do list. When a signal turned out to be wrong or noisy, that was a bug in Pit Crew, and fixing it made the product better for everyone else. For example, [a signal that was wrong or noisy, and what you changed].

Dogfooding kept us honest. If Pit Crew couldn't explain what was happening in its own repository, it wouldn't be useful to anyone else's.

Visionary: what's still left to build

Pit Crew today proves the core loop: plan, observe, reconcile, adjust. The vision is a project model that understands a team's work as deeply as the team does, without anyone having to maintain it.

1. From file overlap to line-level collision detection

Today, two branches collide if they touch the same file. Next, Pit Crew will compare the exact regions of code each branch changes. If $$H(A)$$ is the set of changed line ranges (diff hunks) on branch $$A$$:

$$ C = H(A) \cap H(B) $$

A shared file where the two branches edit distant lines stays quiet; an overlap of the same lines becomes a high-confidence warning. We'll also factor in branch divergence and code ownership.

2. Alerts where the team already talks

Optional Discord and Slack notifications for high-signal events only: collision risks, blockers, milestone risk, and suggested replans, each linking back to the evidence in Pit Crew. Never a firehose, and never reading channels the team hasn't opted into.

3. Deeper development awareness

Pull request reviews as first-class events: who approved, what's waiting on review.
PR-to-task dependencies: warn when a PR relies on a task that isn't finished.
GitLab and Bitbucket alongside GitHub, using the same provider-neutral event model.

4. Start from what teams already have

Import an existing plan from Google Docs, Notion, a GitHub README, Linear, Jira, or GitHub Projects to initialize the brief and plan in minutes, without making any of those tools required.

5. Retrospectives, not report cards

At the end of a project, Pit Crew generates a factual retrospective: the original plan, how it evolved version by version, the blockers and decisions along the way, and the final outcome. It describes what happened; it never scores or ranks teammates.

6. Production readiness

Accounts and permissions, so each teammate signs in and actions are attributed securely.
Clearer AI failures: when a model provider errors, show the provider's actual message instead of a generic error.

The long-term goal:

$$ \text{Project sources} \;\longrightarrow\; \text{Living project model} \;\longrightarrow\; \text{The right signal, at the right moment} $$

The value is not that Pit Crew can chat about a project. The value is that Pit Crew already knows what is going on.