gstack per Claude Code: cosa fa davvero il suo flusso di lavoro con 23 agenti

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à.

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 <reviewed-commit-sha>
./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 è:

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.