Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Skills Laravel Package

llm/skills

A Composer plugin that syncs AI Skills from your vendor packages and arbitrary GitHub/GitLab repos into a project-local directory (default .agents/skills/). Skills are auto-discovered by their SKILL.md files and kept up to date automatically on composer install and update.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Architecture Fit

  • Two Distribution Channels (new in 1.15.0): The package now ships as both a Composer plugin (PHP-native) and a standalone binary for Linux, macOS, and Windows. This broadens architectural fit: the Composer path remains the natural choice for Laravel projects, while the binary decouples skill syncing from the PHP runtime entirely.
  • Modularity Alignment: The Composer plugin continues to leverage Composer’s plugin system, aligning with Laravel’s dependency management ecosystem without disrupting composer install workflows.
  • Skill Isolation: Skills remain self-contained directories (SKILL.md + auxiliary files), mirroring Laravel’s package/service-provider structure and promoting reusability.
  • Agent-Agnostic Design: The .agents/skills/ directory stays tool-agnostic, compatible with IDE plugins, CLI tools, and agents that read from a conventional path.
  • Beyond PHP: The binary makes the package viable in polyglot repositories, frontend-only build stages, and minimal runtime images (e.g., a Node build container or a distroless deploy image) where installing PHP + Composer just to sync skills was previously a non-starter.

Integration Feasibility

  • Low Friction (Composer Path): Requires only a --dev Composer plugin dependency and minimal config (skills.json). No Laravel-specific hooks or service providers are required.
  • Low Friction (Binary Path, new): Download a platform binary and invoke it directly — no PHP, no Composer, no global tooling assumptions. This is the fastest path for CI runners and container images, and it removes the Composer 2.x plugin-system prerequisite for teams on constrained build environments.
  • Laravel-Specific Opportunities:
    • Artisan Integration: Extend Laravel’s CLI with skills:* commands (e.g., php artisan skills:update) that can shell out to the binary or call the PHP implementation.
    • Service Provider: Register a SkillServiceProvider to expose skills as container bindings or a Skill facade.
    • Package Development: Laravel packages could ship skills natively (e.g., laravel/ai-skill-refactor).
  • Dependency Conflicts: Version skew remains a risk if skills declare PHP/Laravel constraints misaligned with the host project. The binary does not eliminate this — it only removes the tooling’s PHP requirement, not the skills’ runtime assumptions. Mitigate via strict composer.json constraints and a documented minimum binary version.

Technical Risk

  • Supply Chain (elevated by the binary): A binary is a new artifact class to trust. Mitigations:
    • Verify published checksums/signatures before execution; wire verification into CI.
    • Pin an exact binary version (not latest) and cache it by digest.
    • Prefer the Composer path where the existing Composer signature/provenance story already applies.
  • Platform Matrix: "Linux, macOS, Windows" is not the same as "all architectures." Confirm coverage for arm64 (Apple Silicon laptops, Graviton CI, ARM container runners) and confirm whether Linux builds are static/musl-compatible so they run on Alpine-based images (relevant for Laravel Sail and slim production images).
  • Security: The trust model is unchanged and still critical. Malicious skills could inject prompts or execute arbitrary code. Mitigations: enforce trusted-replace: true in production, audit donor packages (composer skills:show --verbose or the binary’s equivalent), and require explicit approval for any new skill source.
  • Behavioral Parity: The binary and the Composer plugin must produce identical on-disk results (skills.json semantics, trust rules, alias creation). Divergence would create "works on my machine" failures between developer laptops and CI.
  • Performance: Auto-sync on composer install can still slow builds; disable it ("auto-sync": false) in CI and run sync as an explicit step. The binary may improve cold-start time where PHP bootstrapping was the bottleneck — worth measuring rather than assuming.
  • Cross-Platform Filesystem: Windows junctions vs. POSIX symlinks remain a concern for the alias directories, even if the binary itself runs natively. Test alias behavior on the target OS; do not assume the binary resolves this.
  • Git Conflicts: Aliases (e.g., .claude/skills) may cause merge conflicts if not ignored. Ensure .gitignore coverage.

Key Questions

  1. Binary Scope: Does the standalone binary replicate the full Composer plugin feature set (discovery, trust enforcement, alias creation, skills.json parsing), or a subset? Is there a documented parity matrix?
  2. Architecture Coverage: Which CPU architectures are published per OS? Are Linux builds static (musl) for Alpine/Sail compatibility?
  3. Integrity: Are binaries checksummed and/or signed? Is there a published verification recipe suitable for CI?
  4. Version Alignment: How is binary version pinned relative to the Composer package version? Will a future release have the plugin delegate to a bundled binary, and if so, does that change the trust boundary?
  5. Use Case Clarity: Are skills primarily for developer tooling (IDE hints, CLI commands) or runtime AI agents (e.g., Telescope + AI)? Should skills trigger Laravel events (SkillLoaded) or be consumed via a facade?
  6. Laravel-Specific Extensions: Should skills integrate with Laravel’s service container as bindings? Could skills be versioned alongside Laravel packages (e.g., laravel/framework shipping a debugging skill)?
  7. CI/CD Impact: Will teams adopt the binary in CI and the plugin locally (or vice versa)? How will skills be tested — unit tests for SKILL.md content, integration tests against the HTTP layer?
  8. Governance: Who maintains the trust list — centralized (Laravel team) or project-specific? How are duplicate/conflicting SKILL.md files resolved?
  9. Monitoring: Should skill usage be logged (e.g., logs/skills.log)? Can skills be enabled/disabled dynamically via config or environment variables?

Integration Approach

Stack Fit

  • PHP/Laravel (primary): Native Composer integration requires no additional infrastructure. Skills coexist with:
    • Service Providers: Register skills as dynamic services.
    • Artisan Commands: Extend CLI with php artisan skills:update.
    • Packages: Ship skills alongside Laravel packages (e.g., spatie/laravel-ai).
  • Minimal / Polyglot Runtimes (new): The standalone binary fits CI runners, Docker build stages, and non-PHP repositories without provisioning PHP or Composer.
  • AI Tools: Compatible with Laravel-friendly agents:
    • Claude Code / Cursor: Use aliases (e.g., .claude/skills).
    • Aider: Read from .agents/skills/.
    • Custom Solutions: Expose skills as an API via Laravel’s HTTP layer (e.g., /skills/refactor).
  • Database: Skills could interact with Eloquent (e.g., Skill::find('refactor')) to fetch templates.

Migration Path

  1. Pilot Phase (no change to entry point):
    • Install in a non-production Laravel project:
      composer require --dev llm/skills
      composer skills:init
      
    • Validate: skills appear in .agents/skills/, aliases resolve, trust model blocks untrusted packages.
  2. Evaluate the Binary Alongside:
    • Install the pinned, checksum-verified binary in one CI job and compare its output to the Composer plugin’s output on the same commit.
    • Confirm identical skills.json interpretation and identical directory contents before standardizing on either path.
  3. Laravel-Specific Customization:
    • Create a thin wrapper package (e.g., laravel/skills) that adds Artisan commands, container bindings, and a Skill facade, delegating the sync operation to whichever backend is configured:
      // app/Providers/SkillServiceProvider.php
      public function register()
      {
          $skills = collect(Storage::files('.agents/skills'))->mapWithKeys(function ($path) {
              return [basename(dirname($path)) => new Skill($path)];
          });
          $this->app->instance('skills', $skills);
      }
      
  4. Production Rollout:
    • Disable auto-sync in CI ("auto-sync": false).
    • Run sync explicitly in the deployment pipeline (binary in the build image, or composer skills:update where PHP is already present).
    • Audit trusted packages via composer skills:show --verbose or the binary equivalent.

Compatibility

  • Laravel Versions: Test against LTS lines (10.x, 11.x) for the Composer plugin path.
  • PHP Versions: Align with Laravel’s supported range (8.1+) — relevant only to the plugin path; the binary removes this constraint for sync operations.
  • Composer: Plugin path requires Composer 2.x; binary path does not.
  • Operating Systems: Validate Linux, macOS, and Windows, including Windows junction behavior for aliases and macOS Gatekeeper/quarantine handling for downloaded binaries.
  • Architectures: Confirm x86_64 and arm64 availability per OS before promising support to Apple Silicon and Graviton-based CI users.
  • Containers: Confirm Alpine/musl compatibility if any pipeline uses slim or Sail-based images.

Sequencing

  1. Pre-requisites: Laravel project with Composer (plugin path) or a CI runner capable of executing a pinned binary (binary path).
  2. Installation: Add llm/skills as a dev dependency, or download and verify the platform binary; either way, commit skills.json.
  3. Skill Acquisition: Install donor packages and sync via composer skills:update or the binary’s sync command.
  4. Parity Check: Diff outputs from both paths on a representative branch before committing to one for CI.
  5. Laravel Integration: Register skills in a service provider; add Artisan commands and a facade if runtime consumption is needed.
  6. CI/CD: Pin binary version and verify checksum; add the sync step to the pipeline; cache the binary and skill directories by hash.

Operational Impact

Maintenance

  • Configuration Drift: skills.json must be version-controlled (unlike composer.lock). Use composer skills:init --force to reset a corrupted config.
  • Two Artifacts to Track: The team now owns both a Composer dependency version and (if adopted) a pinned binary version. Document which path each environment uses, and keep them in lockstep to avoid divergent skill directories between laptop and CI.
  • Skill Updates: Donor packages update skills via Composer. Monitor for breaking changes in SKILL.md formats — notably YAML frontmatter changes that downstream Laravel integrations may parse.
  • Dependency Management: Use composer why-not acme/skills-refactor to debug missing skills.

Support

  • Troubleshooting:
    • Skills Not Syncing: Check composer skills:show for skipped packages (trust issues).
    • Binary Won’t Run: Verify architecture, OS, checksum, and (on macOS) quarantine attributes; on Alpine, verify libc compatibility.
    • Permission Errors: Ensure .agents/skills/ is writable (chmod -R u+rw .agents).
    • Broken Skills: Validate SKILL.md syntax (valid YAML frontmatter).
  • Logging: Enable verbose mode (composer skills:update -v or the binary’s verbose flag). Log skill usage in Laravel via an event (e.g., event(new SkillUsed('refactor'))).
  • Documentation: Add a SKILLS.md to the project root covering trusted packages, how to request new skills, which execution path (plugin vs. binary) is authoritative per environment, and example SKILL.md templates.

Scaling

  • Performance: Auto-sync can slow composer install on large projects. Disable it ("auto-sync": false) and run sync as a separate step; use the binary where PHP bootstrap cost is measurable. Use --discovery sparingly, as it scans all vendor packages.
  • Storage: Skills are copied to disk. Monitor .agents/skills/ size and prune unused donor packages; cache the directory in CI keyed on skills.json + lockfile hash.
  • CI Fleet: Distributing a binary across runners means managing per-platform cache entries and upgrade cadence. Standardize on one pinned version per release train, and roll forward deliberately rather than tracking latest.
  • Failure Modes:
    • Composer path: plugin resolution failure, untrusted package skipped, sync blocked by read-only filesystem.
    • Binary path: wrong-architecture download, checksum mismatch, missing execute permission, blocked by endpoint security tooling on Windows, network egress blocked in locked-down runners.
    • Shared: alias directory drift on Windows, merge conflicts in aliased paths, silent skill-version skew between developer machines and CI.
  • Ramp-up: The binary lowers the barrier for non-PHP contributors and platform engineers, but adds a second mental model ("which sync path am I on?"). Budget a short onboarding note and a single canonical command per environment to keep the developer experience uniform.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
se7enxweb/flysystem
lampwick/laravel
jeslage/statamic-emojis
micahdshackelford/rmap-laravel
draftsmaninc/draftsman
square-bit/laravel-volition
himito/laravel-mailman
htinlynn/genius-helper
maco-studios/hephaestus
elmogy/larafast
xeviant/laravel-paystack
gorilladash/laravel-website-sdk
martialbe/flysystem-oss
chondal/3312client
jeroen-g/flickr
opscale-co/nova-genbi
itsjustvita/laravel-retention
tequilarapido/trackit
gregsphotography/site-builder-filament
cabaoctavio/laravel-query-log