Développement piloté par les spécifications avec Claude Code et Cursor

Claude Code est un outil de codage agentique qui lit une base de code, modifie des fichiers et exécute des commandes. Cursor est l’éditeur dont les règles de projet se trouvent dans .cursor/rules sous forme de fichiers .mdc. Le développement piloté par les spécifications (SDD) est la pratique d’écrire la spécification avant le code et de traiter la spécification comme la source de vérité. Un document d’exigences produit (PRD) est la prose qui énonce le problème et le périmètre avant que le travail soit découpé en tâches. Dans SpecScore, une spécification de fonctionnalité est le fichier d’une capacité du produit, une exigence (REQ) est une règle nommée dans cette fonctionnalité, et un critère d’acceptation (AC) est une condition abstraite facultative qui pointe vers une ou plusieurs de ces règles. L’intégration continue (CI) est un contrôle automatique à chaque changement proposé. Le contrôle est une commande de l’interface en ligne de commande (CLI), specscore spec lint, de la CLI dans specscore/specscore-cli. Sur cette page, les spécifications Cursor sont ce fichier de fonctionnalité avec la règle de projet Cursor qui dit à l’agent de le linter.

Dernière mise à jour : 6 novembre 2026

Ce qui va dans la fonctionnalité, et ce qui va dans le fichier de l’agent

Le fichier de fonctionnalité porte l’obligation. Un README de fonctionnalité sous spec/features/ porte les règles #### REQ: et les critères ### AC:. La forme remplie, le plan et la tâche sont le modèle de PRD en Markdown. specscore spec lint vérifie cette forme : titres, sections obligatoires, lignes d’index et références. Il ne décide pas si l’idée de produit est bonne. Linter des spécifications en CI est l’explication plus longue de la commande.

Le fichier de l’agent contient les instructions pour un outil. L’aperçu d’Anthropic dit que CLAUDE.md est un fichier Markdown à la racine du projet que Claude Code lit au début de chaque session. La documentation Rules de Cursor dit qu’une règle de projet est un fichier .mdc dans .cursor/rules, et qu’un fichier .md simple dans ce répertoire est ignoré parce qu’il n’a pas de frontmatter. Ces fichiers disent à l’agent comment travailler dans le dépôt. Ce ne sont pas la spécification que le linter vérifie. Une exigence qui n’existe que dans CLAUDE.md ou seulement dans .cursor/rules/specscore.mdc est invisible pour specscore spec lint.

Ce qu’écrit specscore agent setup

Le README de la CLI dit que specscore agent setup écrit le fichier d’instructions de chaque agent et, là où cet agent a un répertoire de skills, y copie les lots de skills SpecScore. La commande ignore un fichier existant, sauf si vous passez --force. Le contrat est la fonctionnalité agent-setup dans specscore/specscore-cli.

Ce contrat associe l’id caller claude à CLAUDE.md et .claude/skills/, et l’id caller cursor à .cursor/rules/specscore.mdc et .cursor/skills/. Exécutez la commande dans un projet qui a déjà specscore.yaml. Si ce fichier manque, la commande se termine avec le code 6 et le message suggère specscore init. Une invocation qui nomme les deux agents est specscore agent setup claude,cursor. La fonctionnalité dit qu’une liste séparée par des virgules équivaut à des arguments séparés. Les répertoires parents sont créés. Chaque chemin est signalé comme ajouté, modifié ou ignoré.

Le CLAUDE.md généré comprend le titre du projet, des exemples de CLI qui passent --caller claude, et la ligne d’installation /plugin install specscore@specscore. Le fichier Cursor est du Markdown avec un frontmatter YAML. Le frontmatter contient description et alwaysApply: true. Le tableau des règles de Cursor dit que alwaysApply: true signifie que la règle est incluse dans chaque chat. --no-skills écrit les fichiers d’instructions et ne copie pas les lots de skills. La même table du contrat nomme aussi codex, copilot, antigravity.google, pi.dev, opencode et deepseek. Cette page suit les deux agents du titre.

Écrit les fichiers de Claude Code et de Cursor. Exécutez-le depuis un projet qui a specscore.yaml.

specscore agent setup claude,cursor

Chemins que le contrat assigne à claude et à cursor. Les répertoires de skills ne sont pas créés lorsque vous passez --no-skills. Un fichier existant reste tel quel, sauf si vous passez --force.

CLAUDE.md
.claude/skills/
.cursor/rules/specscore.mdc
.cursor/skills/

Le fichier d’instructions pointe vers l’arbre de fonctionnalités. Il ne le remplace pas. Après la configuration, Claude Code doit encore lire spec/features/, et la règle de Cursor doit encore pointer vers le même arbre. La spécification de fonctionnalité reste le document que specscore spec lint accepte ou refuse.

Exécutez specscore spec lint dans la boucle

Installez d’abord la CLI. Les méthodes d’installation sont sur la page d’installation. Ensuite, gardez la fonctionnalité et le linter dans la même boucle que l’agent.

Écrivez la fonctionnalité avant le prompt

Ajoutez le README de la fonctionnalité, la ligne de l’index des fonctionnalités et specscore.yaml avec le modèle de PRD. Placez chaque obligation sous ## Behavior comme #### REQ: {slug}. Faites pointer les critères d’acceptation vers ces ids avec **Requirements:**. Laissez CLAUDE.md et .cursor/rules/ pour l’étape suivante.

Lintez avant que l’agent ne modifie le code

Exécutez specscore spec lint dans le dépôt. Un arbre propre affiche 0 violations found et se termine avec 0. Le rapport d’échec — fichier, ligne, sévérité, règle, message — est dans linter des spécifications en CI. Corrigez la fonctionnalité jusqu’à ce que cette commande soit propre. Un agent qui part d’une fonctionnalité que le linter refuse déjà copiera la forme cassée.

Pointez Claude Code et Cursor vers l’arbre

Exécutez specscore agent setup claude,cursor. Lisez CLAUDE.md et .cursor/rules/specscore.mdc, une fois ajoutés, et confirmez qu’ils nomment l’arbre de spécification et la CLI, y compris --caller. Si l’un ou l’autre fichier existait déjà, la commande l’ignore. Passez --force seulement lorsque vous voulez remplacer ce fichier.

Demandez une tâche qui nomme un critère

Dans la session de l’agent, nommez la fonctionnalité et le critère d’acceptation que le travail doit satisfaire. Une tâche de plan le fait avec **Verifies:** et un id de critère d’acceptation. Demandez à l’agent d’exécuter specscore spec lint à nouveau avant de terminer, et de modifier le fichier de fonctionnalité quand le comportement change. Le fichier d’instructions dit à l’agent d’exécuter la commande. Le fichier de fonctionnalité est ce que la commande vérifie.

Skills qui exposent lint, feature et task

Les lignes d’installation du README de la CLI pour le plugin enveloppant sont /plugin marketplace add specscore/ai-marketplace et /plugin install specscore@specscore. Le dépôt du plugin est specscore/ai-plugin-specscore, sous la licence MIT. Son README des skills dit que les utilisateurs invoquent /specscore:<skill-name>. Les enveloppes livrées comprennent /specscore:spec, qui enveloppe specscore spec lint ; /specscore:feature, qui enveloppe specscore feature (list, info, tree, deps, refs, new et change-status) ; et /specscore:task, qui enveloppe specscore task. /specscore:change-status couvre les changements de statut de fonctionnalité et d’idée. La page CLI Skills de ce site est cette enveloppe. specscore agent setup copie ces lots de skills dans .claude/skills/ et .cursor/skills/, sauf si vous passez --no-skills.

Le README du plugin dit que Cursor n’a pas de commande d’installation à distance et charge les skills depuis .cursor/skills/ dans le projet ou depuis ~/.cursor/skills/. La copie manuelle qu’il montre est git clone de ai-plugin-specscore et cp -R de skills/* vers .cursor/skills/. specscore agent setup cursor est la commande qui fait cette copie pour vous, depuis le marketplace que nomme la spécification de fonctionnalité.

SpecStudio Skills est le flux guidé. Le dépôt est specscore/specstudio-skills, sous la licence MIT. La ligne d’installation Claude Code de son README est /plugin install specstudio@specscore, et il dit que Claude Code installe le plugin specscore comme dépendance. La section de statut nomme la version 0.0.7 et dit que les skills ideate, specify, plan, implement, verify et recap sont assez actifs pour servir sur leur propre projet (dogfood). Le tableau d’inventaire du même README documente specstudio:ideate et specstudio:specify en détail. Ces skills écrivent des artefacts SpecScore. Ils ne remplacent pas specscore spec lint.

La même commande en CI

dogfood.yml dans specscore/specscore règle SPECSCORE_VERSION sur v0.39.1 et exécute specscore spec lint sur les pull requests et sur les push vers main. L’extrait du workflow et le rapport texte sont dans linter des spécifications en CI. Une fonctionnalité qui casse un titre fait échouer ce job, que Claude Code ou Cursor ait écrit le fichier. La boucle de l’agent et la CI appellent la même commande.

La licence du format est CC BY 4.0 dans specscore/specscore. La licence de la CLI est Apache-2.0 dans specscore/specscore-cli.

D’autres outils pilotés par les spécifications publient des contrôles différents. Les phrases ci-dessous n’utilisent que ce que disent les pages de ces projets. La revue des outils enregistre les mêmes pages comme lues le 30 octobre 2026, sauf la page d’accueil de la documentation de Spec Kit, qui imprime le 28 septembre 2026.

OpenSpec documente openspec validate dans sa référence de la CLI. Cette commande vérifie la structure des changements et des spécifications d’OpenSpec. Elle ne vérifie pas un titre ### AC: de SpecScore.

Le README de Task Master décrit le découpage d’un PRD en tâches avec task-master parse-prd. Il ne décrit pas un linter pour ce PRD.

GitHub Spec Kit décrit un flux d’agent dont les phases écrivent des artefacts Markdown. Cette page d’accueil de documentation ne décrit pas une commande qui linte un README de fonctionnalité SpecScore en CI.

Questions fréquentes

Qu’est-ce que Claude Code spec-driven development ?

C’est écrire la fonctionnalité SpecScore avant que Claude Code n’écrive le code, puis garder CLAUDE.md comme fichier d’instructions qui pointe vers cette fonctionnalité. La fonctionnalité contient les exigences (REQ) et les critères d’acceptation (AC). specscore spec lint vérifie la fonctionnalité. specscore agent setup claude écrit CLAUDE.md dans un projet qui a déjà specscore.yaml.

Où vont les spécifications Cursor ?

L’obligation du produit va dans le README de la fonctionnalité sous spec/features/. La règle de projet Cursor va dans .cursor/rules/specscore.mdc. Les fichiers de skills vont dans .cursor/skills/. specscore agent setup cursor écrit la règle et, sauf si vous passez --no-skills, copie les lots de skills. La documentation propre de Cursor est la source de la façon dont les règles .mdc sont appliquées.

CLAUDE.md remplace-t-il la spécification de fonctionnalité ?

Non. CLAUDE.md est ce que Claude Code lit comme instructions. Le README de la fonctionnalité est ce que specscore spec lint vérifie. La fonctionnalité agent-setup dit que le fichier généré enseigne à l’agent l’arbre de spécification et les commandes de la CLI. Elle ne dit pas que le fichier d’instructions est la spécification.

Que se passe-t-il si CLAUDE.md ou la règle Cursor existe déjà ?

La commande ignore le fichier existant et affiche une ligne d’omission qui mentionne --force. Les octets existants restent. Passez --force seulement lorsque le remplacement est ce que vous voulez. La même règle d’omission s’applique à un fichier de skill déjà présent.

Quel skill exécute le linter ?

Dans le README des skills du plugin, /specscore:spec enveloppe specscore spec lint. Vous pouvez aussi exécuter cette commande de CLI vous-même, dans la session de l’agent ou en CI. /specscore:feature et /specscore:task enveloppent les commandes de fonctionnalité et de tâche. Ils ne lintent pas tout seuls.

Le linter note-t-il la prose ?

Non. specscore spec lint vérifie la structure. Linter des spécifications en CI montre le rapport. Un contrôle structurel propre n’est pas une revue de produit.

Sources

Le comportement d’agent-setup est le contrat dans specscore-cli spec/features/cli/agent/setup/README.md sur main, lu le 6 novembre 2026. Les noms des skills viennent de ai-plugin-specscore skills/README.md sur main, lu le même jour. La ligne d’installation de SpecStudio et la liste de statut de la version 0.0.7 viennent de specstudio-skills README.md sur main, lu le même jour. La description de Claude Code et la phrase sur CLAUDE.md viennent de code.claude.com/docs/en/overview. Les chemins des règles de projet de Cursor viennent de cursor.com/docs/rules. dogfood.yml dans ce dépôt fixe SPECSCORE_VERSION à v0.39.1. Les pages concurrentes sont celles liées ci-dessous ; la revue des outils les enregistre comme lues le 30 octobre 2026, sauf la page d’accueil de la documentation de Spec Kit, qui imprime le 28 septembre 2026.