Test OpenSpec : mon nouveau daily driver pour l’AI coding

Test OpenSpec : mon nouveau daily driver pour l’AI coding

La première fois que j'ai exécuté openspec apply sur un vrai projet, je me suis éloigné pour remplir mon café et je l'ai oublié. Deux heures et dix-sept minutes plus tard, je suis revenu à un tableau de bord fonctionnel, une suite de tests réussis et un dossier changes/ rempli de démarques qui expliquaient – ​​avec un niveau de détail que je n'aurais jamais écrit à la main – exactement ce qui venait d'être construit et pourquoi.

Ce n'est pas ce qui est impressionnant. Ce qui est impressionnant, c’est ce qui s’est passé le lendemain matin lorsque j’ai dû ajouter une deuxième fonctionnalité. Je n'ai pas ouvert le code. J'ai ouvert le dossier des spécifications. J'ai lu trois courts fichiers de démarques. Et je savais, avec une sorte de clarté que j'obtiens habituellement seulement après une semaine de chargement du contexte, exactement où la nouvelle fonctionnalité devait se connecter et ce qu'elle toucherait.

C'est à ce moment-là que j'ai compris ce que faisait réellement le OpenSpec AI coding framework - et pourquoi je pense que c'est le premier outil spec-driven qui survit au contact avec mon véritable flux de travail.

Je l'utilise comme daily driver depuis deux semaines sur trois projets : un outil d'administration Laravel que je refactorise pour un client, un projet parallèle Next.js que j'ai démarré à partir de zéro et une base de code Python existante dont j'ai hérité et qui a à peu près l'hygiène de la documentation d'une note d'otage. OpenSpec a gagné sa place dans les trois. Mais pas pour les raisons énumérées sur les pages marketing.

Voici la description complète : ce qu'est OpenSpec, où il se situe dans le paysage AI coding framework, les commandes exactes que j'exécute et les endroits honnêtes où cela n'aide pas. Si vous avez déjà passé des heures à regarder une session Claude Code générer du code par rapport à une spécification qui était erronée dès le début, les 4 000 mots suivants vous sembleront personnels.

Les trois catégories de cadres de AI coding (et pourquoi c'est important)

Avant que OpenSpec ait un sens, vous avez besoin de la carte du territoire dans lequel il vit. J'ai commis cette erreur la première fois que je l'ai évalué : je l'ai comparé à des outils qu'il n'a jamais essayé de battre, et je l'ai presque rejeté pour de mauvaises raisons.

Il existe trois catégories distinctes de AI coding framework expédiés en 2026, et elles résolvent différents problèmes :

Ces catégories ne s’affrontent pas. Ils s'empilent.

Une véritable pile de production ressemble plus à : OpenSpec écrit la spécification, Obra Superpowers applique TDD pendant la construction, BMAD orchestre le pipeline multi-agent qui expédie les PR pendant que vous dormez. Même problème sous trois angles. Différentes couches de la même machine.

Là où la plupart des articles « spec-driven vs autonome » tournent mal, c'est en les traitant comme des alternatives. Ce n’est pas le cas. Ce sont des niveaux. Et OpenSpec est le niveau inférieur, celui qui décide sur quoi les deux autres niveaux travailleront.

C'est pourquoi il est plus important de bien réussir cette couche que les couches situées au-dessus. Une compétence parfaite en matière d'application du TDD ne vous sauvera pas si la spécification qu'elle applique était erronée dès le premier jour. Un pipeline autonome qui expédie 40 PR dans un sprint enverra simplement 40 mauvais PR. La qualité des spécifications est le point d’étranglement en amont. Tout le reste amplifie la décision qui y a été prise – pour le meilleur ou pour le pire.

La question n'est donc pas « OpenSpec ou BMAD ? » La question est "OpenSpec est-il suffisamment bon pour être la source de vérité à laquelle tout le monde en aval fait confiance ?" C'est ce que je suis allé tester.

Qu'est-ce que OpenSpec ?

OpenSpec est un framework de développement open source spec-driven, livré sous le nom de package npm @fission-ai/openspec et maintenu par Fission-AI. Il s'exécute dans n'importe quel projet comme une fine couche au-dessus de votre assistant de AI coding — Claude Code, Cursor, Codex, Windsurf, Continue, GitHub Copilot, Amazon Q et une vingtaine d'autres selon la doc des outils pris en charge.

L'idée de base est brutale dans sa simplicité. La spécification est l'artefact. Le code est la cible de la compilation. Chaque fonctionnalité se trouve dans un fichier de démarque dans votre référentiel avant qu'une seule ligne de code ne soit écrite, et ce fichier devient le contrat que les assistants AI exécutent.

Trois choses à propos de cette idée comptent plus que l’idée elle-même.

Tout d'abord, les spécifications se trouvent dans votre dépôt. Pas dans un tableau de bord SaaS. Pas dans un document Notion qui dérive dès que quelqu'un clique sur « l'expédier ». Dans un dossier openspec/, dans git, avec les différences, vous pouvez consulter les PR comme n'importe quel autre changement de code. C'est la partie que la plupart des équipes sous-estiment jusqu'à ce qu'elles aient besoin de reconstruire ce qu'une fonctionnalité était censée faire six mois plus tard. Avec OpenSpec, vous git log répond aux spécifications.

Deuxièmement, les spécifications sont des deltas. OpenSpec a inventé quelque chose que je n'ai vu bien réalisé dans aucun autre cadre : la proposition n'est pas un nouveau document, c'est un changement par rapport à la spécification existante. Chaque proposition balise explicitement les ajouts, les modifications et les suppressions. Lorsque le changement est expédié, les deltas fusionnent dans la spécification principale. C'est la magie des friches industrielles : c'est ainsi que OpenSpec reste utilisable sur les bases de code existantes au lieu de vous obliger à créer une application de 200 000 lignes pour l'utiliser.

Troisièmement, le flux de travail est fluide, pas en cascade. Le cadrage officiel de Fission-AI est « fluide, pas rigide, itératif, pas en cascade » — et après deux semaines, je peux confirmer que ce n'est pas du marketing. Vous pouvez accéder au flux de travail à n'importe quelle phase, vous pouvez revenir en arrière lorsque l'implémentation révèle quelque chose que la spécification a manqué, et vous pouvez exécuter archive pour valider une modification partielle et en démarrer une nouvelle. Cela ressemble moins à un processus qu’à un cahier qui applique la structure.

La comparaison la plus claire est le [Spec Kit] de GitHub (https://github.com/github/spec-kit). J'ai testé les deux. Spec Kit est plus lourd - ses spécifications comportent environ 800 lignes par fonctionnalité selon le travail de comparaison Hashrocket publié, contre environ 250 pour OpenSpec. Spec Kit traite chaque fonctionnalité comme son propre fichier indépendant. OpenSpec se consolide en une seule source vivante de vérité qui mute au fil du temps. Pour une nouvelle fonctionnalité d'entreprise propre avec des portes d'examen formelles, la production plus lourde de Spec Kit est justifiée. Pour tout ce que je fais – refactors, projets parallèles, travail en agence – l’empreinte plus légère de OpenSpec l’emporte parce que la spécification est quelque chose que je vais réellement relire.

C'est la couche philosophique. Voici à quoi cela ressemble en pratique.

Installation de OpenSpec et de l'expérience de première exécution

La configuration est une commande. Pas "une commande après avoir installé trois dépendances". Une commande.

npm install -g @fission-ai/openspec
cd your-project
openspec init

Le nœud 20.19.0 ou supérieur est requis. La commande init vous demande quel assistant AI vous utilisez - j'ai choisi Claude Code sur le projet Laravel, Cursor sur celui Next.js, Codex sur la base de code Python - et elle écrit les liaisons de commande slash appropriées dans la configuration de votre projet afin que l'assistant sache comment invoquer OpenSpec.

C’est là que j’ai remarqué la première chose qui m’a fait faire confiance à l’outil. Lors d'une nouvelle initialisation, OpenSpec ne vous jette pas devant un document vierge et ne vous dit pas "bonne chance". Il exécute une compétence d'intégration qui vous guide de manière interactive à travers votre première proposition. Il vous demande ce que vous construisez. Il demande qui est l'utilisateur. Il demande quels sont les critères de réussite. Il le fait dans la démarque qui se trouve dans votre dépôt, donc le premier artefact que vous avez n'est pas un didacticiel - c'est le début d'une véritable spécification pour une vraie fonctionnalité.

Comparez cela à mon expérience commençant avec Spec Kit. L'intégration du Spec Kit suppose que vous connaissez déjà le modèle en quatre phases (/specify, /plan, /tasks, /implement) et vous amène directement à l'étape /specify. Si vous n'avez jamais utilisé le développement spec-driven auparavant, vous écrivez une spécification dont la forme est incorrecte et vous découvrez trois commandes plus tard lorsque /tasks produit des bêtises.

L'intégration de OpenSpec fait la différence entre apprendre en lisant et apprendre en faisant la bonne chose du premier coup. C'est un petit détail. C'est aussi pourquoi j'ai maintenant recommandé OpenSpec à deux amis qui n'avaient jamais touché au développement de spec-driven auparavant.

La référence des commandes : ce que chacun fait et quand je l'utilise

OpenSpec est livré avec un jeu de commandes de base et un jeu de commandes étendu appelé opsx que vous acceptez via openspec config profile. J'utilise le profil étendu parce que je veux tous les outils proposés par le framework. Voici le tableau complet, avec ce pour quoi j'utilise réellement chacun en production :

| /openspec:apply | Mettre en œuvre les tâches définies dans la proposition | La phase de construction — dure environ 2 heures en autonomie, 3-4 heures avec mes interruptions | | /opsx:verify | Valider la mise en œuvre par rapport aux spécifications, y compris les vérifications visuelles de l'interface utilisateur via l'intégration Chrome | Migrations de systèmes de conception, fonctionnalités gourmandes en interface utilisateur | | /openspec:archive | Fusionnez les deltas de changement dans la spécification principale, engagez la source vivante de vérité | Chaque fonctionnalité livrée, sans exception | | /opsx:bulk-archive | Archiver plusieurs modifications terminées en un seul passage | Fin d'un sprint lorsque j'ai livré 3 à 5 fonctionnalités | | /opsx:sync | Synchronisez le dossier des spécifications principales avec ce qui se trouve réellement dans la base de code | Quand je soupçonne une dérive entre le code et la spécification | | /opsx:onboard | Réexécutez la compétence d'intégration interactive | Intégrer un coéquipier ou un nouveau projet dans le flux de travail OpenSpec |

La liste complète des commandes se trouve dans le document officiel des commandes OpenSpec, et la référence de profil étendue se trouve dans le doc opsx. Ce qui ne figure pas dans la documentation, c'est l'ordre dans lequel je les exécute ou ceux que je saute – et c'est la section suivante.

Le workflow que j'exécute réellement

Voici la séquence exacte que j'ai suivie en envoyant une fonctionnalité de « chronologie de l'activité utilisateur » dans l'outil d'administration Laravel la semaine dernière. Le tout a pris environ quatre heures de temps d'horloge murale, dont peut-être quarante minutes pour moi et le reste pour OpenSpec travaillant en arrière-plan.

Étape 1 : Explorez avant de proposer

La première commande que j'exécute sur tout changement supérieur à "trivial" est /opsx:explore. Il s'agit de la fonctionnalité la plus sous-estimée du framework, et c'est la seule chose que OpenSpec fait et que GitHub Spec Kit refuse explicitement de faire.

La conception de Spec Kit suppose que vous entrez dans /specify en sachant déjà ce que vous voulez construire. Cette hypothèse est fausse environ 70 % du temps, d’après mon expérience. Ce que j'ai habituellement, c'est une idée floue, trois contraintes dont je me souviens à moitié et le pressentiment qu'il y a une complication dont je n'ai pas encore fait surface. Si j'écris une spécification à partir de cet état, la spécification sera fausse et je le découvrirai quatre étapes plus tard.

/opsx:explore me donne une phase pour me tromper à voix haute. L'agent me pose des questions de clarification. Il étudie la base de code. Cela fait apparaître des ambiguïtés dont j’ignorais l’existence. Concernant la fonctionnalité de chronologie des activités, l'exploration a détecté trois choses que j'aurais manquées si j'étais passé directement à une proposition : la table du journal d'audit existante présentait une ambiguïté de colonne qui aurait provoqué des collisions de requêtes, deux de mes "actions utilisateur" étaient en fait deux événements différents que j'avais mentalement effondrés, et l'exigence de l'interface utilisateur impliquait un composant en temps réel que je n'avais pas prévu dans le budget.

Cela représente environ deux jours de retouche que l'exploration a évités en quinze minutes.

Si je suis honnête, je n'ai presque jamais utilisé /opsx:explore pendant les trois premiers jours. C'était comme si c'était au-dessus de nos têtes. Ensuite, je l'ai essayé sur un refactor qui s'est avéré avoir une dépendance cachée sur une couche de cache obsolète, et je ne l'ai pas ignoré depuis. Le modèle que j'ai intériorisé : si je ne peux pas expliquer le changement en une phrase sans réserve, j'exécute d'abord explore.

Étape 2 : Proposer, Continuer ou Avancer rapidement

Une fois que l'exploration a dissipé le brouillard, j'exécute l'une des trois commandes en fonction de l'ampleur du changement :

• /openspec:propose pour les petits changements bien étendus où je veux que tout soit généré en un seul passage.
• /opsx:continue pour les changements plus importants, je souhaite les diviser en tranches verticales : proposition d'abord, puis spécifications, puis tâches, avec une porte de révision entre chacune.
• /opsx:ff lorsque l'exploration a été approfondie et que je souhaite que OpenSpec avance rapidement dans les étapes restantes de la proposition /spec/tasks sans m'obliger à cliquer sur chaque porte.

La sortie de chacun d'entre eux est la même : un dossier changes/[change-name]/ contenant proposal.md (le pourquoi et le quoi), design.md (le comment, y compris la conception du système), un ou plusieurs fichiers sous specs/ (les scénarios fonctionnels qui font office de contrat) et tasks.md (la répartition du travail que l'assistant exécutera).

C'est le moment du flux de travail où la spécification cesse d'être la mienne et devient celle de l'équipe. Même si l'équipe n'est que moi. La proposition est révisable dans un PR. Le design.md capture les décisions architecturales dans un langage que je peux comprendre dans le futur. Le dossier specs/ est la partie que l'assistant AI traitera comme le contrat lors de la mise en œuvre - et, surtout, c'est la partie qui survit au changement et fusionne dans la spécification principale lors de l'archive.

Une note sur ce qui différencie les spécifications OpenSpec. Chaque spécification décrit des scénarios fonctionnels – étant donné des récits de style /when/then qui décrivent le comportement. Pas les détails de mise en œuvre. Pas "le contrôleur appelle le référentiel". Comportement. C'est la forme qui survit aux modifications de la base de code. Lorsque je refactoriserai la couche de persistance dans six mois, la spécification est toujours correcte car elle n'a jamais porté sur le fonctionnement de la couche de persistance. Il s'agissait de ce que l'utilisateur voyait et pouvait faire.

Étape 3 : postuler (ou : comment j'ai arrêté de regarder la construction)

/openspec:apply est la commande qui crée la fonctionnalité. C'est là que se situe la majeure partie du temps d'exécution : environ deux heures de travail autonome sur la fonction de chronologie des activités, trois à quatre heures lorsque j'interromps pour clarifier les choses en cours de construction.

La chose que j'ai dû apprendre ici, c'est quand interrompre et quand partir. Mon premier instinct a été de surveiller la phase d'application comme je garde une session Claude Code : lire chaque différence, approuver chaque modification de fichier, remettre en question chaque décision. Cet instinct est faux avec OpenSpec. La spécification encodait déjà mes décisions. La phase de candidature consiste simplement à exécuter le contrat. Si j'ai envie d'interrompre pour « faire un choix différent », la bonne décision est presque toujours d'arrêter la candidature, de revenir à la proposition, de corriger les spécifications et de postuler à nouveau.

Une fois que j'ai intériorisé cela, j'ai commencé à laisser la phase d'application s'exécuter en arrière-plan pendant que je travaillais sur autre chose. Onglet ouvert, terminal visible, mais je ne le regarde pas. La première fois que j'ai fait ça, c'était inconfortable. La cinquième fois, c'était le schéma normal. La dixième fois, je me suis surpris à avoir livré deux fonctionnalités en parallèle en exécutant apply dans deux terminaux sur deux propositions différentes.

C'est le moment qui a changé mon modèle mental du AI coding. Le goulot d'étranglement a cessé d'être l'exécution. C’est devenu une qualité spécifique. Ce qui signifie que mon temps a commencé à être consacré à la partie du travail qui nécessite réellement un jugement humain, et le reste a été transféré à l'agent.

Étape 4 : Vérifier (la fonctionnalité qui tue sous-estimée)

/opsx:verify est la commande dont personne ne parle, et c'est celle qui a rendu OpenSpec irremplaçable dans le projet parallèle Next.js.

Le projet Next.js impliquait la migration d'un ancien système de conception vers un nouveau : mêmes composants, nouveaux jetons, nouvelle échelle d'espacement, nouvelle typographie. Il s’agit d’un travail cauchemardesque pour les outils de AI coding, car le code peut être techniquement correct et visuellement complètement faux. Un bouton peut rendre. Un bouton peut également s'afficher avec une mauvaise taille, dans une mauvaise police, avec un mauvais rayon de bordure et réussir tous les tests que vous avez écrits.

/opsx:verify est livré avec une intégration d'extension Chrome qui effectue des vérifications de fidélité visuelle par rapport aux spécifications. Il charge la page, capture l'état rendu et le compare à l'intention de conception codée dans la spécification. Lors de la migration du système de conception, sept régressions visuelles ont été détectées et la suite de tests a manqué. Incohérences d'espacement. Une mauvaise épaisseur de police sur une variante de titre. Un composant qui avait hérité d'une marge de l'ancien système et débordait de sa cellule de grille à certains points d'arrêt.

C'est la fonctionnalité qui n'existe dans aucun autre AI coding framework que j'ai testé. Spec Kit ne l'a pas. BMAD ne l'a pas. Obra Superpowers peut imposer que vous ayez écrit des tests, mais il ne peut pas vous dire que le test a réussi tant que la page ne semble pas correcte. Pour les travaux gourmands en interface utilisateur, en particulier les migrations de systèmes de conception, /opsx:verify fait la différence entre l'expédition et l'expédition correcte.

La mise en garde honnête : ce n’est pas magique. L'extension Chrome nécessite l'exécution de votre serveur de développement. Les contrôles visuels sont aussi bons que l'intention de conception que vous avez codée dans la spécification. Et il ne peut pas détecter les bugs d’interaction – seulement les problèmes de rendu statique. Mais pour la classe de bugs qu’il détecte, rien d’autre ne le fait.

Étape 5 : Archiver (l'astuce de la documentation vivante)

C’est l’étape que j’ai failli sauter la première semaine. C'est aussi l'étape qui est tranquillement la plus importante.

/openspec:archive prend la modification que vous venez d'expédier et fusionne ses deltas dans le dossier maître specs/. La proposition est déplacée vers un répertoire changes/archive/. La spécification principale – la source vivante de vérité – fusionne les nouvelles fonctionnalités, applique les modifications et supprime les suppressions.

Le résultat est qu'après chaque fonctionnalité livrée, votre dépôt contient une description actuelle, précise et lisible par machine du comportement de l'ensemble du système. Il ne s'agit pas d'un fichier README obsolète. Pas une page Confluence qui n'ait été touchée depuis dix-huit mois. L'état actuel réel.

J'ai testé ce que cela signifie six jours après avoir utilisé OpenSpec en demandant à Claude Code d'ajouter une nouvelle fonctionnalité au projet Laravel - sans lui donner de contexte. Je lui ai dit : "lisez openspec/specs/, puis proposez un changement qui ajoute X." Il a lu les spécifications. Il a proposé un changement qui identifiait correctement deux fonctionnalités existantes avec lesquelles il devrait interagir. Il l'a fait sans aucune demande de ma part concernant l'architecture de base du code, car l'architecture était déjà dans les spécifications.

C'est la première fois que je vois une "documentation vivante" comme un élément porteur d'un flux de travail de AI coding au lieu d'un élément agréable à avoir. Avec la plupart des projets, vous passez les cinq premières minutes de chaque session Claude Code à recharger le contexte. Avec OpenSpec, le contexte se charge tout seul.

Si jamais archive semble être une surcharge, je peux vous promettre que ce n'est pas le cas. Sauter les archives est la façon dont les projets spec-driven pourrissent. Toutes les équipes à qui j'ai parlé et qui ont abandonné le développement de spec-driven l'ont fait parce que leurs spécifications dérivaient de leur code. L'archive est la discipline qui empêche la dérive. Traitez-le comme faisant partie d'une « fonctionnalité terminée », et non comme une étape de nettoyage facultative.

Où OpenSpec échoue (la section honnête)

Je suis fan depuis deux semaines, mais un fan qui a mené cela dans trois projets aux formes très différentes. Voici où cela n'aide pas.

Petites modifications. Si la modification est « corriger cette faute de frappe » ou « renommer cette variable », le flux de travail OpenSpec est en surcharge. Ne lancez pas de proposition de correctif sur une seule ligne. Le framework ne prétend pas le contraire – Fission-AI le déconseille explicitement – ​​mais j'ai vu des nouveaux arrivants forcer chaque changement dans le flux de proposition et se retrouver avec un dossier changes/ qui ressemble à un cimetière de PR triviaux. Utilisez OpenSpec pour les choses qui méritent d'être réfléchies. Ignorez-le pour les choses qui ne le sont pas.

Séances de codage en solo où vous ne savez vraiment pas ce que vous voulez. Si vous êtes en mode exploration pure (esquisse, prototypage, lancement de code au mur), la phase de proposition vous ralentira. Le bon modèle ici est de commencer par vibe-code, puis une fois que vous savez ce que vous avez construit, écrivez la spécification rétroactivement et archive comme première proposition. OpenSpec convient à ce flux. Mais essayer de spécifier quelque chose que vous n'avez pas encore conçu est le pire des deux mondes.

La durée d'exécution de l'application de deux heures est réelle. La plupart des exécutions d'application se situent dans la plage de 90 à 180 minutes pour les fonctionnalités non triviales. Si vous avez besoin d'une fonctionnalité livrée en vingt minutes, OpenSpec n'est pas le bon outil. Ce n'est pas un défaut : la qualité des spécifications est ce qui rend la phase d'application fiable, et cette qualité prend du temps à encoder et à s'exécuter. Mais gérez vos attentes. OpenSpec est un outil permettant d'expédier correctement, et non d'expédier rapidement.

L'intégration de Brownfield présente des aspérités. Sur la base de code Python héritée, ma première tentative d'introduction de OpenSpec a abouti à une spécification principale qui était précise à environ 40 % par rapport au code réel. Le framework essayait de déduire des spécifications à partir d'un code qui n'avait aucun principe directeur, et les inférences étaient nécessairement floues. Le correctif exécutait /opsx:onboard correctement, prenant le temps d'écrire manuellement la spécification principale pour les flux principaux, puis puis d'utiliser OpenSpec pour les nouvelles modifications. Si vous vous attendez à déposer OpenSpec sur une base de code héritée et à lui faire comprendre la base de code d'ici vendredi, vous serez déçu. Planifiez une véritable semaine d’intégration.

La communauté est petite. Comparé à la présence GitHub de BMAD ou au soutien d'entreprise de Spec Kit, OpenSpec est le plus petit écosystème. Les documents sont bons. La cadence de sortie est saine. Mais il n’existe pas encore une multitude de didacticiels, de plugins ou d’intégrations tierces. Si vous avez besoin de quelque chose que le framework ne fait pas nativement, vous l'écrirez vous-même. Pour moi, c'est bien – je préfère avoir un petit outil ciblé plutôt qu'un gros outil gonflé – mais cela vaut la peine de le savoir.

Où OpenSpec s'intègre-t-il dans ma pile maintenant

Après deux semaines, OpenSpec se trouve tout en haut de mon flux de travail de AI coding – au-dessus de Claude Code, au-dessus des compétences d'agent que j'exécute, au-dessus des notes de planification que je conservais dans Obsidian. C'est la première chose que je touche lors d'un changement non trivial et la dernière chose que je touche lors de l'expédition.

La pile complète ressemble à ceci :

1. OpenSpec rédige et maintient les spécifications : le contrat pour ce qui est en cours de construction.
2. Claude Code avec Obra Superpowers exécute la spécification avec l'application TDD pendant la phase d'application.
3. Revue git standard détecte ce que TDD a manqué
4. Archive verrouille la modification dans la spécification dynamique, prête pour la prochaine itération

Chaque outil fait ce pour quoi il est le meilleur. OpenSpec n'essaie pas d'appliquer le TDD - c'est le travail des Superpowers. Superpowers n'essaie pas de gérer les spécifications - c'est le travail de OpenSpec. Claude Code n'essaie pas de se souvenir de tout ce qui a été construit — c'est le travail de la spécification principale.

Cette séparation des préoccupations est ce qui fait que la pile évolue réellement. Quand quelque chose se brise, je sais quelle couche déboguer. Lorsque je souhaite mettre à niveau une pièce, je peux l'échanger sans reconstruire les autres. La composabilité est la victoire.

Devriez-vous utiliser OpenSpec ?

Trois questions auxquelles répondre honnêtement :

Proposez-vous des fonctionnalités qui nécessitent plus de deux heures de travail ciblé ? Si oui, OpenSpec s'amortit grâce à la deuxième fonctionnalité. Si vous expédiez uniquement des micro-modifications, ignorez-les.

Revenez-vous déjà sur un projet après deux semaines et avez-vous besoin de recharger le contexte ? Si oui, la spécification vivante vous fera gagner des heures chaque mois. Si vos projets sont tous d’actualité et que votre mémoire est parfaite, la valeur est inférieure.

Faites-vous davantage confiance à votre assistant AI lorsqu'il a un contrat clair à exécuter ? Si oui, OpenSpec est la couche de contrat. Si vous préférez simplement discuter avec l'assistant et vous diriger tour à tour, le flux de la proposition ressemblera à une friction.

J'ai répondu oui aux trois, et OpenSpec a été l'ajout le plus important à mon flux de travail depuis que j'ai commencé à utiliser Claude Code. Non pas parce qu'il fait une chose considérablement mieux que les alternatives, mais parce qu'il rend tous les autres outils de ma pile plus fiables. La spécification est le point d’étranglement en amont. OpenSpec a rendu le point d'étranglement propre.

Questions fréquemment posées

À quoi sert OpenSpec ?

OpenSpec est un framework de développement spec-driven pour les assistants de AI coding. Vous écrivez une spécification de démarque d'une fonctionnalité et le framework se coordonne avec votre assistant AI (Claude Code, Cursor, Codex et plus de 20 autres) pour implémenter la spécification, valider le résultat et fusionner le changement dans une source vivante de vérité. Il est principalement utilisé pour les fonctionnalités de taille moyenne à grande dans les bases de code de friches industrielles où la qualité des spécifications a une valeur composée.

En quoi OpenSpec est-il différent du kit de spécifications GitHub ?

OpenSpec consolide les spécifications dans un seul document évolutif avec des modifications basées sur le delta, tandis que Spec Kit conserve des fichiers de spécifications séparés par fonctionnalité. OpenSpec produit des spécifications plus légères (environ 250 lignes contre 800 pour Spec Kit), prend en charge les bases de code brownfield de manière native et offre un flux de travail itératif avec la phase /opsx:explore. Le modèle en quatre phases plus lourd de Spec Kit s'adapte mieux au travail formel des entreprises inédites. Pour une analyse plus approfondie, voir « Qu'est-ce que OpenSpec » ci-dessus.

OpenSpec fonctionne-t-il avec Claude Code ?

Oui — Claude Code est l'un des 20+ assistants de AI coding pris en charge. Pendant openspec init, vous sélectionnez Claude Code comme assistant et OpenSpec écrit les liaisons de commande slash correspondantes dans votre projet. Cursor, Codex, Windsurf, Continue, GitHub Copilot, Amazon Q, Gemini CLI et autres sont également entièrement pris en charge.

Combien de temps dure une exécution d'application OpenSpec ?

Une exécution typique de openspec apply atterrit dans la plage de 90 à 180 minutes pour les fonctionnalités non triviales lorsqu'elle est exécutée de manière autonome. L'ajout de points de contrôle humains et de clarifications à mi-construction étend ce délai à 3 à 4 heures d'horloge murale. La plupart du temps, l'assistant AI travaille, sans attendre : vous pouvez le laisser fonctionner en arrière-plan pendant que vous travaillez sur autre chose.

OpenSpec peut-il remplacer les superpouvoirs BMAD ou Obra ?

Non, et vous ne devriez pas essayer d'y arriver. OpenSpec est un framework spec-driven. BMAD est un orchestrateur de pipeline autonome. Obra Superpowers est une couche d'application SDLC. Ils résolvent différents problèmes et s'empilent bien : OpenSpec écrit la spécification, Superpowers applique TDD pendant la construction, BMAD orchestre les pipelines multi-fonctionnalités. Pour une répartition complète de ces trois catégories, consultez le tableau comparatif en haut de cet article.

Travaillons ensemble

Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.

• Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
• Portefeuille : mejba.me
• Ramlit Limited (solutions d'entreprise) : ramlit.com
• ColorPark (conception et image de marque) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io