SpecScore vs Kiro

Développement piloté par les spécifications (SDD) signifie écrire ce que le logiciel doit faire avant qu’un agent d’IA n’écrive le code. Kiro, d’Amazon Web Services (AWS), est un environnement de développement agentique — un éditeur, une interface en ligne de commande (CLI) et une application web — qui transforme un prompt en Kiro specs : exigences, une conception et des tâches. Ces exigences utilisent EARS (Easy Approach to Requirements Syntax), des phrases de la forme « WHEN quelque chose se produit, THE SYSTEM SHALL faire quelque chose ». SpecScore est un format à code source ouvert pour la spécification elle-même, plus un CLI qui vérifie les fichiers. L’intégration continue (CI) — une vérification automatique à chaque changement proposé — peut rejeter une spécification SpecScore qui rompt le format.

Dernière mise à jour : 30 octobre 2026

Ce qu'ils partagent.

Les deux traitent une spécification écrite comme ce à partir de quoi un agent doit construire, et non comme la transcription d’une conversation.
Les deux conservent cette spécification en Markdown dans le projet, afin qu’elle se relise comme du code.
Les deux découpent le travail en exigences, une conception et des tâches. Kiro génère ces trois fichiers. SpecScore est un format qu’une équipe peut garder après la fin de la session.

Ce que Kiro fait bien.

La documentation propre de Kiro, lue le 30 octobre 2026, décrit le produit. La page des spécifications de fonctionnalité était marquée comme mise à jour le 4 août 2026.

Des exigences dans une forme de phrase fixe

Les Kiro specs placent le comportement dans requirements.md selon un motif EARS : WHEN une condition est vraie, THE SYSTEM SHALL faire une chose. La documentation donne l’exemple d’un formulaire avec des données invalides, et le système affiche une erreur de validation à côté du champ. Cette forme est plus facile à tester qu’un paragraphe vague.

Un chemin complet du prompt aux tâches

Une spécification de fonctionnalité passe par les exigences, la conception (design.md) et les tâches (tasks.md). Vous pouvez partir des exigences ou d’une conception. Quick Spec exécute les trois sans arrêt d’approbation entre elles. Les Bugfix specs sont un chemin distinct. La documentation décrit aussi l’exécution de tâches indépendantes en parallèle, par vagues, à partir du graphe de dépendances dans tasks.md.

Des vérifications dans le produit

Analyze Requirements, disponible dans l’IDE et le CLI, cherche les incohérences, l’ambiguïté, les contraintes en conflit et les manques avant la conception. Correctness — des tests basés sur les propriétés, tirés de ces lignes EARS — est indiqué pour l’IDE seulement, pas pour le CLI, le web ou le mobile, dans le tableau de capacités des specs.

Comparaison des fonctionnalités.

Kiro est un produit qui rédige des spécifications. SpecScore est le format qu’un dépôt peut vérifier. Le tableau compare ces rôles.

Capacité	Kiro	SpecScore
Rôle principal	IDE agentique, CLI et application web qui rédigent des spécifications et mettent en œuvre les tâches	Format de spécification ouvert + CLI
Fichiers de spécification	`requirements.md` (ou `bugfix.md`), `design.md`, `tasks.md`	Une arborescence spec/ en Markdown + YAML
Syntaxe des exigences	Motif EARS : WHEN … THE SYSTEM SHALL …	Identifiants d’exigences (`REQ: slug`) et critères d’acceptation Étant donné/Quand/Alors
Vérifier la spécification	Analyze Requirements dans l’IDE et le CLI. Tests basés sur les propriétés dans l’IDE. Non décrit comme un linter de format pour votre propre CI.	specscore spec lint dans la CI. `/score` est une note d’IA distincte et manuelle.
Où cela s’exécute	Kiro IDE, Kiro CLI, Kiro web. Certaines vérifications n’existent que dans l’IDE.	N’importe quel dépôt — un binaire Go, sans compte Kiro
Licence	La licence Kiro dit que l’IDE et le CLI sont de l’AWS Content sous l’AWS Customer Agreement. Kiro Crew est un dépôt public distinct.	CC BY 4.0 pour le format · Apache-2.0 pour le CLI
Prix	Un palier gratuit et des offres payantes. Les chiffres bougent — voir les tarifs Kiro, lus le 30 octobre 2026.	Sans frais pour le format ni pour le CLI

Ce que SpecScore apporte en plus.

Le format fait échouer la CI de lui-même

L’analyse de Kiro s’exécute dans Kiro. La vérification de SpecScore est une commande. Le flux dogfood de ce dépôt exécute specscore spec lint sur chaque pull request et sur main. Une spécification cassée fait échouer l’exécution comme le ferait un test cassé. La skill /score note le libellé avec des relecteurs d’IA ; cette passe est manuelle, et le flux ci-dessus ne l’exécute pas.

$ 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 spécification n’est pas liée à un seul IDE

Les Kiro specs sont du Markdown, vous pouvez donc les lire sans le produit. Le flux qui les crée et les exécute est celui de Kiro. Une arborescence SpecScore, ce sont les mêmes fichiers pour Claude Code, Cursor, Copilot ou aucun agent — le CLI n’appelle pas de modèle pour linter.

Les exigences gardent un identifiant

La documentation de Kiro décrit la traçabilité comme le suivi d’une exigence à travers l’implémentation. Elle ne décrit pas d’identifiant stable qui survive à une réécriture. SpecScore désigne une exigence par REQ: slug et un critère d’acceptation par son propre identifiant.

EARS et Étant donné/Quand/Alors répondent à des questions différentes

EARS, tel que Kiro le documente, est une phrase de comportement du système. Les critères d’acceptation SpecScore sont des scénarios Étant donné/Quand/Alors liés à un identifiant d’exigence. Vous pouvez écrire une ligne EARS dans la prose et garder quand même le scénario dans le fichier SpecScore que le linter vérifie. Les patrons de phrase sont dans la syntaxe des exigences EARS.

Quand choisir l'un ou l'autre.

Choisissez Kiro quand…

Vous voulez un IDE agentique AWS qui rédige exigences, conception et tâches à partir d’un prompt, puis met les tâches en œuvre.
Vous voulez des phrases EARS et, dans l’IDE, des tests basés sur les propriétés générés à partir d’elles.
Votre équipe se standardise déjà sur l’éditeur, le CLI ou l’application web de Kiro.

Utilisez SpecScore quand…

La spécification doit rester valide dans la CI après la fin de la session de l’agent, dans un dépôt qui n’exige pas Kiro.
Vous avez besoin d’identifiants d’exigences, d’un statut de cycle de vie et d’un résultat de lint déterministe.
Vous voulez le format à code source ouvert et un vérificateur qui soit un seul binaire.

Kiro peut rédiger. SpecScore peut servir de barrière.

Rien ici ne remplace l’éditeur de Kiro. Si Kiro est l’endroit où l’équipe écrit le prompt, laissez-le rédiger. Si la spécification doit survivre comme fichier relu, écrivez ce contrat dans SpecScore et laissez specscore spec lint faire échouer la pull request quand la structure casse. Les deux fichiers peuvent cohabiter dans le même dépôt.

Choisissez Kiro pour la session. Choisissez SpecScore pour l’artefact qu’une exécution de CI peut refuser.

Sources.

Les pages publiques ci-dessous ont été lues le 30 octobre 2026. Les prix, les noms d’offres et les versions changent.

Autres comparaisons.

Le même format, à côté d’autres outils de développement piloté par les spécifications :

Tous ensemble, sur une page : meilleurs outils de développement piloté par les spécifications en 2026.

Cette comparaison repose sur une documentation et un code source publics. Quelque chose est faux ou périmé ? ouvrez un ticket de correction. Voulez-vous que nous comparions SpecScore à un autre outil ? demandez-en une.