Jak dobrać AI Agent Skills do stacku Laravel i Vue?

Jeśli pracujesz z agentem AI w kodzie — Claude Code, Cursor, Windsurf — prędzej czy później trafisz na agent skills: gotowe paczki wiedzy, które uczą agenta konwencji konkretnego frameworka. Brzmi świetnie. Problem zaczyna się, gdy otworzysz katalog taki jak skills.laravel.cloud i zobaczysz 174 skille, a do tego dziesiątki repozytoriów na GitHubie, każde od innego autora.

Instalujesz sześć, które brzmią sensownie dla Laravela. Po tygodniu agent generuje kod, który raz trzyma się jednego wzorca, raz drugiego — bo dwa skille mówią to samo, tylko trochę inaczej.

Ten artykuł to metoda dochodzenia do zestawu dopasowanego do stacku, którego używam najczęściej — na przykładzie Laravel + Vue 3. Jeżeli jesteś zainteresowany samym efekcie, to na końcu, znajdziesz dwa gotowe zestawy (dla SPA z API oraz dla Inertia).

Krok 1 — Sprawdziłem, czy skille się nie zazębiają

Zacznijmy od sześciu popularnych skillów Laravel/PHP z katalogu:

• laravel-patterns
• php-pro
• laravel-specialist
• laravel-security
• sentry-php-sdk
• laravel-inertia-react

Po przeczytaniu ich treści (nie opisów — do tego wrócę) okazuje się, że duża część pokrywa się ze sobą:

Najważniejsza lekcja tego kroku: skille rzadko się wzajemnie wykluczają (nie ma „użyj Doctrine" kontra „użyj Eloquent"). Problemem jest redundancja — agent dostaje tę samą instrukcję kilka razy, z drobnymi różnicami, i wynikiem są niespójne decyzje w kodzie.

A te „drobne różnice" potrafią być realne:

• php-pro wymaga PHP 8.3+ i PHPStan level 9; laravel-specialist zakłada PHP 8.2+ bez wzmianki o PHPStan.
• Próg pokrycia testami: php-pro → 80%, laravel-specialist → 85%.

Pojedynczo nieszkodliwe. Razem — agent nie wie, którego standardu się trzymać.

Wniosek: zanim dodasz skill, przeczytaj te, które już masz. Dwa skille pokrywające ten sam obszar w 70% to nie „podwójne bezpieczeństwo", to proszenie się o niespójność.

Krok 2 — Zawęziłem do swojego stacku

Mając mapę zazębień, odsiewamy po stacku. Pracujemy w Laravel + Vue 3, więc:

• laravel-inertia-react — odpada natychmiast. To React (JSX, useForm z @inertiajs/react). Dla Vue to inny SDK i inne wzorce komponentów.
• php-pro — wnosi głównie Symfony i async (Swoole, ReactPHP), których w typowym projekcie Laravel nie używam. Pomijamy.
• laravel-patterns — pokryty przez laravel-specialist. Pomijamy.

Tu pojawia się pytanie, które rozstrzyga połowę wyboru frontendu:

Używasz Inertia, czy Vue jako oddzielne SPA gadające z Laravelem po API?

To nie jest pytanie kosmetyczne — determinuje, czy backend renderuje strony Inertia, czy zwraca czysty JSON, a co za tym idzie — zupełnie inny zestaw skillów frontendowych. (W moich projektach odpowiedź bywa różna: czasem Inertia, częściej SPA — dlatego na końcu przygotowałem dwa zestawy.)

Krok 3 — Weryfikuje źródło, nie metadane ⚠️

To najważniejszy — i najmniej oczywisty — krok całej drogi.

Katalogi skillów wyświetlają opis i często podgląd treści. Okazuje się, że bywają mylące lub wręcz puste.

Przykład pierwszy: szukając skilla pod Inertia + Vue trafiłem na laravel-inertia-vue. Na platformie ma opis „A reusable AI agent skill for laravel-inertia-vue" i pusty content. Wniosek na pierwszy rzut oka: stub, nie ma sensu instalować.

Błąd. Wystarczyło zajrzeć do repozytorium źródłowego na GitHubie:

curl -sL https://raw.githubusercontent.com/jasim-k/laravel-agent-skills/main/laravel-inertia-vue/SKILL.md

…i okazuje się, że SKILL.md ma 30+ reguł: Vue 3 Composition API, useForm, persistent layouts, shared data, TypeScript, pełne przykłady kontrolerów i komponentów. Treść była kompletna — po prostu pole content w bazie katalogu nie zostało zsynchronizowane.

Ten sam wzorzec powtórzył się przy laravel-api: pusty content na platformie, a w repo (w podkatalogu laravel-api/SKILL.md, nie w korzeniu!) pełna, dopracowana architektura REST API — invokable controllers, ULID-y, wersjonowanie z nagłówkami Sunset, JWT, Payloads jako DTO, Spatie Query Builder.

Wniosek: opis i podgląd w katalogu to nie to samo, co treść skilla. Zawsze otwórz SKILL.md w repozytorium źródłowym przed decyzją. Skill, który wygląda na pusty, może być najlepszy w zestawie.

Przy okazji — to też moment na bezpieczeństwo. Skille to instrukcje, które wstrzykujesz agentowi mającemu dostęp do Twojego kodu i shella. Sprawdziłem autora, gwiazdki repo i audyty (część katalogów pokazuje wyniki Snyk / Socket / Gen Agent Trust Hub). Laravel Boost — o którym za chwilę — uruchamia nawet audyt bezpieczeństwa przed instalacją zewnętrznego skilla.

Krok 4 — Jeden autor czy mix najlepszych?

Naturalna pokusa: znaleźć jednego autora pracującego w tym samym stacku i wziąć wszystko od niego. Sprawdziłem trzy popularne repozytoria:

Wniosek: żaden pojedynczy autor nie pokrywa Vue w 100% — większość kolekcji ma front nastawiony na React. Najbliżej jest jeffallan (ma i Laravel, i Vue), ale brakuje mu głębi w bezpieczeństwie.

Wniosek: lojalność wobec jednego repo kosztuje jakość. Lepszy jest mix najlepszych — backend od jednego autora, security od drugiego, Vue od trzeciego — pod warunkiem, że (patrz Krok 1) nie zazębiają się.

I właśnie w momencie składania tego miksu pojawia się coś, co przewraca całą układankę.

Krok 5 — Game changer: Laravel Boost

Wszystkie dotychczasowe skille to projekty community. Tymczasem istnieje oficjalne rozwiązanie od zespołu Laravel: laravel/boost (3,5k gwiazdek).

I to nie jest „kolejna kolekcja skillów". To pakiet Composer + lokalny MCP server, który:

1. instalujesz w projekcie (composer require laravel/boost --dev),
2. uruchamia się obok aplikacji jako MCP server,
3. automatycznie wstrzykuje kontekst zależnie od tego, co edytujesz (Eloquent → reguły wydajności DB; kontroler → routing),
4. ma wbudowany skill laravel-best-practices napisany przez zespół Laravel — 19 sekcji, od N+1 i cache'owania po kolejki, scheduling i architekturę,
5. zna kontekst dla: Laravel 11/12, PHP 8.2–8.5, Inertia+Vue, Tailwind, Pest, Livewire, Folio, Wayfinder,
6. pozwala dokładać community skille komendą php artisan boost:add-skill — z audytem bezpieczeństwa.

Co to oznacza dla naszej listy? Boost zastępuje większość tego, co dobieraliśmy ręcznie:

Czego Boost nie pokrywa — i tu community skille wciąż mają sens:

• Vue 3 SPA (Pinia, composables, architektura komponentów) — Boost skupia się na backendzie.
• shadcn-vue — biblioteka komponentów UI.
• Pełny audyt OWASP Top 10 — Boost ma podstawy bezpieczeństwa, nie pełną procedurę audytu.
• Monitoring / observability (Sentry).
• Głębokie wzorce Inertia+Vue — wbudowany kontekst to dosłownie dwie linijki.

Wniosek: nie buduj zestawu od zera. Trzeba zacząć od fundamentu (Boost), potem dokładać tylko luki. To odwraca całą logikę doboru — zamiast „które z 174 skillów wziąć", pytam siebie „czego Boost nie umie".

Finał — dwa gotowe zestawy

Fundament w obu przypadkach: laravel/boost. Resztę dokładasz przez php artisan boost:add-skill.

Zestaw A — Laravel + Vue 3 jako SPA (czyste API)

Zestaw B — Laravel + Vue 3 + Inertia

Różnica między zestawami to jedna zamiana: vue-expert (SPA) ↔ laravel-inertia-vue (Inertia). Reszta identyczna.

Czy to wystarczy?

Zebrałem kilka przydatnych skilli, które poprawiają jakość kodu. Czy to oznacza, że już do końca nie muszę się przejmować nowymi skillami? Oczywiście, że nie. W zależności od projektu może pojawić się potrzeba innych skilli. Skille mogą się także dezaktualizować lub mogą pojawiać  się nowe. Niemniej takie zestawienie jak powyżej daje mi dobry zestaw początkowy, który znacząco ułatwia wystartowanie projektu i przejście prawie od razu z konfiguracji projektu do tworzenia kluczowych funkcjonalności.