SpecScore vs OpenSpec

Tous deux placent les spécifications en Markdown, aux côtés de votre code, lisibles par les agents d'IA. Ils répondent à des problématiques différentes : OpenSpec organise les spécifications et génère des commandes pour les agents. SpecScore valide le contenu des spécifications, applique le cycle de vie et relie le code aux exigences.

Ce qu'ils ont en commun.

Les spécifications vivent dans votre dépôt sous forme de fichiers Markdown — versionnées, révisables dans les PRs.
Tous deux sont open source sous licence MIT.
Tous deux emploient des critères d'acceptation Given/When/Then.
Tous deux traitent les agents d'IA comme des consommateurs de premier ordre des spécifications.

Ce qu'OpenSpec fait bien.

Le support d'agents le plus large

OpenSpec prend en charge 29 agents d'IA via des fichiers de skills générés — Claude, Cursor, Copilot, Gemini, Windsurf, Cline et bien d'autres. Si votre agent figure sur la liste, OpenSpec s'intègre immédiatement sans configuration.

Faible barrière à l'entrée

npm install -g @fission-ai/openspec && openspec init et vous rédigez déjà des spécifications. Aucun schéma à assimiler, aucun frontmatter obligatoire. Conçu pour être simple — particulièrement pour les projets existants.

Modèle propre de deltas de modifications

Le format ADDED / MODIFIED / REMOVED d'OpenSpec pour faire évoluer les spécifications est bien conçu. Chaque modification est un dossier contenant une proposition, des deltas de spécification et des tâches — une approche structurée pour proposer des changements.

Comparaison des fonctionnalités.

Capacité	OpenSpec	SpecScore
Format de spécification	Markdown (sans frontmatter)	Markdown + YAML frontmatter
Linting de spécification	Structure des fichiers uniquement	Qualité du contenu — verbes flous, AC manquants, références orphelines
IDs d'exigences	Aucun (référencés par titre)	Basés sur slug (`REQ: slug-format`)
IDs de critères d'acceptation	Aucun	IDs adressables par machine
État du cycle de vie	Implicite (emplacement du fichier)	Appliqué — Draft → Under Review → Approved → Implementing → Stable → Deprecated
Traçabilité code-vers-spécification	Aucune	Annotations `specscore:` + trailers de commit `Verifies:`
Sous-features	Non	Oui (répertoires imbriqués)
Références croisées	Sans mécanisme formel	Dépendances, Ideas d'origine, références aux plans
Intégration CI	Basique (`openspec validate`)	`specscore lint` avec sévérité configurable, hooks pre-commit
Support des agents	29 agents	Claude Code comme cible principale + CLI pour tout agent
Personnalisation du schéma	Oui (`schema.yaml`, fork/init)	Schéma fixe (cohérence dès la conception)
Propositions de changement	Modèle delta (ADDED/MODIFIED/REMOVED)	Ideas de changement + propositions
Dépendance de runtime	Node.js 20.19+	Aucune — binaire Go unique
Licence	MIT	MIT

Où SpecScore va plus loin.

La validation dépasse la simple structure de fichiers

La commande validate d'OpenSpec vérifie la structure des fichiers — si le fichier existe, s'il a les bonnes sections. SpecScore vérifie plus, en deux couches : lint vérifie de manière déterministe les relations de contenu — chaque exigence a des critères d'acceptation, les références croisées sont résolues, les transitions d'état sont valides — et un réviseur par IA (/review, /score) détecte ce qu'aucun linter ne peut voir : critères ambigus et verbes flous.

$ specscore lint checkout/apply-discount.md
  ✗ R3  no acceptance criteria
  ✗ link  "Related Feature: discount-tiers" not found

Chaque exigence a un ID lisible par machine

OpenSpec référence les exigences par leur titre — fragile face aux renommages. SpecScore attribue des IDs basés sur le slug (REQ: slug-format) et des IDs d'AC qui résistent aux renommages, refactorisations et passages de relais entre agents.

Le cycle de vie est appliqué, non déduit

Dans OpenSpec, le cycle de vie d'une spécification se résume à son emplacement : specs/ (actuel), changes/ (proposé), archive/ (terminé). Dans SpecScore, le cycle de vie est un champ d'état appliqué — Draft → Under Review → Approved → Implementing → Stable → Deprecated — validé par le lint, transité via specscore change-status depuis les git hooks ou la CI.

Le code remonte jusqu'aux spécifications

OpenSpec n'a aucun mécanisme de traçabilité. SpecScore propose des annotations specscore: dans les commentaires du code et des trailers Verifies: dans les commits. Exécutez specscore code refs et obtenez une réponse déterministe à « quel code implémente cette exigence ? »

Aucune dépendance de runtime

OpenSpec nécessite Node.js 20.19+. SpecScore est un binaire Go unique — sans runtime, sans node_modules. Fonctionne dans les projets Go, Rust, Python, Java sans ajouter Node à votre chaîne d'outils.

Hiérarchie d'artefacts composable

Les spécifications d'OpenSpec sont plates par domaine. SpecScore propose une hiérarchie typée : les Ideas se promeuvent en Features, les Features contiennent des exigences et des AC, les Plans référencent les AC, les Tasks référencent les Plans. Toutes les relations sont navigables par machine via le CLI.

Quand utiliser chacun.

Commencez avec OpenSpec quand…

Vous utilisez Cursor, Copilot ou d'autres agents hors-Claude et souhaitez une intégration prête à l'emploi.
Vous introduisez des spécifications dans un codebase existant pour la première fois et voulez zéro friction.
Votre équipe privilégie la flexibilité de schéma par rapport à une rigueur stricte.

Utilisez SpecScore quand…

Vous avez besoin d'un contrôle qualité des spécifications — le lint détecte les ambiguïtés avant que les agents ne gaspillent des tokens.
Vous avez besoin de traçabilité code-vers-spécification — « quel code implémente cette exigence ? » renvoie une réponse déterministe.
Vous construisez un vaste système avec de nombreuses features, sous-features et transitions de cycle de vie.
Vous voulez zéro dépendance de runtime — un binaire unique, sans Node.js requis.
Vous avez besoin de barrières de qualité en CI — specscore lint quitte avec un code non nul en cas d'échec, tout comme ESLint ou go vet.

Ils ne s'excluent pas mutuellement.

SpecScore peut linter les fichiers spec.md d'OpenSpec. Les équipes qui démarrent avec OpenSpec peuvent ajouter la couche de qualité de SpecScore sans migrer — validez les spécifications que vous avez déjà, ajoutez la traçabilité quand vous en avez besoin, appliquez le cycle de vie quand votre équipe grandit.

OpenSpec est une bonne rampe de lancement. SpecScore apporte les garde-fous.

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.