SpecScore vs Kiro

Sviluppo guidato dalle specifiche (SDD) significa scrivere che cosa deve fare il software prima che un agente IA scriva il codice. Kiro, di Amazon Web Services (AWS), è un ambiente di sviluppo agentico — un editor, un’interfaccia a riga di comando (CLI) e un’app web — che trasforma un prompt in Kiro specs: requisiti, una progettazione e attività. Quei requisiti usano EARS (Easy Approach to Requirements Syntax), frasi della forma «WHEN accade qualcosa, THE SYSTEM SHALL fare qualcosa». SpecScore è un formato a codice aperto per la specifica stessa, più una CLI che controlla i file. L’integrazione continua (CI) — un controllo automatico su ogni modifica proposta — può rifiutare una specifica SpecScore che rompe il formato.

Ultimo aggiornamento: 30 ottobre 2026

Cosa hanno in comune.

Entrambi trattano una specifica scritta come ciò da cui un agente deve costruire, non come la trascrizione di una chat.
Entrambi tengono quella specifica come Markdown nel progetto, così si può revisionare come il codice.
Entrambi spezzano il lavoro in requisiti, una progettazione e attività. Kiro genera quei tre file. SpecScore è un formato che un team può conservare quando la sessione finisce.

Cosa fa bene Kiro.

La documentazione di Kiro, letta il 30 ottobre 2026, descrive il prodotto. La pagina delle specifiche di funzionalità risultava aggiornata il 4 agosto 2026.

Requisiti in una forma di frase fissa

Le Kiro specs mettono il comportamento in requirements.md con un modello EARS: WHEN vale una condizione, THE SYSTEM SHALL fare una cosa. La documentazione fa l’esempio di un modulo con dati non validi, e il sistema mostra un errore di validazione accanto al campo. Quella forma è più facile da verificare di un paragrafo vago.

Un percorso completo dal prompt alle attività

Una specifica di funzionalità passa per requisiti, progettazione (design.md) e attività (tasks.md). Puoi partire dai requisiti o da una progettazione. Quick Spec esegue tutte e tre senza una sosta di approvazione in mezzo. Le Bugfix specs sono un percorso a parte. La documentazione descrive anche l’esecuzione di attività indipendenti in parallelo, a ondate, a partire dal grafo delle dipendenze in tasks.md.

Controlli dentro il prodotto

Analyze Requirements, disponibile nell’IDE e nella CLI, cerca incoerenze, ambiguità, vincoli in conflitto e lacune prima della progettazione. Correctness — test basati sulle proprietà ricavati da quelle righe EARS — è indicato solo per l’IDE, non per la CLI, il web o il mobile, nella tabella delle capacità delle specs.

Confronto delle funzionalità.

Kiro è un prodotto che stende specifiche. SpecScore è il formato che un repository può controllare. La tabella confronta questi ruoli.

Capacità	Kiro	SpecScore
Ruolo principale	IDE agentico, CLI e app web che stendono specifiche e implementano le attività	Formato di specifica aperto + CLI
File della specifica	`requirements.md` (oppure `bugfix.md`), `design.md`, `tasks.md`	Un albero spec/ di Markdown + YAML
Sintassi dei requisiti	Modello EARS: WHEN … THE SYSTEM SHALL …	Id dei requisiti (`REQ: slug`) e criteri di accettazione Dato/Quando/Allora
Controllare la specifica	Analyze Requirements nell’IDE e nella CLI. Test basati sulle proprietà nell’IDE. Non è descritto come un linter di formato per la tua CI.	specscore spec lint nella CI. `/score` è una valutazione IA separata e manuale.
Dove gira	Kiro IDE, Kiro CLI, Kiro web. Alcuni controlli sono solo nell’IDE.	Qualsiasi repository — un binario Go, senza account Kiro
Licenza	La licenza di Kiro dice che l’IDE e la CLI sono AWS Content secondo l’AWS Customer Agreement. Kiro Crew è un repository pubblico a parte.	CC BY 4.0 per il formato · Apache-2.0 per la CLI
Prezzo	Un piano gratuito e piani a pagamento. Le cifre cambiano — vedi i prezzi di Kiro, letti il 30 ottobre 2026.	Nessun costo per il formato né per la CLI

Cosa aggiunge SpecScore.

Il formato fa fallire la CI da solo

L’analisi di Kiro gira dentro Kiro. Il controllo di SpecScore è un comando. Il flusso dogfood di questo repository esegue specscore spec lint su ogni pull request e su main. Una specifica rotta fa fallire l’esecuzione come farebbe un test rotto. La skill /score valuta la formulazione con revisori IA; quel passaggio è manuale, e il flusso sopra non lo esegue.

$ specscore spec lint

features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found
features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds
features/apply-discount/refunds:0 [error] readme-exists: README.md not found

3 violations found (3 errors)

La specifica non è legata a un solo IDE

Le Kiro specs sono Markdown, quindi puoi leggerle senza il prodotto. Il flusso che le crea e le esegue è quello di Kiro. Un albero SpecScore sono gli stessi file per Claude Code, Cursor, Copilot o nessun agente — la CLI non chiama un modello per il lint.

I requisiti tengono un id

La documentazione di Kiro descrive la tracciabilità come seguire un requisito attraverso l’implementazione. Non descrive un id stabile che sopravviva a una riscrittura. SpecScore indica un requisito come REQ: slug e un criterio di accettazione tramite il proprio id.

EARS e Dato/Quando/Allora rispondono a domande diverse

EARS, come lo documenta Kiro, è una frase di comportamento del sistema. I criteri di accettazione di SpecScore sono scenari Dato/Quando/Allora legati a un id di requisito. Puoi scrivere una riga EARS nella prosa e tenere comunque lo scenario nel file SpecScore che il linter controlla. I modelli di frase sono in la sintassi dei requisiti EARS.

Quando usare l'uno o l'altro.

Scegli Kiro quando…

Vuoi un IDE agentico AWS che stenda requisiti, progettazione e attività a partire da un prompt e poi implementi le attività.
Vuoi frasi EARS e, nell’IDE, test basati sulle proprietà generati da esse.
Il tuo team si sta già standardizzando sull’editor, sulla CLI o sull’app web di Kiro.

Usa SpecScore se…

La specifica deve restare valida nella CI dopo la fine della sessione dell’agente, in un repository che non richiede Kiro.
Ti servono id dei requisiti, lo stato del ciclo di vita e un risultato di lint deterministico.
Vuoi il formato a codice aperto e un verificatore che sia un solo binario.

Kiro può stendere la bozza. SpecScore può fare da sbarramento.

Niente di quanto scritto qui sostituisce l’editor di Kiro. Se Kiro è dove il team scrive il prompt, lascia che stenda la bozza. Se la specifica deve sopravvivere come file revisionato, scrivi quel contratto in SpecScore e lascia che specscore spec lint faccia fallire la pull request quando la struttura si rompe. I due file possono stare nello stesso repository.

Scegli Kiro per la sessione. Scegli SpecScore per l’artefatto che un’esecuzione di CI può rifiutare.

Fonti.

Le pagine pubbliche qui sotto sono state lette il 30 ottobre 2026. Prezzi, nomi dei piani e linee di rilascio cambiano.

Altri confronti.

Lo stesso formato, accanto ad altri strumenti di sviluppo guidato dalle specifiche:

Tutti insieme, in una pagina: migliori strumenti di sviluppo guidato dalle specifiche nel 2026.

Questo confronto si basa su documentazione e codice sorgente pubblici. Qualcosa è sbagliato o superato? apri una issue di correzione. Vuoi che confrontiamo SpecScore con un altro strumento? richiedine uno.