Utilizzare le Claude Skills nei progetti per i clienti

Mentre lavoravamo a un progetto per Ticketmatic, ci siamo imbattuti ripetutamente nello stesso schema. Utilizziamo la libreria Saloon per integrarci con l'API di Ticketmatic, e la nostra applicazione si basa pesantemente su di essa, funzionando essenzialmente come una SPA in cui quasi ogni interazione passa attraverso la loro API. Se conosci Saloon, sai cosa significa: una classe request dedicata per ogni endpoint e un DTO per analizzare sia i dati della risposta sia il corpo della richiesta. Moltiplica tutto questo per dozzine di endpoint e ti ritrovi con un sacco di lavoro ripetitivo.

Esistono comandi console Artisan che cercano di aiutare in questo, come php artisan saloon:response, ma anche in quel caso dobbiamo comunque scrivere i nostri DTO, aggiungere i parametri manualmente, importare tutto e collegare il tutto. Gran parte del lavoro resta comunque ripetitiva e manuale.

Da dove veniamo: fare lo stesso lavoro, solo più velocemente

Ogni nuovo endpoint seguiva gli stessi quattro passaggi. Ecco come appare l'aggiunta di una semplice chiamata "get order":

1. Creare una classe Params

Un piccolo DTO che contiene i parametri della richiesta e li mappa sulle chiavi attese dall'API:

class GetOrderParams
{
    public function __construct(
        public int $orderId,
        //only one property for simplicity
    ) {}
    public function toTicketmaticParams(): array
    {
        return ['orderId' => $this->orderId];
    }
}

2. Creare un DTO Resource

Un oggetto spatie/laravel-data con un metodo factory che mappa le chiavi minuscole dell'API su proprietà camelCase tipizzate:

class Order extends Data
{
    public function __construct(
        public int $orderId,
        public string $status,
        // ...
    ) {}
    public static function fromTicketmatic(array $data): self
    {
        return new self(
            orderId: $data['orderid'],
            status: $data['status'],
        );
    }
}

3. Creare la classe Request

La request Saloon che collega tutto insieme: endpoint, metodo HTTP, gestione della sessione e trasformazione del DTO:

class GetOrderRequest extends Request
{
    use WithSession;
    protected Method $method = Method::GET;
    public function __construct(
        protected GetOrderParams $params,
    ) {}
    public function resolveEndpoint(): string
    {
        return "user/orders/{$this->params->orderId}";
    }
    public function createDtoFromResponse(Response $response): Order
    {
        return Order::fromTicketmatic($response->json());
    }
}

Alcune convenzioni da tenere a mente: le richieste GET estendono direttamente Request, le richieste POST/PUT estendono TicketShopRequest (che aggiunge HasJsonBody), e la maggior parte delle richieste utilizza il trait WithSession per catturare gli header di sessione.

4. Aggiungere un metodo sulla Resource

public function get(GetOrderParams $params): ?Order
{
    return $this->connector->send(new GetOrderRequest($params))
        ->dtoOrFail();
}

Il che ci dà una catena di chiamate pulita:

app(TicketShop::class)->orders()->get(new GetOrderParams(123));

Niente di tutto questo è difficile. È solo ripetere lo stesso schema più e più volte.

Perché lo abbiamo fatto manualmente?

All'inizio entravo nelle cartelle giuste e creavo questi file da solo, copiando le Request esistenti e sistemando namespace, metodi e così via. Intorno a dicembre 2025, Claude ha iniziato davvero a migliorare e a fare effettivamente ciò che gli veniva detto. Ho iniziato a chiedere a Claude di generare i file di request per me, e poi anche i file delle resource. Già questo rendeva la creazione di nuove request Saloon molto più veloce. In seguito è stato introdotto qualcosa chiamato "Claude Skills", che è stato molto interessante. Le Skills sono set di istruzioni riutilizzabili per gli assistenti di coding AI che si attivano automaticamente in base al contesto.

Come si può vedere nel video, Claude pone una serie di domande sulla request che vogliamo creare. Una volta raccolte tutte le informazioni necessarie, genera i file nelle directory corrette, sistema i namespace, aggiunge le proprietà che abbiamo definito, gestisce i campi obbligatori e opzionali e crea persino i DTO per noi. Nella skill abbiamo anche specificato di eseguire il formatter Laravel Pint.

Immagina di dover aggiungere manualmente 15 proprietà a un DTO del corpo della request e poi altre 15 al DTO della risposta: è un lavoro noioso e ripetitivo. Ora possiamo semplicemente copiare le specifiche dell'API e passarle direttamente alla skill, che gestisce tutto questo per noi.

In circa 9 casi su 10 tutto è corretto: file, proprietà e namespace. Detto questo, resta comunque importante rivedere il codice generato. C'è sempre quel restante 10% in cui qualcosa non è del tutto giusto, di solito perché non abbiamo fornito abbastanza contesto.

Altre skill

La skill di Saloon non è l'unica che abbiamo scritto per questo progetto. Un'altra attività ripetitiva era la creazione di nuove pagine. Sì, Livewire ha comandi Artisan che aiutano a generare lo scaffold dei componenti, ma in questa codebase facciamo del lavoro extra oltre a quello. Ad esempio, abbiamo la nostra classe di configurazione Shop che registra i componenti Livewire in un array:

class Shop
{
    // Alias => Component Class
    protected array $components = [
        // Global
        ShopComponent::GlobalFlash->value => Flash::class,
        ShopComponent::GlobalOptIns->value => OptIns::class,
        ShopComponent::GlobalAddressFields->value => AddressFields::class,
        ShopComponent::GlobalLanguagePicker->value => LanguagePicker::class,
        // Auth
        ShopComponent::AuthLogIn->value => LogIn::class,
        ShopComponent::AuthForgotPassword->value => ForgotPassword::class,
        ShopComponent::AuthResetPassword->value => ResetPassword::class,
        // Event
        ShopComponent::EventIndex->value => EventIndex::class,
        ShopComponent::EventSidebar->value => SeatingSidebar::class,
        ShopComponent::EventRanks->value => SeatingRanks::class,
        //...
    ];

Ogni componente è mappato a un valore di enum che funge da alias:

enum ShopComponent: string
{
    // Global
    case GlobalFlash = 'tm.global.flash';
    //...
}

Se hai lavorato con Livewire, probabilmente sai che registra i componenti automaticamente — e sì, è vero. Abbiamo scritto questa classe di configurazione Shop più avanti nella fase di sviluppo per un motivo specifico: questo progetto è pensato come un package su cui verranno costruite altre app Laravel. Alcune app potrebbero aver bisogno di disabilitare certe funzionalità o di sostituirle con implementazioni personalizzate, e questo registry ci offre quella flessibilità.

Quindi ogni volta che aggiungiamo un nuovo componente Livewire, non si tratta solo di creare il componente stesso. Dobbiamo anche aggiungere un case all'enum, registrarlo nella classe di configurazione Shop e includere i trait personalizzati che usiamo comunemente. Un altro candidato perfetto per una skill. Ecco un video che mostra come procederemmo per creare una pagina di login:

Come si può vedere, funziona davvero bene. Otteniamo il nostro nuovo componente Livewire, il nostro template Blade (tutto già nelle directory corrette!), il componente arriva con i metodi e i trait che usiamo comunemente, e tutto è registrato tramite la classe Shop.

Oltre a generare lo scaffold dei componenti, queste skill aiutano anche a garantire coerenza in tutta la codebase. Ad esempio, ho creato una skill review-pr che revisiona le mie pull request prima che arrivino al mio collega Seb. Individua sviste comuni come stringhe non tradotte o naming incoerente e aiuta a mantenere intatte le nostre convenzioni.

Nel complesso, queste piccole automazioni eliminano l'attrito dal lavoro quotidiano. Meno ripetizione, meno errori e più tempo dedicato alle parti che contano davvero.