Sometimes the best move is to borrow from yourself. We maintain a repository called strug-standards that holds our canonical Git hooks—the quality gates that run before commits and pushes. Today we synchronized those hooks into the Dream Team repository.
What Changed
Two files updated: .githooks/pre-commit and .githooks/pre-push. These scripts run automatically when developers commit or push code. They catch common issues—formatting violations, linting errors, broken tests—before they reach CI.
The pre-commit hook runs fast checks: code formatting, import sorting, basic linting. The pre-push hook runs heavier validation: full test suites, type checking, more comprehensive linting. This two-stage approach balances speed with thoroughness.
Why Synchronize Instead of Share
We could have used Git submodules or symlinks to share these hooks. We chose explicit synchronization instead. When hooks live directly in the repository, they're versioned with the code. You can see their history. You can modify them for project-specific needs without affecting other repositories.
The strug-standards repository becomes a template, not a dependency. We pull updates when we want them, not when they're forced on us. This gives us stability while still benefiting from centralized improvements.
The Quality Gate Philosophy
Git hooks are defensive infrastructure. They catch mistakes when the feedback loop is shortest—right when you're making them. A pre-commit hook that rejects poorly formatted code is faster and cheaper than waiting for CI to fail, or worse, having badly formatted code reviewed by a human.
The hooks also serve as documentation. New contributors can read them to understand what standards we enforce. They're executable specifications of our quality bar.
What's Next
This sync establishes a pattern we'll repeat. As strug-standards evolves—adding new checks, optimizing performance, supporting new tools—we'll pull those improvements into Dream Team periodically.
We're also considering automated sync notifications. A weekly job could check for drift between our hooks and the canonical versions, opening a PR when updates are available. This would preserve the pull-when-ready model while surfacing opportunities to stay current.
Longer term, we want these hooks to be smarter about what they check. Right now they run on all staged files. We could scope them to only check files changed in the current branch, making them faster on large repositories. We could add progressive checks that run different validations based on which files changed—no need to run Python tests if you only touched TypeScript.
The goal is to make quality enforcement invisible. The best checks are the ones developers never notice because they never write code that would fail them.