The argument
Every team relitigates the same setup: which static analyzer, at what level, which formatter, which git hooks, and who fixes the 400 pre-existing violations. The discussion costs more than the decision. Booster is that decision made once, with the configuration that makes it survive contact with an existing codebase.
One command adds the whole stack to a project, with an interactive wizard for choosing which tools you actually want.
What it installs
- Static analysis - PHPStan and Psalm, configured at a level a real codebase can adopt rather than the maximum that forces a mass baseline
- Formatting - EasyCodingStandard, applied automatically
- Refactoring - Rector, for mechanical language-version upgrades
- Git hooks - quality gates before the commit, not after the review
- IDE config - VS Code and PhpStorm settings, so the editor agrees with CI
- DDEV integration - optional, but the tools run inside the container when it is there
The part I think is right
Formatting and modernization are fixed in CI, not in code review. A GitHub Action applies the automated fixes and pushes them back. Style is never a review comment, because a human arguing about brace placement is a human not reviewing the logic.
The bundle versions itself, updates its own dependencies through a scheduled workflow, and ships a documentation site. Integration tests verify the installer actually works against a fresh project, which is the test that matters for something whose entire job is installation.