GitHub Spec Kit vs Kiro vs Claude Code SDD Workflows

Gli sviluppatori che confrontano i setup di Spec-Driven Development nel 2026 di solito non si chiedono quale modello sia il più intelligente. Si chiedono quale flusso di lavoro terrà allineato un agente AI senza seppellirli sotto una montagna di rituali.

GitHub Spec Kit, AWS Kiro e i flussi di lavoro personalizzati di Claude Code implementano tutti la stessa idea generale – requisiti, progettazione, attività, implementazione, validazione – ma bilanciano in modo diverso portabilità, profondità di integrazione e quanto processo impongono.

Se hai bisogno prima dei concetti, leggi Cos’è lo Spec-Driven Development? e la guida neutra rispetto agli strumenti Flusso di Lavoro dello Spec-Driven Development nel cluster di documentazione Architettura delle Applicazioni. Questo confronto si trova nell’hub Strumenti per Sviluppatori AI insieme a recensioni di assistenti e guide ai flussi di lavoro.

Lo SDD Sta Diventando una Categoria di Strumenti

Lo Spec-Driven Development ha smesso di essere un esercizio sulla carta alla fine del 2025. Ogni grande fornitore di coding AI ora offre qualche versione di specifica-pianifica-implementazione, e un elenco crescente di strumenti indipendenti compete su quanta struttura aggiungono attorno a quel ciclo.

Il confronto che conta non è “quale strumento vince”. È profondità di processo rispetto alla portabilità. Kiro è integrato. Spec Kit è portatile. I flussi di lavoro di Claude Code sono modificabili. Specifiche scadenti rendono ogni agente peggiore indipendentemente da quale wrapper si scelga. Specifiche buone viaggiano tra gli strumenti.

Come Confrontare gli Setup SDD

Prima di scegliere uno strumento, definisci cosa stai ottimizzando. La stessa funzionalità può sembrare scorrevole in un setup e burocratica in un altro, a seconda della dimensione del team, dell’età della codebase e di quanta revisione ti serve.

Portabilità – Le specifiche possono esistere come semplice markdown nel tuo repository e funzionare con l’agente che preferisci il trimestre prossimo? O sono legate a un unico IDE, a un unico cloud o a un formato proprietario?

Attrito di setup – Quanto tempo va da “voglio provare lo SDD” a un ciclo funzionante di specifica-pianifica-attività? Impalcatura CLI, installazione IDE o creazione propria di comandi slash hanno tutti diversa energia di attivazione.

Qualità della specifica – Lo strumento ti aiuta a scrivere requisiti e criteri di accettazione precisi, o genera principalmente documenti lunghi? La struttura è utile. Il volume, no.

Esecuzione delle attività – Come lo strumento spezza il lavoro in fette revisionabili? Le attività possono essere eseguite in parallelo? Resiste a esplosioni di liste di attività da cinquanta elementi?

Punti di controllo revisione – Ci sono gate umani naturali tra specifica, pianificazione, attività e implementazione? Lo SDD senza revisione è solo coding guidato da vibrazioni più lento.

Ancoraggio al repository – Il flusso di lavoro legge le convenzioni del progetto, record di decisione, ADR, AGENTS.md e il codice esistente prima della pianificazione? Agenti senza ancoraggio reinventano l’architettura perché non vedono mai l’intento revisionato dietro le scelte precedenti.

Collaborazione del team – Più persone possono revisionare gli stessi artefatti della specifica nelle pull request? Puoi mescolare agenti senza riscrivere il processo?

Lock-in – Cosa perdi se cambi editor, modelli o fornitori di cloud in sei mesi?

GitHub Spec Kit

GitHub Spec Kit è un toolkit CLI open-source che imposta un ciclo guidato da specifica nel tuo repository e lascia l’esecuzione a qualsiasi agente di coding che già usi. La CLI specify deposita template, comandi slash e un layout cartelle convenzionale. I comandi tipici seguono una sequenza costituzione-specifica-clarifica-pianifica-attività-implementa, con un passo esplicito di chiarimento per risolvere ambiguità prima che inizi il lavoro di architettura.

Il vantaggio distintivo di Spec Kit è l’indipendenza dall’agente. I documenti ufficiali lo posizionano come tooling che funziona con Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex e decine di altri agenti. Scrivi le specifiche una volta in markdown, le commetti come codice e cambi l’esecutore senza riscrivere il processo. Questo rende Spec Kit la raccomandazione predefinita per i team che vogliono SDD senza scommettere su un singolo fornitore.

I compromessi sono reali. Spec Kit può produrre un grande albero di artefatti – costituzione, specifica, piano, attività, contratti – che ripaga nelle funzionalità multi-sessione ma sembra pesante per una piccola modifica CLI. I thread di Hacker News confrontano regolarmente quell’overhead con il rituale waterfall. Spec Kit è anche più debole se vuoi un IDE completamente integrato dove specifiche, attività e implementazione vivono in una singola superficie guidata. Aggiunge processo sopra il tuo editor esistente anziché sostituirlo.

Spec Kit si adatta ai team che hanno già un assistente AI di coding preferito e vogliono una impalcatura SDD standardizzata sopra. È particolarmente forte per funzionalità greenfield, aziende multi-agente e chiunque si rifiuti di accettare il lock-in dell’editor.

AWS Kiro

Kiro è l’IDE guidato da specifica di AWS, costruito su un fork di VS Code / Code OSS. Dove Spec Kit porta lo SDD al tuo stack esistente, Kiro assume che lo SDD meriti un ambiente costruito apposta. Un prompt genera artefatti strutturati – tipicamente requirements.md in notazione stile EARS, design.md e una tasks.md sequenziata per dipendenze – prima che gli agenti scrivano codice di produzione.

L’esperienza guidata è il principale punto di vendita di Kiro. Requisiti, progettazione e attività sono oggetti UI di prima classe accanto al tuo codice, non file che gestisci attraverso una CLI separata. Kiro offre anche Agent Hooks, automazioni event-driven che possono aggiornare test, documenti o artefatti correlati quando l’implementazione cambia. Quel ciclo bidirezionale è qualcosa che Spec Kit non fornisce out of the box – le specifiche di Spec Kit restano statiche finché un umano non le aggiorna.

I costi sono profondità di integrazione scambiata per portabilità. Kiro gira nel suo editor, usa modelli supportati da AWS Bedrock e fattura attraverso un modello di prezzo basato su crediti con piani a livelli. I team enterprise già su infrastruttura AWS spesso lo trovano accettabile. Gli sviluppatori solisti e i team multi-editor forse no. Kiro ha anche spigoli tipici di un IDE più nuovo – compatibilità estensioni, sorprese nei flussi di lavoro e la solita domanda “ho davvero bisogno di un altro editor?”.

Kiro si adatta agli sviluppatori che vogliono l’esperienza SDD più guidata e sono a proprio agio adottando un IDE nativo per specifiche. È un’opzione forte per i team enterprise, ambienti pesanti su AWS e chiunque migra da Amazon Q Developer volendo disciplina specifica senza assemblare manualmente la toolchain. Se oggi vivi in VS Code e ami il tuo setup attuale, Kiro chiede un cambio più grande di quanto faccia Spec Kit.

Comandi Personalizzati e Skills di Claude Code

Claude Code non offre un unico prodotto SDD ufficiale come fanno Spec Kit o Kiro. Se sei nuovo allo strumento stesso, inizia con la guida all’installazione e configurazione di Claude Code} per setup, permessi e backend locali. Il pattern SDD stesso vive nei comandi personalizzati, nelle skills e nei template markdown locali al repo che gli sviluppatori mantengono. Anthropic ha fuso i vecchi file .claude/commands/*.md nel meccanismo Skills, quindi il pattern durevole è un SKILL.md (o equivalente) che definisce il tuo checklista specifica-pianifica-implementa, caricato su richiesta.

Questo approccio è il più leggero e modificabile. Puoi portare un layout a tre file stile Kiro, rispecchiare le fasi di Spec Kit con comandi slash o inventare un flusso di lavoro minimo che si adatti a un singolo repository. Claude Code legge CLAUDE.md per il contesto di progetto sempre attivo e preleva skills quando il task corrisponde. Quell’espansione progressiva mantiene le sessioni focalizzate senza caricare un’intera costituzione a ogni prompt.

Lo svantaggio è la disciplina. Niente ti costringe a passare per gate di chiarimento o revisione a meno che non tu li costruisci tu stesso. I thread di Reddit e Hacker News su “sviluppo guidato da specifica dentro Claude Code” sono pieni di sviluppatori che hanno copiato la skill di qualcun altro, l’hanno eseguita una volta e sono tornati al prompting non strutturato quando la skill sembrava lenta. Lo SDD di Claude Code funziona quando tratti le skills come codice – versionate, revisionate e mantenute – non come un download di prompt una tantum.

Per un’implementazione seria, leggi Claude Skills e SKILL.md per Sviluppatori} e codifica le tue fasi come skills con punti di controllo revisione espliciti. Lo SDD di Claude Code è la scelta giusta quando vivi già in Claude Code, vuoi massima flessibilità e manterrai tu stesso il flusso di lavoro. Per il passo di gate di revisione in particolare, i sottagenti di Claude Code possono eseguire un passaggio di revisione indipendente a contesto isolato sul codice generato prima di mergeare un task – un sostituto leggero per il ruolo di verifica che gli Agent Hooks di Kiro forniscono nativamente.

Superpowers: Una Versione Imballata dello Stack di Skills Fai-da-te

Se assemblare manualmente quello stack di skills sembra esattamente il problema di disciplina avvisato dalla tabella sopra, Superpowers} merita uno sguardo. È un pacchetto di skills open-source – brainstorming, writing-plans, subagent-driven-development, test-driven-development, requesting-code-review e un pugno di skills di supporto – distribuito come plugin installabile piuttosto che qualcosa che scrivi da zero. Mira direttamente al limite “la qualità dipende interamente dalla disciplina dell’autore”: le skill si attivano automaticamente e sono destinate a essere flussi di lavoro obbligatori, non suggerimenti opzionali che l’agente può saltare.

Il flusso di lavoro che impone mappa strettamente il ciclo a cinque fasi coperto nel Flusso di Lavoro dello Spec-Driven Development dai requisiti al codice}: il brainstorming raffina un’idea vaga in un documento di progettazione revisionato, writing-plans lo spezza in piccoli task verificabili, subagent-driven-development dispatcha un nuovo sottagente per task con una revisione a due stadi, e test-driven-development impone un rigoroso red-green-refactor prima che qualcosa sia considerato fatto. Quest’ultima parte è più stretta di quanto la maggior parte delle skills SDD di Claude Code si preoccupi di essere – Superpowers elimina esplicitamente il codice scritto prima che esistesse un test fallente per esso.

A differenza di una skill locale al repo che scrivi tu, Superpowers non è solo per Claude Code. Offre manifesti di plugin per Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid e diversi altri agenti, quindi la stessa metodologia ti segue tra gli ambienti invece di vivere in una sola cartella .claude/skills/. Questo lo rende una via di mezzo tra scrivere la tua skill Claude Code e adottare uno strumento più pesante e specifico per IDE come Kiro: ottieni un ciclo opinione e imposto senza rinunciare al tuo editor o impegnarti nel formato specifico di un singolo fornitore.

Superpowers si adatta agli sviluppatori che amano in principio l’approccio delle skills di Claude Code ma continuano a scivolare indietro al prompting non strutturato perché niente impone i gate di revisione. È un adattamento più debole se hai già una skill SDD specifica per il progetto adattata al tuo stack – in quel caso stai scambiando una piccola quantità di personalizzazione per una maggiore quantità di cerimoniale imposto.

BMAD, OpenSpec e Altri Flussi di Lavoro

Non ogni team vuole l’albero di artefatti di Spec Kit o l’IDE Kiro. Due alternative emergono costantemente nei confronti del 2026.

OpenSpec (Fission AI) adotta un approccio centrato sui cambiamenti con meno file generati di Spec Kit. I benchmark della community riportano un uso di token materialmente inferiore per task comparabili, al costo di meno struttura preliminare. OpenSpec tende a vincere quando stai modificando una codebase esistente e vuoi specifiche revisionabili senza una fase di pianificazione di 800 righe. Compete con Spec Kit sulla portabilità più che con Kiro sull’integrazione IDE. Vedi il quickstart di OpenSpec} per i passi di installazione, il ciclo esplora-proponi-applica-archivia e gli errori che emergono di più su Reddit.

BMAD-METHOD (community) spinge nella direzione opposta – flussi di lavoro multi-agente, basati su ruoli, che simulano personaggi di product owner, architetto, sviluppatore e revisore. BMAD può essere potente su grandi sforzi greenfield dove la separazione esplicita dei ruoli aiuta. È anche pesante. I team riportano spesso che il cerimoniale ripaga solo quando il dolore di coordinamento è già acuto.

Tessl tratta la specifica come la letterale fonte del codice generato, marcando l’output come derivato e scoraggiando le modifiche a mano. Questa è la posizione “specifiche come sorgente” più forte tra gli strumenti mainstream, ma Tessl resta in beta e porta il lock-in di prodotto più alto del gruppo.

Spec Kitty e altri scaffold della community si collocano tra OpenSpec e Spec Kit in termini di peso. Valgono la attenzione se vuoi template senza adottare l’intera toolchain GitHub.

gstack va un passo oltre il livello delle specifiche: avvolge l’agente di coding in un intero team di ingegneria virtuale – revisione del prodotto, revisione di architettura e progettazione, QA browser, audit di sicurezza e la catena di rilascio ship-deploy – in modo che la specifica sia uno dei diversi stage imposti invece della spina dorsale. Gira su Claude Code e altri nove agenti, e la guida copre come far sì che Spec Kit (o OpenSpec) possieda la spina dorsale della pianificazione mentre gstack fornisce i livelli che uno strumento di specifica non impone.

Il pattern attraverso tutti loro è lo stesso. Più processo aiuta quando l’ambiguità è costosa. Più processo danneggia quando la velocità di feedback conta più dell’allineamento. Abbina il peso dello strumento alla dimensione del task, non all’hype.

Quale Setup SDD Dovresti Usare?

Non c’è un vincitore universale. Il setup giusto dipende da chi sei, cosa stai costruendo e quanta struttura manterrai realmente.

Sviluppatore solista, codebase esistente, piccole funzionalità. Inizia con skills di Claude Code o OpenSpec. Scrivi un breve blocco requisiti, una lista attività minima e un punto di controllo revisione. Non installare un intero albero Spec Kit per una modifica di cinquanta righe.

Vuoi l’approccio delle skills di Claude Code ma continui a saltare i tuoi gate di revisione. Installa Superpowers invece di scrivere una skill custom da zero. Rinunci ad alcuni aggiustamenti specifici per il progetto in cambio di un ciclo brainstorm-pianifica-implementa-revisiona imposto che non dipende dalla tua disciplina del giorno.

Sviluppatore solista, funzionalità greenfield, più sessioni. Spec Kit o una ben mantenuta skill SDD di Claude Code. Hai bisogno di artefatti durevoli più che di mano guida dell’IDE.

Piccolo team, editor misti. Spec Kit. Specifiche semplice markdown in Git, revisionate in pull request, eseguite da qualsiasi agente che ogni sviluppatore preferisca.

Team enterprise, AWS-native, pressione di conformità. Kiro. Artefatti guidati, tracciabilità dei requisiti e hook che tengono documenti e test più vicini all’implementazione.

Ambiente regolamentato. Kiro o Spec Kit più la tua lista di validazione – non solo skills di Claude Code a meno che non codifichi esplicitamente i gate di conformità. Il tooling non sostituisce i trail di audit. Li rende solo più facili da produrre.

Codebase esistente, modifica brownfield. OpenSpec o un flusso di lavoro leggero di Claude Code. Il cerimoniale completo di Spec Kit su ogni bugfix sembrerà waterfall. Riserva struttura più pesante per funzionalità trasversali.

Prodotto greenfield, molti agenti. Spec Kit. La portabilità conta più della lucidatura dell’IDE quando Copilot, Claude Code e Cursor potrebbero tutti toccare lo stesso repo.

I team che sperimentano con l’orchestrazione multi-agente dovrebbero guardare anche Oh My OpenCode Agents} per pattern sulla separazione dei ruoli tra agenti – complementare agli artefatti SDD, non un sostituto per essi. Se il tuo team esegue un agente terminal-first invece di uno integrato nell’IDE, la guida pratica alla CLI di OpenCode) mostra la versione più leggera, a livello di prompt, della stessa disciplina pianifica-prima-di-implementare – utile quando un intero albero Spec Kit è più cerimoniale di quanto il task meriti.

Tabella di Decisione Pratica

Cosa Determina Realmente il Successo

La scelta dello strumento conta meno della qualità dell’artefatto. Un file requisiti Kiro con criteri di accettazione vaghi produrrà lo stesso drift di un prompt Claude Code disordinato. Un piano Spec Kit che elenca cinquanta attività ridondanti sembrerà waterfall indipendentemente da quale agente lo implementi.

Le pratiche che viaggiano attraverso ogni setup sono noiose ed efficaci. Mantieni le specifiche abbastanza piccole da essere revisionate in una sola seduta. Scrivi i non-obiettivi esplicitamente. Spezza i task in diff che un umano può leggere. Valida contro i criteri di accettazione prima del merge. Aggiorna la specifica quando l’implementazione scopre un percorso migliore.

Se stai ancora scegliendo tra SDD e prompting non strutturato per una data funzionalità, leggi Spec-Driven Development vs Vibe Coding. Il confronto degli strumenti in questo articolo ha importanza solo dopo che hai deciso che la funzionalità merita una specifica.

Specifiche scadenti rendono ogni agente peggiore. Specifiche buone viaggiano tra gli strumenti.

Conclusione

GitHub Spec Kit, Kiro e i flussi di lavoro di Claude Code sono tre risposte alla stessa domanda – come tenere allineati gli agenti AI tra le sessioni – con puntate diverse su portabilità rispetto a integrazione. Spec Kit ottimizza per markdown agnostico agli agenti nel tuo repository. Kiro ottimizza per un IDE nativo per specifiche guidato con agenti supportati da AWS. Le skills di Claude Code ottimizzano per flussi di lavoro modificabili e leggeri che riescono solo quando li mantieni tu.

Scegli il setup più superficiale che ancora rimuove l’ambiguità per la funzionalità in questione. Aggiungi struttura quando appare il dolore di coordinamento, non quando un post di blog te lo dice. Gli sviluppatori che ottengono valore dallo SDD nel 2026 non sono quelli con la toolchain più elaborata. Sono quelli che scrivono specifiche degne di essere implementate – e poi lasciano che qualsiasi strumento abbiano scelto esegua contro di esse.

Link Utili

• Documentazione di GitHub Spec Kit – riferimento ufficiale del flusso di lavoro Spec Kit
• Superpowers Quickstart: Installazione, Flusso di Lavoro e Prova} – pacchetto di skills open-source che impone una metodologia brainstorming-a-TDD tra Claude Code, Cursor, Codex e altri agenti
• gstack: Uno Stack Opinato di Ingegneria Software AI} – l’opzione team di ingegneria virtuale completo, e come si combina con Spec Kit, OpenSpec e Superpowers
• Martin Fowler sugli strumenti SDD – analisi di Kiro, Spec Kit e Tessl