Modèle de PRD en Markdown pour coder avec l’IA

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é 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 (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, une exigence (REQ) est une règle nommée dans une fonctionnalité. Un critère d’acceptation (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 est le document qui découpe la fonctionnalité en tâches. Une tâche est une unité de travail qu’une personne ou un agent peut terminer. L’intégration continue (CI, continuous integration) est un contrôle automatique à chaque changement proposé. Le contrôle est une commande de l’interface en ligne de commande (CLI, command-line interface), specscore spec lint, de la CLI dans specscore/specscore-cli. Easy Approach to Requirements Syntax (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 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.

Dernière mise à jour : 5 novembre 2026

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é 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 appelle plan le document qui décompose cette fonctionnalité en tâches. Un scénario, dans la spécification de scénario, est un fichier concret Given/When/Then dans le répertoire _tests/ de la fonctionnalité. La spécification des critères d’acceptation 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 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. 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 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)

---
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

---
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

# Checkout specification

## Open Questions

None at this time.

specscore.yaml du même passage de lint

# 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. 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 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.

Critère d’acceptation

La spécification des critères d’acceptation 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 est le guide de rédaction. La règle ac-heading-format (ac_heading.go à l’étiquette v0.55.1 de la CLI) vérifie que le titre est ### AC: <id> avec un id en kebab-case. L’article sur le lint 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 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 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

# 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 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 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 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

---
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

---
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 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.

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 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 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 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 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 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.

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. 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. 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 <agent-name> pour claude, copilot, cursor, codex, antigravity.google, pi.dev ou opencode, exécuté dans un projet géré par SpecScore. 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 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 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 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 et la spécification de tâche 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.