Continuous integration
Everyone merges small changes into main often, and a machine builds and tests each one, so breakage surfaces in minutes.
See it
What it is
Continuous integration is a habit first and a robot second. The habit: everyone merges their work into the shared main branch often (at least daily), in small pieces. The robot: a server builds and tests every one of those merges automatically, so a break is discovered within minutes of the commit that caused it, while the author still remembers what they changed. The practice comes out of Extreme Programming in the late 1990s, and Martin Fowler's article is still the canonical write-up.
The thing CI actually prevents is the week-long merge nightmare: six people work in isolation for a month, then discover on release day that their changes contradict each other. Small, frequent, verified merges make that a five minute conflict instead of a five day one.
Common misconception: 'we have GitHub Actions, so we do CI'. If people sit on branches for two weeks, or the suite is red and everyone shrugs, you have a build server, not continuous integration. A red main branch is supposed to be an emergency, and flaky tests are what quietly kill that instinct.
Ask AI for it
Add continuous integration to this repo. Create a CI workflow that runs on every pull request and every push to main, with lint, typecheck, unit tests, and the production build as independent parallel jobs rather than one sequential script, so a lint typo does not hide a test failure. Where the runner supports it, cancel the remaining jobs once one fails. Keep the whole run under five minutes with dependency caching. Reporting a check does not make it required, so configure branch protection separately to require those exact job names on main. Then add a short CONTRIBUTING note telling contributors to merge small changes daily and to treat a red main branch as stop-the-line.