Boost Skills Laravel Package

Technical Evaluation

Architecture Fit

• Laravel/Composer Integration: Still Composer-native and Laravel-friendly, but the "zero-runtime, pure Markdown" characterization no longer holds. As of 2.52.x the package ships executable tooling — a resolve-conflicts workflow backed by dangling-symbols.sh — which means installation now places shell scripts in the project/tooling path, not just static skill definitions.
• New Runtime Surface: dangling-symbols.sh performs source-code symbol scanning (declarations vs. imports) to detect symbols left dangling after a merge-conflict resolution. This is a lightweight static-analysis capability executing in the developer's shell / CI, introducing a bash dependency and a new class of behavior the previous assessment did not account for.
• AI Agent Integration: Unchanged dependency on a sync engine (boost-core or laravel/boost) to push skills to agents (Claude, Cursor). Still an external-service dependency with an extensibility question.
• Modularity: Tag-gated skills (laravel, phpunit) still allow selective adoption, but the conflict-resolution tooling is a separate adoption decision from the skills themselves — it can be piloted independently, which is architecturally favorable.

Integration Feasibility

• Low Code Impact (revised): No PHP classes or routes to merge, but the conflict tooling requires shell execution privileges and a POSIX/bash environment — a real, if modest, integration constraint, especially for Windows-native developer fleets.
• Laravel-Specific Skills: Framework-agnostic by default, with Laravel-tagged skills (deployment, testing) requiring manual relevance review.
• AI Agent Configuration: Still requires Laravel Boost or boost-core and the associated API/auth layer.
• Version Baseline Shift: The package moved from 2.15.0 (2026-06-26) to 2.52.1 in roughly two months — on the order of 37 minor releases. Integration effort is unchanged, but the upgrade cadence and pinning policy are now a first-class planning concern.

Technical Risk

• Dependency on an Immature Ecosystem (unchanged, now compounded): boost-core/laravel/boost remain new with no dependents; long-term maintenance, backward compatibility, and Laravel roadmap alignment are all still open.
• Release Velocity / Semver Discipline (new): Dozens of minor bumps in weeks, with behavioral fixes landing in patch releases (2.52.1 fixes a 2.52.0 regression). Teams must pin exact versions and treat upgrades as reviewable changes, not routine composer update churn.
• Correctness Risk in Conflict Resolution (new): The 2.52.1 fix addresses false "clean sweep" reporting — previously, a declaration following a closed block comment (/** @deprecated */ public function run()) was dropped entirely, and an import following a block comment (/* note */ import type Money from './money') was miscounted as a declaration. A tool that silently reports no dangling symbols can mask broken references after a merge. Trust in its output requires validation against real codebases.
• Fragile Parsing Surface (new): Symbol detection implemented in bash regex/line scanning is inherently brittle against comment syntax, generics, multi-line signatures, and language variety (PHP + JS/TS imports are both referenced). Expect ongoing edge-case churn in exactly this area.
• AI Service Lock-in: Skills remain agent-specific; provider switching may require rewriting skills.
• Security: Skills and now scripts may encode sensitive workflows (deployment checklists, conflict-resolution procedure). Confirm script provenance (release notes carry a verified SHA) and enforce access controls.

Key Questions

1. AI Strategy Alignment: Is Claude/Cursor/Copilot an approved platform, or a proof-of-concept? Are there internal AI tools that could replace boost-core?
2. Tooling Adoption Scope: Do we want the conflict-resolution script at all, or only the skill definitions? These are now separable decisions.
3. Version Pinning: What is our policy for a package shipping ~37 minors in two months — exact pins, scheduled review, or fork?
4. Platform Support: Do we have Windows-native developers or CI runners without bash/WSL? If so, the dangling-symbols.sh workflow is a blocker for that cohort.
5. Trust in Output: What is our validation bar before relying on "no dangling symbols" as a merge gate rather than an advisory hint?
6. Maintenance Burden: Who updates skills and scripts when boost-core evolves or breaks? How will Laravel-specific skills be validated against project needs?
7. Performance & Cost: Does syncing skills to agents delay responses or increase spend?
8. Compliance: Do skills or scripts encode proprietary workflows (Jira, internal deploy runbooks) requiring legal/security review?

Integration Approach

Stack Fit

• Laravel Compatibility: ✅ High — Composer-native; Laravel-tagged skills align with common workflows (testing, deployment, Artisan, migrations).
• Conflict-Resolution Tooling: ⚠️ Conditional — requires bash/POSIX; strongest fit for Linux/macOS dev and CI, uncertain for Windows-native teams.
• AI Tooling Compatibility: ⚠️ Conditional — requires Laravel Boost or boost-core; agent support assumed, not proven at scale.
• Alternative Stacks: Symfony/Symfony Flex workable with skill pruning; non-PHP not applicable (though the symbol-scanning script is language-adjacent and PHP/TS-oriented).

Migration Path

1. Assessment Phase:
   • Audit existing AI tooling (Copilot, custom scripts) and existing merge-conflict procedure.
   • Pin an exact version (e.g., 2.52.1) and review the changelog range from 2.15.0 → 2.52.1 for behavior changes, not just the latest patch.
2. Pilot Integration:
   • Install sandermuller/boost-skills + laravel/boost in a single repo; configure sync for one AI agent.
   • Trial resolve-conflicts on deliberately adversarial fixtures: block-commented declarations, comment-prefixed imports, multi-line signatures.
3. Gradual Rollout:
   • Start with generic skills (code review), then Laravel-specific skills.
   • Introduce the conflict-resolution script as an advisory check before considering it a gate.
   • Monitor AI response quality, sync latency, and false-negative rate of the symbol scan.
4. Fallback Plan:
   • If boost-core is unstable, fork and maintain a local sync layer; use skills as reference docs.
   • If the shell tooling proves brittle or platform-blocked, adopt skills only and keep the existing conflict workflow.

Compatibility

• Composer: ✅ Native.
• Laravel Ecosystem: ✅ Mostly compatible (validate Laravel-specific skills).
• Shell Environment: ⚠️ bash/POSIX required for resolve-conflicts; verify Windows/CI runner support.
• AI Agents: ❌ No guarantees — validate against target tools.
• Existing AI Plugins: ⚠️ Potential conflicts (e.g., Copilot extensions).

Sequencing

Operational Impact

Maintenance

• Upgrade Cadence (elevated): ~37 minors in ~2 months means upgrades must be scheduled and reviewed, not absorbed passively. Track releases; read changelogs for behavioral patch fixes like 2.52.1.
• Skill Updates: Proactive subscription to releases (MIT license permits forks); override locally or fork the package.
• Script Maintenance: dangling-symbols.sh is the highest-churn component — expect continued edge-case fixes in comment parsing and import detection. Budget review time for each such release.
• Sync Engine: Track boost-core/laravel/boost; fallback is a local sync script.
• Deprecation Risk: If upstream stalls, skills degrade to static documentation and the shell tooling must be owned internally.

Support

• Troubleshooting: Debug sync via boost-core logs; debug symbol scans via script output on known fixtures.
• False Confidence: The most dangerous support scenario is a silent clean sweep on code the script mis-parses. Train users to treat output as advisory, and keep a manual verification step for conflict resolution.
• Skill Customization: Edit Markdown locally or submit PRs; no IDE support for skills.
• Vendor Support: None official — community-driven, small repo. Release notes do carry a verified SHA, which supports supply-chain review.

Scaling

• Performance: Sync cost scales with number of skills × agents; symbol scanning scales with repo size and conflict volume. Mitigate with selective sync and scoping the scan to changed files.
• Team Adoption: Onboarding must cover using AI skills and the conflict workflow, not just installing the package.
• Multi-Repo: Skills are global and may not fit monorepo/multi-tenant layouts; per-repo pins amplify upgrade overhead.
• Fleet Consistency: Mixed versions across repos will produce inconsistent conflict-resolution behavior — standardize the pinned version centrally.

Failure Modes

Ramp-Up

• For Developers: 1–2 hours to install and test sync; ~1 day to customize skills; +2–4 hours to validate resolve-conflicts against representative merge scenarios; ongoing monitoring for output drift.
• For TPM: 1 week to evaluate fit with AI strategy (including the skills-only vs. skills+tooling decision); 2 weeks to pilot with a small team; 1 month to decide on long-term adoption, pinning policy, or fork.
• Blockers: AI tooling lock-in (Claude-only skills); absence of bash on target platforms; cultural resistance to AI-assisted workflows; security review of shell scripts executing in dev/CI.