gstack: Stack di ingegneria del software con IA

Gli agenti di coding AI possono già scrivere funzioni, modificare repository, eseguire test e aprire pull request. Il problema più difficile è convincere un agente a seguire un processo di ingegneria ripetibile prima, durante e dopo la scrittura del codice.

gstack, un progetto di Garry Tan inizialmente costruito attorno a Claude Code, segue un percorso diverso: invece di sostituire il tuo agente di coding con un’altra piattaforma, avvolge l’agente che già utilizzi con abilità specializzate, strumenti browser, revisioni, controlli di sicurezza e processi di rilascio. Il progetto descrive il risultato come una squadra virtuale di ingegneri: ventitré specialisti e otto strumenti potenti, tutti comandi slash, tutti in Markdown, con licenza MIT.

Gli obiettivi del confronto dipendono da quale parte di gstack ti serve: collezioni di abilità come Superpowers, sistemi di specifica come OpenSpec e GitHub Spec Kit, metodologie come BMAD, piattaforme di orchestrazione come Ruflo, o il tuo stesso set mantenuto di abilità per agenti. Alcuni di questi si combinano con gstack anziché sostituirlo, e l’ecosistema più ampio a cui appartengono tutti è mappato nell’hub Strumenti per Sviluppatori AI di questo sito.

Cos’è gstack?

gstack è una collezione open source di workflow di ingegneria AI. Nella prospettiva di gstack, lo sviluppo software consiste in diversi tipi di ragionamento, e chiedere a un prompt di coding generico di eseguirli tutti è un’astrazione scadente: quindi il progetto espone abilità specializzate:

• esplorazione del prodotto
• revisione del prodotto e del CEO
• revisione dell’architettura
• revisione dell’esperienza dello sviluppatore
• revisione del design
• revisione dell’implementazione
• QA basata su browser
• indagine e debug
• analisi della sicurezza
• documentazione
• benchmarking
• preparazione al rilascio
• deploy
• retrospettive

Il progetto presenta questi ruoli come una squadra virtuale di ingegneri: un CEO che ripensa il prodotto, un manager tecnico che blocca l’architettura, un designer che intercetta la “spazzatura AI”, un revisore che trova bug in produzione, un responsabile QA che apre un browser reale, un ufficiale di sicurezza che esegue audit OWASP e STRIDE, e un ingegnere di rilascio che spedisce la PR. La toolchain attorno alle definizioni delle abilità è TypeScript e Bun: uno script di setup, documentazione generata delle abilità, hook di sessione, stato sotto ~/.gstack/, un browser bundle e un set di CLI autonome.

gstack non è un modello di fondazione e non è un sostituto per Claude Code; è un livello di processo che gira sopra un harness per agenti:

Due proprietà strutturali decidono dove si colloca gstack. Prima, il progetto lo descrive come un processo piuttosto che una collezione di strumenti: le abilità vengono eseguite nell’ordine in cui si svolge uno sprint: pensare, pianificare, costruire, revisionare, testare, spedire, riflettere; e ogni abilità passa i suoi artefatti alla successiva, quindi /office-hours scrive un documento di design che /plan-ceo-review legge, e /plan-eng-review scrive un piano di test che /qa raccoglie. Secondo, gstack non è esclusivo di Claude Code: ./setup rileva automaticamente gli agenti installati sulla macchina, e ./setup --host <name> si rivolge a Codex CLI, OpenCode, Cursor, Factory Droid, Kiro, Slate, OpenClaw e Hermes, mentre un digest di soli istruzioni di 2KB nel repo copre gli agenti che leggono le regole e non necessitano di alcuna installazione.

Perché esiste gstack

Una sessione vuota di Claude Code è estremamente flessibile, e quella flessibilità è anche una delle sue debolezze. Considera una richiesta di funzionalità come:

Aggiungi token API a livello di organizzazione all'applicazione.

Un agente capace potrebbe immediatamente ispezionare il repository e iniziare a modificare il codice di autenticazione, mentre un ingegnere senior prima chiederebbe chi possiede i token, se gli utenti possono appartenere a più organizzazioni, come vengono revocati i token, se i permessi sono ereditati, cosa succede all’autenticazione esistente, se i token dovrebbero scadere, come vengono visualizzati i segreti e quali eventi di audit sono richiesti. L’agente potrebbe scoprire alcune di queste domande in seguito, ma non c’è alcuna garanzia che le scopra prima dell’implementazione. gstack sposta quella disciplina in workflow riutilizzabili: invece di idea -> agente di coding -> codice, il passaggio passa attraverso la revisione del prodotto, la pianificazione tecnica, la revisione dell’architettura, l’implementazione, la revisione del codice, la QA del browser e il rilascio come fasi nominate, ciascuna con il proprio comando (la sequenza completa è in Un Workflow gstack Pratico di seguito).

Questo non rende l’AI corretta; cambia la distribuzione di probabilità dei suoi errori. L’agente è spinto a mettere in discussione le assunzioni prima, ispezionare le evidenze, revisionare il proprio lavoro da più prospettive e verificare l’applicazione invece di fermarsi quando il codice compila.

Come gstack Trasforma le Abilità in Markdown in Processo

La maggior parte delle capacità di gstack origina da definizioni di abilità in Markdown. Un’abilità per agenti può descrivere:

• quando dovrebbe essere eseguita
• quale contesto dovrebbe ispezionare
• quali domande dovrebbe fare
• quali strumenti può usare
• quali comandi dovrebbe eseguire
• quali evidenze deve raccogliere
• quali controlli devono passare
• come il risultato dovrebbe essere strutturato

Tale abilità agisce da qualche parte tra documentazione, un prompt riutilizzabile, una procedura operativa standard e una configurazione di workflow eseguibile. I meccanismi sottostanti sono coperti in Claude Skills e SKILL.md per Sviluppatori; gstack aggiunge infrastruttura sopra quella primitiva: definizioni di abilità generate, hook di avvio e completamento, gestione dello stato sotto ~/.gstack/, automazione del browser, meccanismi di sicurezza, ispezione del repository, telemetria opt-in, memoria tra sessioni gestita da /learn e conoscenza persistente opzionale attraverso il progetto separato GBrain, che /setup-gbrain può impostare come un database PGLite locale, un progetto Supabase o un endpoint MCP remoto.

Le Abilità gstack Più Importanti

La raccolta esatta cambia rapidamente, ma diversi workflow illustrano come il sistema sia destinato a essere usato.

office-hours

/office-hours si colloca vicino all’inizio di un progetto o di una funzionalità. Esegue sei domande forzanti sul problema prima che venga scritto qualsiasi codice e, nell’esempio pratico del README, riformula una richiesta per un “app di briefing giornaliero” in un AI capo di stato personale, quindi scrive il documento di design che ogni abilità a valle legge. Per un input vago come “abbiamo bisogno di una migliore ricerca di progetto”, l’output è un requisito, non codice.

plan-ceo-review

/plan-ceo-review esamina le assunzioni a livello di prodotto dietro un piano. Funziona in quattro modalità di scope: Espansione, Espansione Selettiva, Mantiene Scope, Riduzione; e può mettere in discussione lo scope, identificare opportunità mancanti, ridurre il lavoro non necessario o suggerire di inquadrare il problema in modo diverso. Viene eseguito prima che i requisiti siano fissati, una fase che la maggior parte degli strumenti per agenti di coding non ha.

plan-eng-review

/plan-eng-review sposta la prospettiva verso l’ingegneria: architettura, flusso dei dati, diagrammi, casi limite, una matrice di test, modalità di fallimento e preoccupazioni di sicurezza. Resta separato dalla revisione del prodotto perché fonderli in un singolo prompt grande fa mescolare al modello decisioni di prodotto con decisioni di implementazione.

plan-design-review e design-review

gstack tratta il design visivo e interattivo come una disciplina separata. /plan-design-review valuta ogni dimensione del design da 0 a 10, descrive come appare un 10 e modifica il piano per colmare il divario, con il rilevamento della “spazzatura AI” come controllo nominato. Il successivo /design-review esegue la stessa audit contro l’implementazione effettiva e corregge ciò che trova con commit atomici e screenshot prima/dopo. Per le applicazioni web, entrambi si abbinano con l’automazione del browser di gstack.

review

/review esegue la revisione ingegneristica sui cambiamenti del repository da una prospettiva di ingegnere staff: corregge automaticamente i riscontri ovvi, segna il resto per approvazione e mantiene una lente di semplificazione consigliativa per il codice sovra-costruito. Il codice scritto con successo non è necessariamente codice che dovrebbe essere unito.

investigate

/investigate impone una regola sistematica di debug che il progetto chiama La Legge di Ferro: nessuna correzione senza indagine. Traccia il flusso dei dati, testa le ipotesi e si ferma dopo tre tentativi di correzione falliti invece di continuare a girare a vuoto. Attiva anche automaticamente /freeze, che blocca le modifiche al modulo sotto indagine.

qa e qa-only

/qa fa all’agente operare un browser, interagire con l’applicazione, trovare bug, correggerli con commit atomici, ri-verificare e generare un test di regressione per ogni correzione. /qa-only esegue la stessa metodologia solo con report. Molti agenti di coding fermano la verifica al “test superati”; per un’applicazione web, il browser è dove errori di integrazione, problemi di layout, flussi errati, fallimenti di autenticazione ed eccezioni JavaScript di solito diventano visibili.

ship, land-and-deploy e canary

La catena di rilascio è composta da tre abilità piuttosto che una. /ship sincronizza main, esegue i test, audit la copertura, spinge e apre la pull request, avviando un framework di test se il progetto non ne ha. /land-and-deploy unisce, aspetta per CI e il deploy e verifica la salute di produzione. /canary quindi esegue un loop di monitoraggio post-deploy che tiene d’occhio errori di console, regressioni di prestazioni e fallimenti di pagina.

autoplan, spec, learn e retro

/autoplan esegue automaticamente il pipeline di revisione CEO, design, DX e ingegneria: l’ingegneria sempre per ultima, in modo che il gate di rilascio riveda il piano finale modificato; e mostra solo decisioni di gusto per approvazione. /spec trasforma un’intento vago in una specifica precisa e eseguibile in cinque fasi (perché, scope, tecnico con lettura obbligatoria del codice, bozza, file) con un gate di qualità di revisione esterna prima del deposito. /learn gestisce ciò che gstack ha appreso tra le sessioni: pattern, trappole e preferenze; con revisione, ricerca, potatura ed export. /retro produce un retro settimanale a consapevolezza di squadra; /retro global lo esegue attraverso tutti i tuoi progetti e strumenti AI.

Automazione del Browser in gstack

Sui sistemi macOS supportati (macOS 15+), gstack guida prima il browser Aside: il tuo browser reale, con le tue sessioni reali con login, in tab che l’agente apre per sé e chiude quando ha finito. Quando Aside non è disponibile, gstack torna al suo motore basato su Chromium, che ./setup costruisce e che esegue un daemon persistente anziché avviare un browser fresco per ogni comando:

Lo stato persistente del browser permette a cookie, sessioni di autenticazione e tab di sopravvivere tra le operazioni, il che rende pratica la QA basata su browser. /open-gstack-browser espone l’engine fallback in modo visibile, con un agente sidebar che instrada azioni rapide (clic, navigazione, screenshot) a Sonnet e lettura o analisi a Opus. Quando l’agente incontra un CAPTCHA, un muro di autenticazione o un prompt MFA, $B handoff apre un browser visibile sulla stessa pagina con cookie e tab intatti; tu lo risolvi, e $B resume riprende dove l’agente si era fermato. L’agente suggerisce un handoff automaticamente dopo tre fallimenti consecutivi. /pair-agent condivide il browser con altri agenti: OpenClaw, Hermes, Codex, Cursor o qualsiasi cosa che possa eseguire curl; con token con scope, isolamento dei tab, limitazione del tasso e attribuzione dell’attività per tab.

L’engine persistente aumenta anche la superficie di sicurezza, poiché un agente con accesso a sessioni autenticate detiene un privilegio significativo. gstack fornisce una difesa multi-livello contro l’iniezione di prompt per questo: filtri dei contenuti (datamarking, rimozione di elementi nascosti, pulizia ARIA, blocklist di URL) su ogni lettura di pagina, più un classificatore ML locale in un subprocesso sidecar che scandisce i contenuti derivati dalla pagina prima che l’agente li veda, con un combinatore di verdetto che richiede l’accordo del classificatore prima di bloccare. I contenuti della pagina sono trattati come input non fidati: l’agente prende la sintassi da una pagina, mai le istruzioni. Controlli prima e durante l’uso della QA guidata da browser:

• Decidi in anticipo quali ambienti autenticati l’agente può operare e preferisci un profilo isolato per il lavoro di QA quando l’engine fallback è in uso.
• Conosci l’interruttore di arresto di emergenza: GSTACK_SECURITY_OFF=1 disattiva il livello di sicurezza: non lasciarlo impostato.
• Il daemon persistente conserva cookie e sessioni tra le esecuzioni, quindi fermalo quando hai finito e conferma che nulla rimanga in esecuzione, ad esempio ps aux | grep -i chrom.
• Leggi gli hook e i meccanismi di sicurezza nel repository clonato prima di attivarli: sono file in chiaro, quindi revisionali come faresti per una configurazione CI.
• Dopo aver aggiornato il clone, riesegui ./setup in modo che i componenti generati restino sincronizzati con le definizioni delle abilità.

Salvaguardie di Sicurezza e Secondi Pareri

Tre strumenti potenti agiscono come interruttori di sicurezza a livello di sessione. /careful avvisa prima di comandi distruttivi: rm -rf, DROP TABLE, force-push, git reset --hard; e si attiva dicendo “stai attento”; eliminazioni ricorsive della radice o della directory home e force-push al ramo predefinito sono negati in modo rigoroso. /freeze restringe le modifiche ai file a una directory in modo che l’agente non possa “correggere” codice non correlato durante il debug, e /guard attiva entrambi contemporaneamente.

Le revisioni con secondo parere attraversano gli harness: su Claude Code, /codex invia il lavoro a OpenAI Codex CLI per una revisione, una messa in discussione o una consultazione indipendente; sugli altri harness, /claude-code fa il contrario. Ogni report identifica il provider che ha effettivamente completato la revisione.

Un Workflow gstack Pratico

Non hai bisogno di ogni abilità gstack per ogni modifica. Un workflow di funzionalità ragionevole:

1. /office-hours
2. /plan-ceo-review
3. Crea il piano di implementazione
4. /plan-eng-review
5. Implementa
6. /review
7. /qa
8. /ship

Quali abilità di revisione aggiungere dipende da per chi è il software:

Per una correzione di bug banale, andare direttamente a indagine, implementazione, revisione e test è spesso sufficiente. Una versione neutra rispetto agli strumenti della stessa forma: specifica, design, task, implementa, valida; è in Workflow di Sviluppo Guidato da Specifica Dalle Richieste al Codice. Il README del progetto descrive l’esecuzione di dieci o quindici di questi sprint in parallelo, ciascuno nel proprio workspace isolato; la struttura dello sprint è ciò che il progetto afferma mantenere gli agenti paralleli dall’essere fonti di caos.

Installare gstack

L’installazione corrente richiede una configurazione Claude Code funzionante, Git, Bun v1.0+ e, su Windows, Node.js: Bun ha un bug noto con la pipe transport di Playwright su Windows, quindi il server di browsing torna a Node.js lì. Se non hai ancora configurato Claude Code, inizia con la Panoramica di Claude Code prima. Su macOS, il browser Aside (macOS 15+) è raccomandato per le abilità di browser; senza di esso, viene usato il daemon Chromium bundle.

1. Verifica i prerequisiti: git --version e bun --version (la toolchain è basata su Bun).

2. Clona gstack nella directory delle abilità Claude:

   git clone --single-branch --depth 1 \
     https://github.com/garrytan/gstack.git \
     ~/.claude/skills/gstack
   

3. Esegui lo script di setup dalla directory clonata:

   cd ~/.claude/skills/gstack
   ./setup
   

   Setup installa e genera i componenti richiesti dalle abilità supportate e costruisce il browser bundle; un fallimento dell’installazione di Chromium è best-effort, setup registra il motivo, completa la registrazione di ogni abilità e stampa quali abilità sono colpite.

4. Aggiungi una sezione ## gstack alla CLAUDE.md del progetto. Le istruzioni di installazione del progetto includono questo passaggio, ed è ciò che fa sì che Claude Code instradi le abilità: usa /browse da gstack per tutto il browsing web, non usare mai gli strumenti mcp__claude-in-chrome__* e elenca le abilità disponibili.

5. Verifica l’installazione: controlla che i file generati siano presenti nella directory clonata, avvia una sessione di Claude Code ed esegui /office-hours su un progetto di test per confermare che l’abilità sia riconosciuta.

Modalità squadra

Per i repository, gstack offre una configurazione orientata alla squadra in cui gli sviluppatori condividono un singolo workflow anziché ambienti configurati individualmente:

(cd ~/.claude/skills/gstack && ./setup --team) && \
  ~/.claude/skills/gstack/bin/gstack-team-init required && \
  git add .claude/ CLAUDE.md && \
  git commit -m "richiedi gstack per il lavoro assistito da AI"

required blocca il lavoro assistito da AI nel repository senza gstack; sostituisco con optional per suggerire ai membri della squadra invece di bloccarli. Nessun file è venduto nel repository: ogni sessione di Claude Code inizia con un controllo di aggiornamento automatico rapido (limitato a una volta all’ora, sicuro in caso di fallimento di rete, silenzioso), che rimuove la deriva delle versioni nella squadra. La configurazione personale migliora uno sviluppatore; la configurazione a livello di repository crea una convenzione di ingegneria condivisa.

Altri harness, aggiornamenti e disinstallazione

• Altri agenti: ./setup --host codex, --host opencode, --host cursor, --host factory, --host kiro, --host slate, --host openclaw e --host hermes installano le abilità nella directory delle abilità di ciascun agente. Il digest di sole istruzioni di 2KB in agents-digest/gstack-AGENTS.md copre gli agenti che leggono solo file di regole.
• Nomenclatura dei comandi: le abilità si registrano con nomi brevi per impostazione predefinita (/qa, /review); ./setup --prefix passa a nomi con namespace (/gstack-qa), il che conta quando esegui altri pacchetti di abilità accanto a gstack.
• Aggiornamenti: riesegui ./setup dopo un git pull (richiesto su Windows, dove le installazioni sono copie di file) oppure usa l’abilità /gstack-upgrade; impostando auto_upgrade: true in ~/.gstack/config.yaml si mantiene l’installazione aggiornata automaticamente.
• La telemetria è disattivata per impostazione predefinita e chiede l’opt-in alla prima esecuzione. Se opti per l’invio, invia nome dell’abilità, durata, successo/fallimento, versione gstack e OS: mai codice, percorsi di file, nomi di repository o prompt. gstack-config set telemetry off lo disattiva in qualsiasi momento.
• Disinstallazione: ~/.claude/skills/gstack/bin/gstack-uninstall rimuove abilità, symlink, stato ~/.gstack/, stato locale del progetto, daemon di browsing e registrazioni hook.

Verifica l’installazione e correggi i fallimenti comuni

• ./setup fallisce: conferma che Bun sia sul tuo PATH con bun --version; i componenti generati sono costruiti dalla toolchain Bun.
• Abilità non riconosciute da Claude Code: conferma che il clone risieda effettivamente in ~/.claude/skills/gstack, che la CLAUDE.md del progetto abbia una sezione gstack e riesegui ./setup.
• /browse riporta NEED_ASIDE o ASIDE_NOT_RUNNING: la sonda ti sta dicendo che userà il browser fallback. È normale su Linux e Windows; su macOS significa che Aside non è aperto o non è connesso.
• Il browser fallback fallisce: cd ~/.claude/skills/gstack && bun install && bun run build.
• Installazione obsoleta dopo un aggiornamento: esegui /gstack-upgrade oppure imposta auto_upgrade: true in ~/.gstack/config.yaml.

Provare gstack Senza Adottare Tutto

Usa gstack su una funzionalità reale ma non critica anziché migrare il tuo processo di sviluppo. Il quick start del progetto è la stessa prova e finisce con “fermati lì”:

1. /office-hours: definizione del problema
2. /plan-ceo-review: ragionamento sul prodotto
3. /review: verifica ingegneristica, dopo l’implementazione
4. /qa: verifica di runtime, per progetti web

Se quelle fasi producono riscontri che il tuo normale workflow di Claude Code perde, il resto del sistema vale la pena esplorarlo; se producono principalmente testo aggiuntivo senza cambiare le decisioni di ingegneria, adottare l’intero stack probabilmente non aiuterà.

Cosa gstack Fa Bene

Ruoli di ingegneria separati. Invece di un’istruzione gigante “sii un ingegnere senior”, strategia di prodotto, architettura, UX, QA, sicurezza e ingegneria di rilascio ricevono ciascuno la propria modalità di ragionamento.

Verifica, non solo generazione. Revisione, QA del browser con generazione di test di regressione, audit di sicurezza, benchmarking e la catena ship-deploy-canary sono workflow di prima classe in gstack piuttosto che ripensamenti opzionali.

Ispezionabile. Molto del livello comportamentale sono file Markdown in chiaro che gli sviluppatori possono leggere e modificare, a differenza dei workflow interni di un agente autonomo proprietario. Il repo fornisce anche strumenti di audit per lo stack stesso: gstack-context-bill riporta quanto costa in token un albero di abilità installato, e gstack-egress scrive una ricevuta concatenata a hash per ogni invio fuori dalla macchina, telemetria inclusa.

Infrastruttura di squadra. Le abilità possono codificare convenzioni di ingegneria: invece di digitare

Ricordati di verificare la compatibilità dell'API, eseguire test di integrazione,
ispezionare la console del browser e aggiornare il changelog.

in ogni sessione, i requisiti risiedono in un workflow riutilizzabile, e la modalità squadra rende quel workflow un requisito del repository.

Dove gstack Può Essere Troppo

gstack è intenzionalmente opinione, e ciò limita la sua aderenza: un’organizzazione matura potrebbe già avere procedure di revisione dell’architettura, tooling di rilascio, gate CI, automazione QA, scansione di sicurezza, convenzioni ADR, modelli di specifica e politiche di revisione del codice, e aggiungere un’altra metodologia completa sopra crea sovrapposizione invece di chiarezza.

C’è anche un costo di contesto e token: ogni fase di revisione aggiuntiva aggiunge ispezione del repository, ragionamento del modello e potenzialmente più chiamate a modelli esterni. L’obiettivo è il processo minimo affidabile necessario per spedire software corretto, non un numero massimo di revisioni AI; gstack-context-bill può quantificare quanto costa effettivamente il tuo set di abilità installato per sessione prima che tu decida quanto di esso mantenere.

gstack funziona meglio come un toolbox i cui workflow selezioni e adatti, non come cerimoniale per ogni commit.

Alternative e Combinazioni per gstack

Le alternative più vicine, e il livello che ciascuna occupa:

gstack + Superpowers: disciplina di implementazione all’interno dei ruoli

Entrambi sono framework di abilità, quindi si sovrappongono di più. La divisione del lavoro quando si combinano: gstack fornisce i ruoli circostanti: prodotto, design, QA, rilascio; mentre Superpowers fornisce la disciplina dentro la fase di implementazione (TDD, pianificazione prima dell’implementazione, debug sistematico, revisione subagente). Installa entrambi i set di abilità, quindi riduci le abilità sovrapposte in modo che l’agente non veda mai due istruzioni in conflitto per la stessa fase; se i nomi dei comandi collidono, installa gstack con ./setup --prefix in modo che le sue abilità si registrino come /gstack-* e coesistano con l’altro pacchetto. Dettagli di installazione e workflow sono nel quickstart di Superpowers.

gstack + OpenSpec: specifiche durevoli, revisioni live

OpenSpec mantiene umani e agenti allineati attorno a specifiche di modifica esplicite: artefatti per la modifica proposta, specifiche, decisioni di design e task di implementazione. La proprietà chiave è la persistenza: una conversazione in chat scompare nella storia del contesto, ma una specifica rimane nel repository dove umani e future sessioni di agenti possono rivederla. gstack aggiunge la revisione del prodotto prima che la specifica esista e la revisione e la QA dopo che è implementata:

Una sequenza concreta: esegui /office-hours e /plan-ceo-review, cattura il risultato come una modifica OpenSpec, implementa contro di essa, quindi esegui /review e /qa. Nota che gstack fornisce anche il suo skill /spec, che archivia le specifiche sotto ~/.gstack; se OpenSpec possiede la specifica, tieni il /spec di gstack fuori dal loop in modo che i due non divergano. Il quickstart di OpenSpec copre il loop esplora-proponi-applica-archivia in dettaglio.

gstack + GitHub Spec Kit: scegli una spina dorsale di pianificazione

Il workflow core di Spec Kit è una sequenza di fasi esplicite: costituzione, specifica, piano, task, implementa, converge; e si è espanso in correzione di bug, valutazione delle idee, estensioni, preset e integrazioni. Dato che sia Spec Kit che gstack centrano la fase di pianificazione, eseguire entrambi i flussi completi duplica il lavoro. Se la tracciabilità dei requisiti e le fasi formali contano, lascia a Spec Kit di possedere la spina dorsale della specifica e usa gstack per i livelli che Spec Kit non applica: revisione del prodotto, revisione del design, QA del browser e rilascio. Un confronto più ampio di configurazioni guidate da specifiche, incluso Kiro e Claude Code, è in GitHub Spec Kit vs Kiro vs Claude Code SDD Workflows.

BMAD e Ruflo: assi diversi

BMAD è una metodologia più ampia di sviluppo guidato da AI i cui workflow adattivi coprono pensiero di prodotto, specifiche, architettura e implementazione, scalando il cerimoniale alla dimensione del lavoro. Esso e gstack giocano entrambi il ruolo di spina dorsale del processo, quindi scegli uno come spina dorsale piuttosto che eseguire entrambi in completo; le singole abilità di gstack possono ancora essere selezionate accanto a una metodologia.

Ruflo mira all’orchestrazione multi-agente: lavoratori coordinati, memoria condivisa, sciami. gstack applica più prospettive specialiste a un workflow di ingegneria; una piattaforma di orchestrazione applica più agenti esecutivi a un obiettivo di ingegneria. Il confine si sfuma: gstack può chiamare strumenti esterni e modelli aggiuntivi, e gli orchestratori possono implementare ruoli di ingegneria strutturati; ma la decisione è indipendente: se il problema è che l’agente salta la disciplina di ingegneria, un framework di abilità è la correzione diretta; se è l’esecuzione di dieci agenti contemporaneamente su molte task e repository, un orchestratore si colloca sopra un workflow come gstack piuttosto che sostituirlo.

Abilità custom: il livello più personalizzabile

Puoi anche saltare completamente il framework e creare una piccola collezione di abilità per le procedure che la tua squadra segue già:

skills/
  architecture-review/
  api-review/
  database-migration-review/
  incident-analysis/
  release-check/
  security-review/

Ogni abilità codifica una conoscenza specifica dell’organizzazione che un framework generico non può conoscere. Un’abilità di migrazione del database può richiedere analisi del rollback, analisi del lock delle tabelle, revisione dell’impatto degli indici, stima della durata della migrazione, ordinamento del deploy e compatibilità con la versione precedente dell’applicazione; un’abilità di revisione dell’API può richiedere compatibilità all’indietro, controlli di autenticazione, coerenza della paginazione, analisi dell’idempotenza, comportamento del rate-limit e modifiche OpenAPI. Un percorso pratico: parti dalle abilità gstack che usi realmente, copia la loro struttura nella tua directory skills/ e riscrivi i controlli attorno alle tue convenzioni.

Quattro Livelli: Abilità, Specifiche, Metodologie, Orchestratori

Quattro livelli coprono la maggior parte di questi strumenti e mostrano come le combinazioni sopra si incastrino:

Le abilità rispondono a “come dovrebbe comportarsi l’agente?”

gstack, Superpowers e abilità di agenti custom.

I sistemi di specifica rispondono a “cosa stiamo costruendo esattamente?”

OpenSpec e GitHub Spec Kit; i concetti e la terminologia di specifica-guida sottostanti sono definiti in Cos’è lo Sviluppo Guidato da Specifica?.

Le metodologie rispondono a “come dovrebbe il progetto muoversi dall’idea al software?”

BMAD, Superpowers e parti di gstack.

Gli orchestratori rispondono a “come dovrebbero più agenti eseguire il lavoro?”

Ruflo e altri runtime multi-agente.

I livelli compongono; un ambiente di sviluppo può contenere tutti e quattro:

gstack attraversa già diversi di questi confini.

Dovresti Usare gstack?

Il README del progetto descrive il pubblico come founder tecnici e CEO che vogliono ancora spedire, utenti di Claude Code alle prime armi che vogliono ruoli strutturati invece di un prompt vuoto, e lead tecnici e ingegneri staff che vogliono revisione, QA e automazione di rilascio rigorose su ogni PR. gstack vale la pena provarlo se usi agenti di coding estesamente e il fattore limitante non è più la generazione di codice stessa. Sintomi tipici:

• l’agente inizia a implementare prima di capire il problema
• i piani di implementazione perdono implicazioni architettoniche
• il codice generato passa i test ma fallisce nel browser
• le revisioni sono inconsistenti tra le sessioni
• i passi di rilascio sono ripetutamente dimenticati
• sviluppatori diversi promptano l’agente in modi completamente diversi
• istruzioni di ingegneria utili restano sepolte nei file CLAUDE.md
• digiti ripetutamente gli stessi prompt di revisione manualmente

Se la tua automazione fornisce già gate deterministici forti e l’agente gestisce solo piccoli task ben specificati, gstack aggiunge poco.

gstack e la Direzione dello Sviluppo Software AI

Il cambiamento in cui gstack si colloca traccia le generazioni: completamento del codice (2022-2023), agenti di coding (2024-2025), specifiche e workflow di agenti (2025-2026) e organizzazioni di ingegneria AI programmabili. I prodotti cambieranno, ma il modello resta un componente; la qualità ingegneristica dipende sempre più dal sistema circostante:

• specifiche persistenti
• abilità riutilizzabili
• conoscenza del repository
• accesso al browser
• test
• strumenti deterministici
• loop di revisione
• controlli di sicurezza
• memoria
• confini di approvazione umana
• orchestrazione

Conclusione

gstack è il processo di ingegneria attorno a un agente di coding, confezionato come abilità ispezionabili e versionate, e il suo valore sta nel forzare quel processo sull’agente piuttosto che in una singola abilità.

Inizia dalla sequenza di prova e conserva solo le abilità che guadagnano il loro posto. Al di là di ciò, la direzione sono livelli componibili: specifica, abilità, verifica deterministica, orchestrazione; ciascuno fa ciò che gli altri non possono.

Riferimenti

• Repository gstack: fonte, definizioni delle abilità e setup
• Analisi dettagliate delle abilità gstack: filosofia, esempi e workflow per ogni abilità
• Browser Aside: il browser che gstack guida prima su macOS
• Repository Superpowers: fonte, abilità e manifesti plugin
• Repository OpenSpec: fonte, documentazione e pacchetto CLI
• Documentazione GitHub Spec Kit: riferimento ufficiale del workflow Spec Kit
• Repository BMAD-METHOD: la metodologia agile guidata da AI adattiva
• Repository Ruflo: la piattaforma di orchestrazione multi-agente