Agent Skills Laravel Package

Technical Evaluation

Architecture fit. alizharb/agent-skills is a content-distribution package, not a runtime library. It ships Markdown skills, guidelines, JSON manifests, and a service provider that hooks into Laravel Boost's discovery path (resources/boost/skills, resources/boost/guidelines/core.blade.php). This is architecturally low-risk: it is installed as a dev dependency, adds nothing to production autoload paths, and does not touch application code, routes, migrations, or config. The real "architecture" being integrated is a set of instructions to AI coding agents, which is a new class of dependency for most Laravel teams. Fit is high if the organization already uses Laravel Boost and AI-assisted development; near-zero if it does not, because the package has no standalone value.

Integration feasibility. Mechanically trivial: composer require alizharb/agent-skills --dev plus php artisan boost:install. Auto-discovery via AgentSkillsServiceProvider removes manual wiring. The skills.sh-compatible root skills/ directory and the multi-agent documentation (Claude Code, Codex, Cursor, Windsurf, Copilot, generic) mean it can serve a heterogeneous toolchain rather than forcing one vendor. The main feasibility constraints are environmental: PHP 8.3+, Laravel 13, Livewire 4, Filament, Pest/Pint/PHPStan are the assumed baseline. Teams on Laravel 10/11/12 or PHP 8.1/8.2 will get guidance that is actively misleading rather than merely unusable.

Technical risk.

• Content correctness risk (highest). 62 skills and 44 guidelines are prescriptive instructions an agent will follow. Incorrect or deprecation-prone guidance propagates silently into generated code and is harder to detect than a broken API. This risk is not covered by the CI workflows described (tests, Pint, PHPStan validate the package's scripts and PHP, not the semantic accuracy of prose).
• Supply-chain / trust risk. A v1.0.0 package from a single maintainer whose payload is natural-language instructions consumed by an agent with repository access is a meaningful trust surface. The release does call out AI agent safety, prompt-injection resistance, and dirty-worktree safety guidelines, which is a positive signal, but those are content the package provides, not a security control the package enforces.
• Version-skew risk. "Modern" framing tied to Laravel 13/PHP 8.3+ means the library will date quickly and its usefulness decays between releases.
• Instruction conflict risk. Skills can contradict team conventions, other Boost guidelines, or framework conventions; there is no described precedence mechanism beyond presets.json curation.
• Low direct operational risk. Dev-only, no runtime footprint, easily removed.

Key questions.

1. Is Laravel Boost already adopted, and at which version? Is boost:install compatible with our pinned Boost release?
2. What is the review/approval process for skill content before it influences agent output — who signs off, and against what (framework version, internal standards)?
3. Is there a licensing and maintenance commitment (license file, release cadence, issue responsiveness, bus factor mitigation)?
4. How do we detect drift between generated code and intended conventions — do we have lint/static-analysis gates that catch bad AI-generated patterns regardless of guidance?
5. Can we pin to a version and vendor the skill set, or does boost:install pull mutable content?
6. What is the rollback path, and does installation overwrite or merge with existing local skills/guidelines?

Integration Approach

Stack fit. Strong alignment with a modern Laravel stack already using Livewire, Filament, Inertia, Pest, Pint, and PHPStan — the skill taxonomy maps almost one-to-one onto those concerns (architecture, actions/DTOs/services, Filament, Livewire, Blade, Tailwind/Flux, API, webhooks, imports/exports, notifications, permissions, rate limiting, observability, package development, releases, testing, security review, accessibility). That breadth is the package's main differentiator versus hand-rolled prompt files. Presets (core, filament, api, saas, package, security, testing, frontend, devops) allow per-repo scoping instead of a blanket install.

Migration path. Additive and reversible — there is no data, schema, or API migration. The realistic path: (1) pilot on a single non-critical repository; (2) inspect the installed skills/ and guidelines/ content and diff against existing team conventions; (3) select presets matching the repo's actual profile; (4) only then propagate. Treat the first install as an evaluation, not a rollout.

Compatibility. Confirm three things before adoption: the Boost version pairing, the PHP/Laravel floor against each target repo, and whether the skills.sh layout conflicts with any existing root-level skills/ directory in our repos. Multi-agent documentation means we should deliberately pick which agent configs to enable rather than enabling all of them.

Sequencing.

1. Prerequisite: Laravel Boost installed and working in at least one repo.
2. Pilot install with core + one domain preset; run existing Pint/PHPStan/Pest gates to establish a baseline.
3. Content review and customization of guidelines to match house standards; record deviations.
4. Wire scripts/validate-skills.php, generate-manifest.php, and sync-boost-skills.php into CI where we maintain our own skills, so manifests stay consistent.
5. Wider rollout by preset per repository archetype; pin versions in composer.json and review on upgrade.
6. Establish an upgrade cadence tied to Laravel/PHP minor releases.

Operational Impact

Maintenance. Low code maintenance, moderate content maintenance. There is no runtime to patch, but 62 skills and 44 guidelines are a large surface to keep accurate; the package's value decays with framework drift. Assign an owner (typically a platform/DevEx engineer) responsible for reviewing releases and re-validating guidance against our Laravel version. Pin the dev dependency and upgrade deliberately rather than allowing floating versions across many repos.

Support. Community/single-maintainer package with no SLA. Presence of SECURITY.md, CONTRIBUTING.md, CHANGELOG.md, and GitHub Actions is a good maturity signal for a v1.0.0, but it does not constitute vendor support. Do not make it a hard dependency of any delivery pipeline; keep it a developer-experience enhancement that can be removed without breaking builds.

Scaling. Content is static, so scale is a distribution problem: many repos × pinned versions × preset combinations. manifest.json and presets.json make this automatable, and per-repo preset selection keeps noise down. The scaling risk is divergence — teams editing local guideline copies and drifting from upstream. Mitigate by deciding explicitly whether we vendor (fork and own) or track upstream, and applying one policy consistently.

Failure modes.

• Silent guidance rot: outdated skills produce deprecated patterns that pass review because they look plausible.
• Conflicting instructions: package guidelines vs. team conventions vs. other agent configs; agents follow the loudest instruction, not the correct one.
• Trust incident: malicious or erroneous instruction content in a dependency the agent treats as authoritative — the package addresses prompt injection in its guidelines but cannot enforce anything.
• Installation collisions: boost:install or the root skills/ directory overwriting or conflicting with existing repo content.
• Version mismatch: installed on a repo below the Laravel 13/PHP 8.3 baseline, yielding confidently wrong output.
• Dependency noise: dev-dependency conflicts in Composer resolution across a large monorepo.

Ramp-up. Technically minimal — two commands and no application changes. The real ramp-up is conceptual: teams must understand that this is a curated instruction layer, that its output should be reviewed like any generated code, and that they now have a new artifact type (skills/guidelines) to version and govern. Expect roughly a half-day of onboarding per team plus a review pass over the enabled presets; the extensive documentation (installation, Boost, skills.sh, presets, validation, auditing, security, authoring, versioning, per-agent setup) supports self-service, but the absence of prior assessment means the first cycle should be treated as a time-boxed pilot with explicit exit criteria rather than a standard-issue dependency.