# Modèle de PRD en Markdown pour coder avec l’IA Canonical: https://specscore.md/fr/articles/feature-spec-template/ Dernière mise à jour : 5 novembre 2026 Un document d’exigences produit (PRD, product requirements document) est la prose qui énonce le problème et le périmètre avant que le travail soit découpé en tâches. Une [spécification de fonctionnalité](https://specscore.md/feature-specification) est le fichier de SpecScore pour une capacité du produit : ce qu’elle fait, pourquoi elle existe et comment elle se comporte. Markdown est le format en texte brut de ce fichier. Le [développement piloté par les spécifications](https://specscore.md/fr/spec-driven-development/) (SDD, spec-driven development) est la pratique d’écrire la spécification avant le code et de traiter la spécification comme la source de vérité. Dans [SpecScore](https://specscore.md/), une exigence (REQ) est une règle nommée dans une fonctionnalité. Un [critère d’acceptation](https://specscore.md/acceptance-criteria-specification) (AC, acceptance criterion) est une condition abstraite facultative qui pointe vers une ou plusieurs de ces règles. Un scénario est un exemple concret, écrit en étapes Given, When et Then. Un [plan](https://specscore.md/plan-specification) est le document qui découpe la fonctionnalité en tâches. Une [tâche](https://specscore.md/task-specification) est une unité de travail qu’une personne ou un agent peut terminer. L’[intégration continue](https://specscore.md/fr/validators/) (CI, continuous integration) est un contrôle automatique à chaque changement proposé. Le contrôle est une commande de l’[interface en ligne de commande](https://specscore.md/fr/cli/) (CLI, command-line interface), `specscore spec lint`, de la CLI dans [specscore/specscore-cli](https://github.com/specscore/specscore-cli). [Easy Approach to Requirements Syntax](https://specscore.md/fr/articles/ears-requirements/) (EARS) est un patron de phrase qu’une exigence peut utiliser. Claude Code est l’agent de codage par IA pour lequel le plugin [CLI Skills](https://specscore.md/fr/ai/cli-skills/) de ce site est écrit. Ce modèle de spécification de fonctionnalité est ce fichier de fonctionnalité, plus le plan et la tâche qui pointent vers lui. ## Ce qu’est ce modèle de spécification de fonctionnalité Un PRD est souvent un fichier de prose qu’une personne lit. SpecScore garde le même mandat dans des fichiers qu’un linter peut vérifier. La [spécification de fonctionnalité](https://specscore.md/feature-specification) appelle fonctionnalité l’unité atomique de la spécification de produit : un répertoire sous `spec/features/` dont le `README.md` est la seule source de vérité de ce que fait la fonctionnalité. La [spécification de plan](https://specscore.md/plan-specification) appelle plan le document qui décompose cette fonctionnalité en tâches. Un scénario, dans la [spécification de scénario](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md), est un fichier concret Given/When/Then dans le répertoire `_tests/` de la fonctionnalité. La [spécification des critères d’acceptation](https://specscore.md/acceptance-criteria-specification) garde le critère abstrait : il dit ce qui doit être vrai, et le scénario dit comment le prouver. Le fichier checkout ci-dessous est le modèle rempli. Avec l’index des fonctionnalités, un README de spécification et `specscore.yaml`, `specscore spec lint` l’a accepté avec 0 violation. Ce contrôle a été exécuté le 2 novembre 2026 avec specscore 0.55.1 et avec 0.39.1, l’étiquette que [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) installe. La ligne de la barre d’outils Studio dans le fichier de fonctionnalité est la ligne que portent les README de fonctionnalité dans [specscore/specscore](https://github.com/specscore/specscore). La table des sections obligatoires de la spécification de fonctionnalité ne la liste pas. ## Le README de la fonctionnalité La table des sections obligatoires de la spécification de fonctionnalité dit que chaque README de fonctionnalité a un titre `# Feature: {Title}`, une ligne `**Status:**` juste après le titre, un Summary, un Problem, une section Behavior, une section Acceptance Criteria, une section Open Questions et un pied d’adhésion. La valeur de statut est l’une de `Draft`, `In Review`, `Approved`, `Implementing`, `Stable`, `Amending`, `Rejected` ou `Deprecated`. Une section Contents n’est obligatoire que lorsque la fonctionnalité a des répertoires enfants. `**Source Ideas:**` est facultatif. Le fichier vérifié le règle sur `—`. Open Questions n’est jamais omis. Lorsqu’il n’y en a aucune, la section dit `None at this time.` Acceptance Criteria n’est jamais omis non plus. Lorsqu’aucun critère n’est défini, cette section dit `Not defined yet.` et Open Questions doit alors inclure `Acceptance criteria not yet defined for this feature.` Le pied est la dernière ligne, et son URL est `https://specscore.md/feature-specification`. La [convention de frontmatter des artefacts](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md) dit que chaque artefact porte une clé `format:` dans le frontmatter YAML, et qu’un artefact porteur d’un statut porte aussi `status:`, en miroir du jeton `**Status:**` du corps. La même fonctionnalité dit que les règles de lint qui l’imposent sortent après une période de grâce. Le fichier vérifié inclut les deux clés. Cette page n’affirme pas que l’épingle v0.39.1 rejette un fichier qui les omet. ### README de fonctionnalité que specscore spec lint a accepté (2 novembre 2026) ```markdown --- format: https://specscore.md/feature-specification status: Draft --- # Feature: Checkout validation > [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) | **Status:** Draft **Source Ideas:** — ## Summary The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. ## Problem A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them. ## Behavior ### Field validation The checkout system checks the form when the shopper submits it. #### REQ: show-field-error When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field. #### REQ: reject-invalid-email If the submitted email is not a valid address, then the checkout system MUST reject the form. ## Acceptance Criteria ### AC: invalid-submission **Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected. ## Open Questions None at this time. --- *This document follows the https://specscore.md/feature-specification* ``` ### Index des fonctionnalités du même passage de lint ```markdown --- format: https://specscore.md/features-index-specification --- # Features | Feature | Status | Description | |---|---|---| | [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. | ## Open Questions None at this time. --- *This document follows the https://specscore.md/features-index-specification* ``` ### README de spécification du même passage de lint ```markdown # Checkout specification ## Open Questions None at this time. ``` ### specscore.yaml du même passage de lint ```yaml # SpecScore Repo Config Schema: https://specscore.md/repo-config project: title: Checkout sample host: github.com org: example repo: checkout ``` L’identifiant de la fonctionnalité est le chemin de son répertoire relatif à `spec/features/`. Le lien d’index `checkout/README.md` signifie que le fichier se trouve à `spec/features/checkout/README.md`, donc l’id de fonctionnalité qu’utilisent les exigences et les critères est `checkout`. L’index liste chaque fonctionnalité de premier niveau. Un répertoire enfant qui n’est pas listé est une violation de `index-entries`, que décrit [linter des spécifications en CI](https://specscore.md/fr/articles/lint-specs-in-ci/). Le README de spécification de cet arbre a une section, Open Questions, et elle dit `None at this time.` Le fichier de configuration est ce que la CLI cherche en remontant. Sans `specscore.yaml` la commande se termine avec 3 et nomme `specscore init`. ## Identifiants REQ, critères d’acceptation et scénarios La [spécification d’exigence](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) place chaque règle sous un titre de sujet à l’intérieur de `## Behavior`. Le titre est `#### REQ: {slug}`, avec un espace après les deux-points. Le slug utilise des lettres minuscules, des chiffres et des traits d’union. L’id canonique est `{feature-path}#req:{slug}`. Dans le fichier checkout, c’est `checkout#req:show-field-error` et `checkout#req:reject-invalid-email`. Une exigence énonce une seule obligation. La spécification dit que les exigences SHOULD utiliser les mots-clés du RFC 2119 : MUST, MUST NOT, SHOULD, SHOULD NOT et MAY. Un titre `REQ:` n’est pas valide en dehors de `## Behavior`. Une phrase EARS peut être cette prose. Le linter ne note pas l’anglais. Les patrons sont dans [la syntaxe des exigences EARS](https://specscore.md/fr/articles/ears-requirements/). ### Critère d’acceptation La [spécification des critères d’acceptation](https://specscore.md/acceptance-criteria-specification) dit que chaque critère est un titre `### AC: {slug}` à l’intérieur de `## Acceptance Criteria`, puis une ligne `**Requirements:**` qui liste des valeurs `{feature-id}#req:{slug}`, puis un énoncé abstrait de ce qui doit être vrai. Les critères sont facultatifs. La spécification dit d’en ajouter un lorsque regrouper deux exigences liées ou plus apporte de la clarté. Le fichier checkout regroupe les deux règles dans `checkout#ac:invalid-submission`. L’énoncé ne contient ni Given, ni When, ni Then. [Comment écrire des critères d’acceptation](https://specscore.md/fr/articles/acceptance-criteria/) est le guide de rédaction. La règle `ac-heading-format` ([ac_heading.go](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/ac_heading.go) à l’étiquette v0.55.1 de la CLI) vérifie que le titre est `### AC: ` avec un id en kebab-case. L’[article sur le lint](https://specscore.md/fr/articles/lint-specs-in-ci/) enregistre que cette règle n’exige pas la ligne `**Requirements:**` et ne note pas les mots. La spécification des critères d’acceptation exige toujours cette ligne. ### Scénario La [spécification de scénario](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) place un scénario dans `_tests/`, qui n’est pas une sous-fonctionnalité et qui est exclu de l’index des fonctionnalités. Le fichier commence par `# Scenario: {Title}`, une ligne `**Validates:**` qui pointe vers une exigence ou un critère, et une section `## Steps` dont les mots-clés sont en capitales : GIVEN, WHEN, THEN et AND. Chaque répertoire `_tests/` doit contenir un README avec un index de scénarios. L’échantillon ci-dessous a cette forme de fichier. Il ne faisait pas partie du passage de lint du 2 novembre. `specscore spec lint` ne vérifie pas les mots-clés des étapes de scénario. `specscore rehearse` exécute les fichiers de scénario. [Rehearse](https://specscore.md/rehearse) est cet exécuteur. Le workflow dogfood exécute le linter et n’appelle pas rehearse. ### Forme de fichier de scénario selon la spécification de scénario ```markdown # Scenario: Reject an invalid email **Validates:** [checkout#ac:invalid-email-rejected](../README.md#ac-invalid-email-rejected) ## Steps GIVEN the shopper is on the checkout form WHEN the shopper submits the email "not-an-email" THEN the page shows "Enter a valid email address" beside the email field AND the order is not placed ``` Lisez les trois couches dans l’ordre. L’exigence dit la règle. Le critère d’acceptation dit ce qui doit être vrai pour les règles qu’il nomme. Le scénario donne un flux concret. Un agent qui ne voit que la prose du PRD doit inventer cette découpe. Le modèle l’a déjà. ## Plans et tâches Un README de plan se trouve à `spec/plans/{plan-slug}/README.md`. La [spécification de plan](https://specscore.md/plan-specification) exige le titre `# Plan: {Title}` et les champs d’en-tête Status, exactement une ligne de source, Date, Owner et Supersedes. Un plan dont la source est une fonctionnalité utilise `**Source Feature:**` plus le slug de la fonctionnalité, ici `checkout`. Les autres lignes de source admises sont `**Source:** idea:{slug}` et `**Source:** none`. Les sections obligatoires sont Summary, Approach, Tasks et Open Questions. Dans le plan, chaque tâche est un titre `### Task N:` avec une ligne `**Verifies:**` de la forme `feature-slug#ac:ac-slug`. La règle `P-001` dans [plan_rules.go](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/plan_rules.go) signale un titre de critère d’acceptation qu’aucune tâche ne couvre et qui n’est pas listé sous `## Deferred AC Coverage`. La règle `P-002` signale une valeur `**Verifies:**` qui ne se résout pas en l’un de ces titres. Les plans dont la source est une idée et les plans avec `**Source:** none` sont exemptés de `P-001`. Le plan ci-dessous suit cette forme publiée pour la fonctionnalité checkout, y compris le frontmatter `format:` et `status:`. Il n’était pas dans le passage de lint du 2 novembre. Une fonctionnalité qu’un plan touche doit inclure une table `## Plans` avec les colonnes Plan, Status, Author et Approved. Le fichier de fonctionnalité vérifié n’a pas de section Plans, parce que cet arbre n’a pas de plan. La [spécification de tâche](https://specscore.md/task-specification) définit aussi une tâche comme son propre répertoire et `README.md` sous le plan. Le titre est `# Task: {Title}`. Les champs obligatoires sont `**Status:**`, `**Depends on:**` (le littéral `none` lorsqu’il n’y a pas de dépendance) et `**Model:**` (`small`, `medium`, `large` ou `inherit`). Un répertoire qui contient des répertoires de tâches enfants est un plan, pas une tâche. Le fichier de tâche ci-dessous utilise ces champs pour la première tâche de checkout. Il n’était pas dans le passage de lint du 2 novembre. L’URL de pied d’un document de tâche est `https://specscore.md/task-specification`. ### Forme de plan de la spécification de plan, remplie pour checkout ```markdown --- format: https://specscore.md/plan-specification status: Draft --- # Plan: Show checkout validation errors **Status:** Draft **Source Feature:** checkout **Date:** 2026-11-05 **Owner:** @example **Supersedes:** — ## Summary This plan decomposes the checkout feature into the work that shows a field error and rejects an email that is not a valid address. ## Approach Both tasks verify the same acceptance criterion, which bundles the two requirements. Nothing is deferred, so this plan has no Deferred AC Coverage section. ## Tasks ### Task 1: Show a validation error beside the invalid field **Verifies:** checkout#ac:invalid-submission When the shopper submits the checkout form with invalid data, show a validation error next to the invalid field. ### Task 2: Reject an email that is not a valid address **Verifies:** checkout#ac:invalid-submission If the submitted email is not a valid address, reject the form. ## Open Questions None at this time. --- *This document follows the https://specscore.md/plan-specification* ``` ### Forme de document de tâche selon la spécification de tâche ```markdown --- format: https://specscore.md/task-specification status: queued --- # Task: Show a validation error beside the invalid field **Status:** queued **Depends on:** none **Model:** medium ## Acceptance Criteria - Submitting the checkout form with invalid data shows a validation error next to the invalid field. ## Open Questions None at this time. --- *This document follows the https://specscore.md/task-specification* ``` Le fichier de fonctionnalité répond à ce que le formulaire de checkout doit faire. Le plan répond à la façon dont ce travail est découpé, et chaque tâche en ligne nomme le critère qu’elle vérifie. Le document de tâche est la feuille qu’une personne ou un agent prend. Gardez l’id du critère stable. `checkout#ac:invalid-submission` est la chaîne qu’utilisent la fonctionnalité et le plan. ## Linter le modèle en CI `specscore spec lint` valide l’arbre de spécification pour des violations de convention structurelle. Une exécution propre affiche `0 violations found` et se termine avec 0. Une exécution qui trouve des violations affiche une ligne par constat et se termine avec 1. Ce code de sortie fait échouer un job de CI. Des arguments invalides se terminent avec 2. Un `specscore.yaml` absent se termine avec 3. [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) installe la CLI avec `SPECSCORE_VERSION` réglé sur `v0.39.1`, puis exécute `specscore spec lint` sur les pull requests et sur les push vers main. L’extrait du workflow, le rapport d’échec et le catalogue de règles sont dans [linter des spécifications en CI](https://specscore.md/fr/articles/lint-specs-in-ci/). La licence du format est [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) dans [specscore/specscore](https://github.com/specscore/specscore). La licence de la CLI est [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) dans [specscore/specscore-cli](https://github.com/specscore/specscore-cli). D’autres outils de développement piloté 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](https://specscore.md/fr/spec-driven-development/tools/) 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](https://github.com/Fission-AI/OpenSpec) documente `openspec validate` dans sa [référence de CLI](https://openspec.dev/docs/cli). Cette commande vérifie la structure des changements et des spécifications d’OpenSpec et se termine avec un code différent de zéro lorsque la validation échoue. Elle ne vérifie pas un titre `### AC:` de SpecScore ni un index SpecScore. Le README de [Task Master](https://github.com/eyaltoledano/claude-task-master) décrit le découpage d’un PRD en tâches avec `task-master parse-prd`. Il ne décrit pas de linter pour ce PRD. Un PRD peut rester le texte que vous réécrivez dans le fichier de fonctionnalité de cette page. `specscore spec lint` est ce qui vérifie ensuite le fichier de fonctionnalité. [GitHub Spec Kit](https://github.github.io/spec-kit/) décrit un flux d’agent dont les phases écrivent des artefacts Markdown. Cette page d’accueil de la documentation ne décrit pas une commande qui linte un README de fonctionnalité SpecScore en CI. La comparaison de ces outils est la [revue des outils](https://specscore.md/fr/spec-driven-development/tools/). ## Un modèle de spécification que Claude Code peut lire Les fichiers sont en Markdown, donc un agent qui peut lire un dépôt peut lire le modèle. Claude Code est l’agent que vise la page [CLI Skills](https://specscore.md/fr/ai/cli-skills/). Cette page documente `ai-plugin-specscore`, un plugin léger de Claude Code qui enveloppe la CLI. Le dépôt du plugin est [specscore/ai-plugin-specscore](https://github.com/specscore/ai-plugin-specscore). La page dit que le plugin expose `specscore spec lint`, `specscore feature`, `specscore task` et `specscore feature change-status` comme commandes du plugin. Les lignes d’installation de cette page sont `/plugin marketplace add specscore/ai-marketplace` et `/plugin install cli-skills@specscore`. La même page documente `specscore agent setup ` pour `claude`, `copilot`, `cursor`, `codex`, `antigravity.google`, `pi.dev` ou `opencode`, exécuté dans un projet géré par SpecScore. [SpecStudio Skills](https://specscore.md/fr/ai/specstudio-skills/) est le flux guidé (`/ideate`, `/specify`, `/plan`, `/implement`) et c’est aussi un plugin Claude Code. Le modèle de cette page est le fichier que ces commandes lintent. Le plugin ne remplace pas le README de la fonctionnalité. ## Questions fréquentes ### Qu’est-ce qu’un modèle de PRD en Markdown ? C’est un document d’exigences produit écrit comme des fichiers Markdown à forme fixe. Dans SpecScore, cette forme est un README de fonctionnalité : titre, statut, résumé, problème, comportement avec des règles `#### REQ:`, critères d’acceptation et questions ouvertes. Le fichier checkout de cette page est un fichier que `specscore spec lint` a accepté. ### Où vont les identifiants REQ dans un modèle de spécification de fonctionnalité ? Sous un titre de sujet à l’intérieur de `## Behavior`, comme `#### REQ: {slug}`. L’id est `{feature-path}#req:{slug}`. Les critères d’acceptation listent ces ids sur `**Requirements:**`. Une tâche du plan liste l’id du critère sur `**Verifies:**`. ### Quelle est la différence entre un critère d’acceptation et un scénario ? Un critère d’acceptation est une condition abstraite. Un scénario est un flux concret Given/When/Then dans `_tests/`. La [spécification des critères d’acceptation](https://specscore.md/acceptance-criteria-specification) dit que le critère ne doit pas prescrire les étapes. Le fichier de scénario le fait. ### Le linter note-t-il la prose du PRD ? Non. `specscore spec lint` vérifie la structure : les titres, les sections obligatoires, les lignes d’index et les références telles que `P-001` et `P-002`. Il ne décide pas si le produit est une bonne idée. [Linter des spécifications en CI](https://specscore.md/fr/articles/lint-specs-in-ci/) est le récit plus long de cette commande. ### Claude Code peut-il utiliser ce modèle de spécification ? Oui. Le modèle est du Markdown dans le dépôt. Le plugin [CLI Skills](https://specscore.md/fr/ai/cli-skills/) expose `specscore spec lint` et les commandes de fonctionnalité et de tâche dans Claude Code. `specscore agent setup claude` écrit un fichier d’instructions pour cet agent. Le plugin n’invente pas un autre modèle. ### Un plan remplace-t-il la spécification de fonctionnalité ? Non. Le README de la fonctionnalité est la source des exigences et des critères d’acceptation. Le plan décompose cette fonctionnalité en tâches, et chaque tâche renvoie avec `**Verifies:**`. La [spécification de plan](https://specscore.md/plan-specification) et la [spécification de tâche](https://specscore.md/task-specification) sont les deux documents de cette découpe. ## Sources La fonctionnalité checkout, l’index des fonctionnalités, le README de spécification et specscore.yaml ont été acceptés par specscore spec lint le 2 novembre 2026 avec specscore 0.55.1 et avec 0.39.1. Les échantillons de plan et de tâche suivent les spécifications publiées et ne faisaient pas partie de cette exécution. 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. - [Spécification de fonctionnalité](https://specscore.md/feature-specification) - [specscore/specscore — spécification de fonctionnalité](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md) - [specscore/specscore — spécification d’exigence](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [Spécification des critères d’acceptation](https://specscore.md/acceptance-criteria-specification) - [specscore/specscore — spécification des critères d’acceptation](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — spécification de scénario](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [Spécification de plan](https://specscore.md/plan-specification) - [specscore/specscore — spécification de plan](https://github.com/specscore/specscore/blob/main/spec/features/plan/README.md) - [Spécification de tâche](https://specscore.md/task-specification) - [specscore/specscore — spécification de tâche](https://github.com/specscore/specscore/blob/main/spec/features/task/README.md) - [specscore/specscore — convention de frontmatter des artefacts](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md) - [specscore/specscore](https://github.com/specscore/specscore) - [specscore/specscore — licence CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) - [specscore/specscore-cli](https://github.com/specscore/specscore-cli) - [specscore-cli — licence Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) - [specscore/specscore — dogfood.yml (CLI v0.39.1)](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) - [specscore-cli v0.55.1 — ac-heading-format](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/ac_heading.go) - [specscore-cli v0.55.1 — règles de plan P-001 et P-002](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/plan_rules.go) - [Linter des spécifications en CI avec un linter de spécifications](https://specscore.md/fr/articles/lint-specs-in-ci/) - [Comment écrire des critères d'acceptation qu'un agent d'IA peut vérifier](https://specscore.md/fr/articles/acceptance-criteria/) - [Syntaxe des exigences EARS expliquée, avec exemples](https://specscore.md/fr/articles/ears-requirements/) - [CLI Skills — la CLI SpecScore dans Claude Code](https://specscore.md/fr/ai/cli-skills/) - [SpecStudio Skills](https://specscore.md/fr/ai/specstudio-skills/) - [specscore/ai-plugin-specscore](https://github.com/specscore/ai-plugin-specscore) - [Ce que SpecScore valide](https://specscore.md/fr/validators/) - [Rehearse](https://specscore.md/rehearse) - [Référence de la CLI OpenSpec — openspec validate](https://openspec.dev/docs/cli) - [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) - [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) - [Documentation de GitHub Spec Kit (date de page 28 septembre 2026)](https://github.github.io/spec-kit/) - [Outils de développement piloté par les spécifications](https://specscore.md/fr/spec-driven-development/tools/) ## En lien - [Développement piloté par les spécifications avec Claude Code et Cursor](https://specscore.md/fr/articles/claude-code-specs/) - [Spécification de fonctionnalité](https://specscore.md/feature-specification) - [Spécification des critères d’acceptation](https://specscore.md/acceptance-criteria-specification) - [Spécification de plan](https://specscore.md/plan-specification) - [Spécification de tâche](https://specscore.md/task-specification) - [Comment écrire des critères d'acceptation qu'un agent d'IA peut vérifier](https://specscore.md/fr/articles/acceptance-criteria/) - [Syntaxe des exigences EARS expliquée, avec exemples](https://specscore.md/fr/articles/ears-requirements/) - [Linter des spécifications en CI avec un linter de spécifications](https://specscore.md/fr/articles/lint-specs-in-ci/) - [Développement piloté par les spécifications](https://specscore.md/fr/spec-driven-development/) - [Outils de développement piloté par les spécifications](https://specscore.md/fr/spec-driven-development/tools/) - [CLI Skills pour Claude Code](https://specscore.md/fr/ai/cli-skills/) - [CLI](https://specscore.md/fr/cli/)