Package Boost Laravel Package

Technical Evaluation

Architecture Fit

• Laravel/Composer Package Alignment: The package is explicitly designed for Laravel-specific and framework-agnostic Composer packages, making it a direct fit for Laravel-based projects. Its integration with Testbench (for dev-only harnessing) and Laravel Boost (for MCP sync) aligns with Laravel’s ecosystem.
• AI-Agent Skill Sync: The core value proposition—syncing .ai/skills/ to per-agent directories (Claude, Cursor, GitHub Copilot, etc.)—is highly relevant for TPMs managing Laravel packages that rely on AI-assisted development. The modular skill system (e.g., package-development, cross-version-laravel-support) reduces cognitive load for maintainers.
• Deprecation Note: The package is deprecated in favor of package-boost-php (framework-agnostic) and package-boost-laravel (Laravel-specific). A TPM should migrate immediately to avoid future breakage, but the core functionality remains identical in successors.

Integration Feasibility

• Low Friction for Laravel Packages:
  • Requires Testbench (already common in Laravel packages for testing).
  • Zero-config sync for all 9 agents or selective sync via CLI.
  • Automatic .mcp.json generation when Laravel Boost is installed.
• Framework-Agnostic Support:
  • Works for non-Laravel Composer packages (e.g., PHP libraries) via Testbench.
  • No runtime dependencies—only dev-time tooling.
• CI/CD Readiness:
  • Drift detection (--check flag) prevents "forgotten syncs" in CI.
  • JSON output enables programmatic validation (e.g., GitHub Actions).

Technical Risk

Key Questions for TPM

1. Laravel vs. Agnostic:
   • Is this package Laravel-specific (use package-boost-laravel) or framework-agnostic (use package-boost-php)?
2. Agent Selection:
   • Should we sync all 9 agents by default, or curate a subset (e.g., only Claude + GitHub Copilot)?
3. CI Integration:
   • Should --check drift detection be mandatory in CI to enforce syncs?
4. Skill Customization:
   • Do we need custom skills (e.g., my-package-guidelines.md) beyond the shipped defaults?
5. Testbench Adoption:
   • Is Testbench already in use? If not, is the dev-time overhead justified for AI sync benefits?
6. Long-Term Maintenance:
   • Should we pin to a specific successor version (e.g., package-boost-laravel:^1.0) to avoid future breaking changes?

Integration Approach

Stack Fit

• Primary Stack: Laravel + Composer + Testbench (dev-only).
• Secondary Stack: Framework-agnostic PHP packages using Testbench for testing.
• Tooling Compatibility:
  • Laravel Boost: Seamless .mcp.json integration when installed.
  • PHPStan/Pest/PHPUnit: Skills like fixing-phpstan-errors align with modern PHP tooling.
  • GitHub Actions: --check flag enables pre-commit/pre-push hooks or CI gates.

Migration Path

1. Remove Legacy Package:

   composer remove sandermuller/package-boost
   

2. Install Successor:
   • For Laravel packages:

     composer require --dev sandermuller/package-boost-laravel
     

   • For framework-agnostic packages:

     composer require --dev sandermuller/package-boost-php
     

3. Update testbench.yaml:

   providers:
     - SanderMuller\PackageBoost\PackageBoostServiceProvider
   

4. Run Initial Sync:

   vendor/bin/testbench package-boost:sync
   

5. Optional: Agent Selection:

   vendor/bin/testbench package-boost:install  # Interactive picker
   

6. CI Setup: Add a step to validate syncs (example GitHub Actions):

   - name: Check package-boost sync
     run: vendor/bin/testbench package-boost:sync --check
   

Compatibility

Sequencing

1. Pre-Dev Setup:
   • Add Testbench and package-boost-* to composer.json.
   • Configure testbench.yaml with the provider.
2. Skill Authoring:
   • Scaffold skills/guidelines:

     vendor/bin/testbench package-boost:new skill my-skill
     vendor/bin/testbench package-boost:new guideline my-conventions
     

3. Sync Workflow:
   • Local: package-boost:sync (full sync) or package-boost:sync --skills (selective).
   • CI: package-boost:sync --check (fail on drift).
4. Post-Sync:
   • Commit both .ai/ (source) and generated files (e.g., .claude/, CLAUDE.md).

Operational Impact

Maintenance

• Low Overhead:
  • No runtime impact—only dev-time tooling.
  • Skills are self-contained in .ai/, reducing merge conflicts.
• Skill Updates:
  • Shipped skills (e.g., cross-version-laravel-support) are auto-updated via Composer.
  • Custom skills require manual updates but follow a stable frontmatter schema.
• Deprecation Handling:
  • No breaking changes in successors (package-boost-php/package-boost-laravel).
  • Backward compatibility for existing .ai/ layouts.

Support

• Troubleshooting:
  • package-boost:doctor validates skill/guideline structure.
  • --check mode surfaces drift in CI before it affects users.
• Agent-Specific Issues:
  • Claude Code: Native skill support (auto-activatable).
  • Other Agents: Relies on guidelines files (AGENTS.md, CLAUDE.md).
• Community:
  • Limited stars (1) but directly maintained by Sander Muller (Laravel Boost author).
  • GitHub Discussions/Issues for successor packages (package-boost-php).

Scaling

• Performance:
  • Sync is O(1) relative to skill/guideline count (no recursive scans).
  • CI drift checks add ~500ms–2s per run (negligible).
• Multi-Package Workflows:
  • Monorepos: Run package-boost:sync per-package or use global Testbench config.
  • Large Codebases: Selective sync (--skills/--guidelines) reduces I/O.
• Agent Fan-Out:
  • 9-agent sync is parallelizable (agents read from independent dirs).

Failure Modes

| Failure Scenario | Impact | Mitigation |