GitRekt

GitGud or GitRekt.

Comment

GitRekt 🚨💀

Punishing bad commits, one push at a time

Inspiration

Our friends were vibecoding a little too hard.
Broken builds, careless commits, and “it works on my machine” started appearing way too often in shared repositories.

So we asked ourselves:

What if pushing broken code actually had consequences?

That’s how GitRekt was born — a system that punishes developers for pushing incorrect code into a GitHub repository.

What It Does

GitRekt monitors GitHub repositories and enforces consequences when faulty code is pushed.

Depending on the severity level chosen, GitRekt applies different “punishments” to keep developers accountable.

🔥 Punishment Modes

Normal Mode

  • 🤖 Uses an LLM to roast the coding mistake
  • 📣 Posts the roast on LinkedIn or X after certain time-span if code not fixed
  • Public shame as a learning tool

Hard Mode

  • 🔄 Automatically reverts the repository to the last successful commit
  • Safe, practical, and CI-friendly

Hardcore Mode

  • 💣 Deletes the entire repository
  • No mercy. No rollback. Just regret.

How we built it

  1. Authentication

    • Implemented login for GitHub and authorization for LinkedIn, and X
    • Used Auth.js with OAuth for multi-provider authentication

  2. GitHub Actions Workflow

    • A GitHub Actions pipeline is triggered on every push
    • The workflow:
    • Analyzes code changes
    • Uses an LLM to detect errors
    • Generates a roast if issues are found
    • The workflow fails if the code is incorrect, otherwise it passes

  3. Grace Period Timer

    • After a failed workflow, a cron-based timer starts
    • If the developer fixes the code before the timer expires:
      • No punishment
    • If the timer expires:
      • The selected punishment is executed

Challenges we ran into

One of the biggest challenges was multi-provider authentication.

  • Our primary sign-in provider was GitHub
  • Users also needed to connect LinkedIn and X
  • Issues we faced:
    • Auth.js had limited and outdated documentation
    • Connecting LinkedIn or X would sometimes log users out of GitHub
    • Managing multiple active sessions was unclear

How We Solved It

  • Dug deep into the Auth.js source code
  • Explored GitHub issues and internal implementations
  • Learned how to properly manage provider sessions without overriding existing ones

Despite Auth.js being in beta and poorly documented, we eventually got everything working smoothly.

Accomplishments that we're proud of

  • Finished the project within the hackathon time limit
  • Successfully implemented multi-provider OAuth
  • Integrated LLMs with guardrails and safety boundaries
  • Built a complete end-to-end system using beta tools

What we learned

  • How to work with poorly documented and beta technologies
  • How to design safe and controlled LLM prompts
  • How CI/CD workflows can be extended beyond testing
  • Why accountability (and a little fear) improves code quality

What's next for GitRekt

Deployment

Built With

Share this project:

Updates