Strauss: prefix bundled Composer dependencies

WordPress loads every active plugin into one PHP process, and for any given class name, whichever plugin's Composer autoloader registers first wins. If your plugin bundles Guzzle 7 and another plugin bundles Guzzle 6, one of you silently runs the other's version — best case a subtle bug, worst case a fatal. Strauss solves this by copying your runtime dependencies into vendor-prefixed/ and rewriting their namespaces, classnames, and constants so they are unique to your plugin (GuzzleHttp\Client becomes My_Plugin\GuzzleHttp\Client). This skill wires Strauss into the Composer lifecycle and the release build. It is about bundling isolation, not autoloading your own plugin code.

When to use this skill

• A distributed plugin ships any Composer runtime dependency (require, not require-dev) — HTTP clients, SDKs, loggers, parsers.
• Two plugins fatal or misbehave together with "Cannot redeclare class", wrong-version method signatures, or Uncaught Error: Call to undefined method on a vendor class.
• composer.json contains extra.strauss or extra.mozart (reviewing or extending an existing setup).
• Migrating off Mozart (Strauss began as a Mozart fork and reads the Mozart config for a seamless migration).
• Setting up the release/CI build for a plugin whose vendor/ is gitignored.

Install: pinned phar via composer scripts (recommended)

The upstream-recommended install is the phar, downloaded on demand and run from composer scripts — not composer require --dev brianhenryie/strauss. The phar keeps Strauss's own dependency tree (composer/composer, symfony/console, nikic/php-parser, monolog, …) out of your dev autoloader, where it could conflict with your own dev tools.

Create bin/ (with a .gitkeep), add bin/strauss.phar to .gitignore, then: