Source: https://aiprimetech.io/it/blog/gstack-claude-code-setup-guide/ Lug 15, 2026 · 7 min · Strumenti # gstack per Claude Code: cosa fa davvero il suo flusso di lavoro con 23 agenti A Di [AI Prime Tech](https://aiprimetech.io/it/) · Con l'assistenza dell'AI Una pull request che coinvolge 14 file può superare i test unitari e comunque fallire per tre motivi completamente diversi: il comportamento del prodotto non è specificato a sufficienza, l'interfaccia è poco pratica e le note di rilascio omettono un passaggio di migrazione. Eseguire Claude Code una sola volta con «rivedi questa PR» concentra questi aspetti in un'unica conversazione sovraccarica. gstack adotta un approccio più prescrittivo. I suoi 23 strumenti basati sui ruoli suddividono la consegna del software in pianificazione, progettazione, implementazione, revisione, controllo qualità nel browser, attività di rilascio e documentazione. Anziché chiedere a un unico assistente di programmazione generico di improvvisare un processo, richiami una sequenza di flussi di lavoro mirati di Claude Code, come /plan-ceo-review, /plan-eng-review, /review, /qae /ship. Questa distinzione conta. gstack non è semplicemente una raccolta di prompt utili e i suoi «23 agenti» non sono 23 operatori autonomi che si coordinano continuamente in background. Sono skill di Claude Code specifiche per ruolo, richiamate in momenti precisi di un flusso di lavoro ingegneristico. Il valore deriva dal modello operativo che impongono; lo stesso vale per gran parte del carico aggiuntivo. ## gstack Claude Code è un sistema operativo, non un pacchetto di prompt Il modello mentale utile per gstack Claude Code è un sistema operativo per l'ingegneria costruito sopra Claude Code. Ogni strumento assegna a Claude un ruolo, una procedura e gli output attesi. Insieme, questi strumenti codificano precise idee su come il software dovrebbe passare da un'idea alla produzione. Un prompt generico potrebbe essere: ``` Review my implementation plan. ``` Un flusso di lavoro basato sui ruoli pone una domanda più circoscritta: ``` /plan-eng-review ``` Quella skill può guidare Claude nell'esame di architettura, dipendenze, modalità di guasto, testabilità, rischi del rilascio e sequenza di implementazione. Una skill di pianificazione orientata al prodotto può esaminare lo stesso piano in termini di valore per l'utente e ambito. Una skill orientata al design può mettere in discussione i dettagli delle interazioni anziché i confini del backend. La differenza è la ripetibilità. Non è necessario che ogni membro del team ricordi un prompt di revisione di 40 righe o inventi una propria checklist. La skill contiene la procedura. Il compromesso è altrettanto importante: gstack introduce nel tuo repository la procedura di qualcun altro. Presuppone che più passaggi di revisione, QA esplicita e attività di rilascio strutturate giustifichino il contesto e il tempo che consumano. Questo è spesso appropriato per modifiche in produzione, ma eccessivo per un refuso o uno script interno di due righe. ## Cosa coprono realmente i 23 strumenti basati sui ruoli L'elenco esatto degli strumenti del repository può evolvere, quindi considero autorevoli i file SKILL.md presenti nel checkout, anziché affidarmi a screenshot o descrizioni di lancio. L'elemento architetturale importante è la suddivisione delle responsabilità. | Fase di consegna | Strumenti rappresentativi | Cosa viene chiesto a Claude di fare | Limite principale | Pianificazione del prodotto | /plan-ceo-review, /office-hours | Mettere in discussione il problema, il valore per l'utente, l'ambito e le ipotesi sul prodotto | La valutazione del prodotto dipende comunque dal contesto fornito sui clienti | Pianificazione tecnica | /plan-eng-review | Esaminare architettura, flusso dei dati, casi limite, test e distribuzione | Non può convalidare vincoli infrastrutturali non documentati | Design | /plan-design-review, /design-consultation | Esaminare la struttura delle interazioni, le scelte visive e l'usabilità | Testo e screenshot sono meno efficaci dell'osservazione degli utenti reali | Controllo dell'implementazione | /careful, strumenti di protezione o blocco | Limitare le modifiche rischiose e mantenere il lavoro entro i confini dichiarati | I vincoli possono rallentare modifiche trasversali legittime | Revisione del codice | /review | Esaminare i diff per individuare difetti, regressioni, problemi di sicurezza e test mancanti | I diff di grandi dimensioni possono comunque superare la capacità di attenzione concretamente disponibile per la revisione | QA in esecuzione | /qa, /browse | Utilizzare l'applicazione tramite un browser ed esaminarne il comportamento effettivo | La configurazione dell'ambiente e i dati di test determinano la copertura | Rilascio | /ship | Eseguire i controlli di rilascio e coordinare i passaggi di commit o consegna | Le autorizzazioni per Git e il deployment richiedono un controllo consapevole | Documentazione | /document-release, /retro | Registrare il comportamento rilasciato, il contesto del rilascio e le lezioni apprese | Il testo generato deve essere verificato rispetto al sistema finale Ecco perché definire gstack una «raccolta di prompt» ne sminuisce il valore. I risultati della pianificazione alimentano l'implementazione; l'implementazione produce un diff; revisione e QA analizzano quel diff; rilascio e documentazione confezionano il risultato. È anche il motivo per cui «flusso di lavoro con 23 agenti» può essere fuorviante. Quando invochi una skill, ciò che accade realmente è che Claude Code carica le istruzioni ed esegue il flusso di lavoro associato usando gli strumenti disponibili nella sessione corrente. A meno che una skill non deleghi esplicitamente il lavoro, non ci sono 23 processi persistenti che condividono uno stato globale. ### La pianificazione è intenzionalmente ridondante Le revisioni di prodotto, tecniche e di design si sovrappongono. È una scelta deliberata. Considera la proposta di una funzionalità per «esportare tutte le attività dei clienti»: - La revisione di prodotto si chiede se agli utenti serva un'esportazione completa o un report filtrato. - La revisione tecnica si chiede se l'esportazione possa stare in memoria e come funzionino i nuovi tentativi. - La revisione di design si chiede dove compaiano lo stato dell'esportazione, gli errori e i comandi di download. - La QA si chiede cosa accada in assenza di record, con link scaduti e con processi interrotti. In pratica, questa separazione fa emergere ipotesi che sfuggono all'interno di un piano di implementazione generico. Il costo è il caricamento ripetuto del contesto. Se il piano contiene già 8,000 token, tre passaggi di revisione possono diventare costosi e produrre osservazioni duplicate. ### Revisione e QA sono attività diverse /review si basa principalmente su evidenze ricavate dal codice: diff, tipi, test, punti di chiamata e convenzioni del repository. /qa e /browse può raccogliere evidenze durante l'esecuzione dell'applicazione stessa. Questa separazione è una delle idee più valide di gstack. Un diff può sembrare corretto mentre il risultato visualizzato è inutilizzabile. Viceversa, un controllo nel browser sul percorso senza errori può riuscire anche se l'implementazione introduce una condizione di competizione o un aggiramento dell'autorizzazione. Una sequenza pratica si presenta così: ``` /plan-eng-review /careful # Implement the approved plan in Claude Code /review /qa /document-release /ship ``` Non considerarla una pipeline obbligatoria. Per una migrazione del database, la revisione tecnica e la pianificazione del rollback possono contare molto più del design visivo. Per una regressione CSS, /browse, la revisione di design e la QA possono costituire il nucleo del flusso di lavoro. ## Installare gstack senza fidarsi alla cieca Una tipica installazione a livello utente colloca il repository nella directory delle skill di Claude Code ed esegue il relativo script di configurazione: ``` git clone https://github.com/garrytan/gstack.git \ ~/.claude/skills/gstack cd ~/.claude/skills/gstack ./setup ``` Riavvia Claude Code dopo la configurazione se i nuovi comandi non vengono rilevati immediatamente. Poi esamina le skill installate, anziché presumere che il numero pubblicato corrisponda ancora al tuo checkout: ``` find ~/.claude/skills/gstack \ -name SKILL.md \ -print | sort find ~/.claude/skills/gstack \ -name SKILL.md | wc -l ``` Un errore comune è eseguire gli script di installazione perché il repository è popolare, senza leggere cosa modificano. gstack include meccanismi eseguibili per i flussi di lavoro, non Markdown inerte. Prima di eseguire la configurazione, esaminala: ``` cd ~/.claude/skills/gstack git status --short git log -1 --oneline sed -n '1,240p' setup ``` Per l'adozione da parte di un team, fissa un commit revisionato anziché seguire silenziosamente lo stato più recente del repository: ``` git clone https://github.com/garrytan/gstack.git vendor/gstack cd vendor/gstack git checkout ./setup ``` La procedura di installazione esatta e le dipendenze possono cambiare con lo sviluppo del progetto. Il README attuale del repository e lo script di configurazione devono quindi avere la precedenza sui comandi copiati da un articolo meno recente, incluso questo. ## Definire le autorizzazioni di Claude Code per il flusso di lavoro Alcuni strumenti di gstack richiedono un accesso ampio per esaminare file, eseguire test, usare un browser o interagire con Git. Questo non significa che ogni strumento debba ricevere autorizzazioni illimitate per la shell e il rilascio. Un file a livello di progetto .claude/settings.json può stabilire una base prudente: ``` { "permissions": { "allow": [ "Bash(git status:*)", "Bash(git diff:*)", "Bash(npm test:*)", "Bash(npm run lint:*)" ], "deny": [ "Read(./.env)", "Read(./.env.*)", "Bash(git push:*)", "Bash(git push --force:*)" ] } } ``` Considerala una policy di esempio, non un file universale pronto all'uso. Adatta i comandi al tuo gestore di pacchetti, al tuo test runner e alla tua versione di Claude Code. Il rifiuto deliberato di git push è particolarmente utile durante la valutazione. /ship può comunque verificare se il rilascio è pronto, ma la persona mantiene il controllo sull'azione finale che produce effetti sulla rete. Dopo che il team ha compreso il flusso di lavoro, puoi decidere se sia giustificata un'autorizzazione di push con un ambito strettamente limitato. Testa inoltre le skill orientate al browser in staging o con dati locali prepopolati. L'automazione del browser con una sessione di produzione può modificare record reali se il flusso di lavoro fa clic su un comando distruttivo. ## Adottare un sottoinsieme prima dell'intero sistema Non introdurrei tutti i 23 strumenti in un team fin dal primo giorno. Parti dai punti in cui il processo esistente perde più informazioni. Una matrice di valutazione ragionevole è: | Problema del team | Inizia con | Rimanda inizialmente | I piani trascurano i casi limite | /plan-eng-review | Sequenza completa di design e rilascio | Le modifiche alla UI introducono regressioni che passano inosservate | /browse, /qa, /plan-design-review | Flussi di lavoro per la strategia di prodotto | Le revisioni sono incoerenti | /review | Rilascio automatizzato | I rilasci mancano di contesto | /document-release, /retro | Strumenti per il browser | Claude apporta modifiche troppo estese | /careful e controlli dell'ambito | Adozione del flusso di lavoro completo Esegui il sottoinsieme su diverse modifiche reali e registra: - Quali rilievi hanno portato a modifiche del codice o dell'ambito? - Quali rilievi erano duplicati? - Quanto contesto è stato necessario ripetere? - Gli artefatti generati sono rimasti sincronizzati con l'implementazione? - Quali comandi richiedevano autorizzazioni che il team non concederebbe in CI? - Gli sviluppatori hanno capito quando invocare ciascun ruolo? Il costo aggiuntivo del contesto non è teorico. Ogni ruolo ha bisogno dello stato del repository, dei requisiti e delle decisioni precedenti. Sessioni separate possono perdere le motivazioni; una sessione lunga può accumulare ipotesi obsolete. Conservo il piano approvato in un file del repository come docs/plans/export-jobs.md, poi indico a ogni flusso di lavoro di usare quell'artefatto. I file persistenti sono più affidabili dell'aspettativa che il contesto della conversazione funzioni come memoria del progetto. ## Comportamento documentato e affermazioni promozionali L'affermazione sostenibile è che gstack fornisce 23 strumenti di Claude Code orientati ai ruoli e un flusso di lavoro basato su scelte precise che copre il ciclo di vita del software. Puoi verificare questo comportamento leggendo le skill installate ed eseguendole in un repository di test. Affermazioni più ampie, come produrre una quantità di lavoro enormemente superiore, sostituire un team di sviluppo o comprimere settimane in ore, restano promozionali finché non vengono dimostrate nel tuo ambiente. I risultati dipendono dalla qualità del repository, dalla copertura dei test, dall'ambiguità del compito, dalla scelta del modello, dalle autorizzazioni e dallo sviluppatore che supervisiona il lavoro. Anche l'attuale gamma di modelli non elimina questi vincoli. Sonnet 4.6 può essere una scelta predefinita pratica per un lavoro di programmazione prolungato, mentre Haiku 4.5 può essere adatto ad attività più leggere di classificazione o documentazione. Il contesto di 1M di Fable 5 può aiutare con insiemi di materiale molto estesi, e gpt-5.6-sol offre un'altra opzione orientata allo sviluppo negli ambienti supportati. Nessuno trasforma un prompt di ruolo in conoscenza verificata del prodotto o in evidenze di produzione. ## Indicazioni pratiche - Considera gstack un processo di sviluppo basato su scelte precise, implementato tramite le skill di Claude Code. - Interpreta «23 agenti» come strumenti basati sui ruoli, non come esecutori persistenti coordinati automaticamente. - Installa dal repository, esamina setupe fissa un commit revisionato per l'uso da parte del team. - Inizia con due o tre flussi di lavoro che affrontano problemi noti nel processo di rilascio. - Conserva i piani e le decisioni approvati in file, così che i ruoli condividano un contesto persistente. - Separa la revisione del codice dal controllo qualità in esecuzione: individuano categorie diverse di problemi. - Limita l'accesso ai segreti, alle sessioni di produzione, ai push Git e ai comandi di distribuzione durante la valutazione. - Misura i risultati utili e i difetti evitati, non il numero di comandi eseguiti. - Adotta l'intero sistema operativo solo quando il costo del suo processo è inferiore a quello dei problemi che previene. [Programmazione](/it/blog/tag/coding/)[Claude](/it/blog/tag/claude/)[Agenti](/it/blog/tag/agents/)[Modelli](/it/blog/tag/models/) A [AI Prime Tech](https://aiprimetech.io/it/) AI Prime Tech pubblica questo blog. Gli articoli sono redatti con l'assistenza dell'AI; verifica nella documentazione ufficiale i dettagli specifici della versione, come gli ID dei modelli, i prezzi e i limiti, prima di farvi affidamento. Ottieni accesso all'API Claude a un costo inferiore Un'unica chiave API per Claude Opus 5.5, Sonnet 5, Haiku 4.5 e Fable 5.1, oltre a GPT-6 modelli. Pagamento a consumo, senza abbonamento. [Ottieni la tua chiave API →](/register) AI Prime Tech è un gateway API indipendente di terze parti. Claude™ e Anthropic® sono marchi di Anthropic, PBC. Non si intende suggerire alcuna affiliazione o approvazione.