Шаблон PRD у Markdown для програмування зі ШІ

Документ вимог до продукту (PRD, product requirements document) — проза, яка називає проблему і межі до того, як роботу ділять на завдання. Специфікація функції — файл SpecScore для однієї можливості продукту, і цей файл каже, що можливість робить, навіщо вона існує і як вона поводиться. Markdown — текстовий формат цього файлу. Розробка за специфікаціями (SDD, spec-driven development) — практика написати специфікацію до коду і вважати специфікацію джерелом правди. У SpecScore вимога (REQ) — іменоване правило всередині функції. Критерій приймання (AC, acceptance criterion) — необов’язкова абстрактна умова, яка вказує на одне або кілька таких правил. Сценарій — конкретний приклад, записаний кроками Given, When і Then. План — документ, який ділить функцію на завдання. Завдання — одна одиниця роботи, яку може завершити людина або агент. Безперервна інтеграція (CI, continuous integration) — автоматична перевірка кожної запропонованої зміни. Перевірка — це команда інтерфейсу командного рядка (CLI, command-line interface), specscore spec lint, з CLI у specscore/specscore-cli. Easy Approach to Requirements Syntax (EARS) — шаблон речення, який може використати вимога. Claude Code — ШІ-агент програмування, для якого написано плагін CLI Skills на цьому сайті. Цей шаблон специфікації функції — той файл функції разом із планом і завданням, які вказують назад на нього.

Оновлено: 5 листопада 2026

Що це за шаблон специфікації функції

PRD часто є одним файлом прози, який читає людина. SpecScore тримає той самий стислий виклад файлами, які може перевірити лінтер. Специфікація функції називає функцію атомною одиницею специфікації продукту: каталог під spec/features/, чий README.md є єдиним джерелом правди про те, що функція робить. Специфікація плану називає план документом, який розкладає цю функцію на завдання. Сценарій у специфікації сценарію — конкретний файл Given/When/Then у каталозі _tests/ функції. Специфікація критеріїв приймання лишає критерій абстрактним: вона каже, що має бути істинним, а сценарій каже, як це довести.

Файл checkout нижче — це заповнений шаблон. Разом з індексом функцій, README специфікації і specscore.yaml команда specscore spec lint прийняла його з 0 порушеннями. Цю перевірку виконано 2 листопада 2026 року зі specscore 0.55.1 і з 0.39.1, тегом, який встановлює dogfood.yml. Рядок панелі Studio у файлі функції — рядок, який несуть README функцій у specscore/specscore. Таблиця обов’язкових розділів у специфікації функції його не містить.

README функції

Таблиця обов’язкових розділів специфікації функції каже, що кожен README функції має заголовок # Feature: {Title}, рядок **Status:** одразу після заголовка, Summary, Problem, розділ Behavior, розділ Acceptance Criteria, розділ Open Questions і нижній рядок дотримання. Значення статусу — одне з Draft, In Review, Approved, Implementing, Stable, Amending, Rejected або Deprecated. Розділ Contents обов’язковий лише тоді, коли функція має дочірні каталоги. **Source Ideas:** необов’язковий. Перевірений файл ставить його в —.

Open Questions ніколи не пропускають. Коли їх немає, розділ каже None at this time. Acceptance Criteria теж ніколи не пропускають. Коли критеріїв не визначено, той розділ каже Not defined yet. і Open Questions тоді мусить містити Acceptance criteria not yet defined for this feature. Нижній рядок — останній, і його URL — https://specscore.md/feature-specification.

Конвенція frontmatter артефактів каже, що кожен артефакт несе ключ format: у YAML frontmatter, а артефакт зі статусом несе ще й status:, дзеркало токена **Status:** у тілі. Та сама функція каже, що lint-правила, які це примушують, виходять після пільгового періоду. Перевірений файл містить обидва ключі. Ця сторінка не стверджує, що pin v0.39.1 відхиляє файл, який їх пропускає.

README функції, який прийняв specscore spec lint (2 листопада 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*

Індекс функцій із того самого запуску 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 специфікації з того самого запуску lint

# Checkout specification

## Open Questions

None at this time.

specscore.yaml із того самого запуску lint

# SpecScore Repo Config Schema: https://specscore.md/repo-config

project:
  title: Checkout sample
  host: github.com
  org: example
  repo: checkout

Ідентифікатор функції — шлях її каталогу відносно spec/features/. Посилання індексу checkout/README.md означає, що файл лежить у spec/features/checkout/README.md, тож id функції, який використовують вимоги і критерії, — checkout. Індекс перелічує кожну функцію верхнього рівня. Дочірній каталог, якого немає в списку, — порушення index-entries, яке описує Лінтувати специфікації в CI лінтером специфікацій. README специфікації в тому дереві має один розділ, Open Questions, і він каже None at this time. Файл конфігурації — те, що CLI шукає вгору. Без specscore.yaml команда завершується з кодом 3 і називає specscore init.

Ідентифікатори REQ, критерії приймання і сценарії

Специфікація вимоги кладе кожне правило під заголовок теми всередині ## Behavior. Заголовок — #### REQ: {slug}, з одним пробілом після двокрапки. Slug використовує малі літери, цифри і дефіси. Канонічний id — {feature-path}#req:{slug}. У файлі checkout це checkout#req:show-field-error і checkout#req:reject-invalid-email. Вимога називає одне зобов’язання. Специфікація каже, що вимоги SHOULD використовують ключові слова RFC 2119: MUST, MUST NOT, SHOULD, SHOULD NOT і MAY. Заголовок REQ: не є дійсним поза ## Behavior. Речення EARS може бути цією прозою. Лінтер не оцінює англійську. Шаблони є в синтаксисі вимог EARS.

Критерій приймання

Специфікація критеріїв приймання каже, що кожен критерій — це заголовок ### AC: {slug} усередині ## Acceptance Criteria, потім рядок **Requirements:**, який перелічує значення {feature-id}#req:{slug}, а потім абстрактне твердження про те, що має бути істинним. Критерії необов’язкові. Специфікація каже додати один, коли об’єднання двох або більше пов’язаних вимог додає ясності. Файл checkout об’єднує обидва правила в checkout#ac:invalid-submission. Твердження не містить Given, When чи Then. Як писати критерії приймання — посібник із написання. Правило ac-heading-format (ac_heading.go на тегу CLI v0.55.1) перевіряє, що заголовок — ### AC: <id> з id у kebab-case. Стаття про lint записує, що це правило не вимагає рядка **Requirements:** і не оцінює слова. Специфікація критеріїв приймання все одно вимагає цей рядок.

Сценарій

Специфікація сценарію кладе сценарій у _tests/, який не є підфункцією і виключений з індексу функцій. Файл починається з # Scenario: {Title}, рядка **Validates:**, який вказує на вимогу або критерій, і розділу ## Steps, чиї ключові слова — великі GIVEN, WHEN, THEN і AND. Кожен каталог _tests/ мусить містити README з індексом сценаріїв. Зразок нижче — ця форма файла. Він не входив до запуску lint 2 листопада. specscore spec lint не перевіряє ключові слова кроків сценарію. specscore rehearse виконує файли сценаріїв. Rehearse — цей виконавець. Воркфлоу dogfood виконує лінтер і не викликає rehearse.

Форма файла сценарію зі специфікації сценарію

# 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

Читайте три шари по порядку. Вимога каже правило. Критерій приймання каже, що має бути істинним для правил, які він називає. Сценарій дає один конкретний потік. Агент, який бачить лише прозу PRD, мусить вигадати цей поділ. Шаблон уже має його.

Плани і завдання

README плану лежить у spec/plans/{plan-slug}/README.md. Специфікація плану вимагає заголовок # Plan: {Title} і поля шапки Status, рівно один рядок джерела, Date, Owner і Supersedes. План із джерелом-функцією використовує **Source Feature:** плюс slug функції, тут checkout. Інші дозволені рядки джерела — **Source:** idea:{slug} і **Source:** none. Обов’язкові розділи — Summary, Approach, Tasks і Open Questions. Усередині плану кожне завдання — заголовок ### Task N: з рядком **Verifies:** форми feature-slug#ac:ac-slug. Правило P-001 у plan_rules.go повідомляє про заголовок критерію приймання, який не покриває жодне завдання і якого немає під ## Deferred AC Coverage. Правило P-002 повідомляє про значення **Verifies:**, яке не зводиться до жодного з цих заголовків. Плани з джерелом-ідеєю і плани з **Source:** none звільнені від P-001.

План нижче дотримується цієї опублікованої форми для функції checkout, включно з frontmatter format: і status:. Його не було в запуску lint 2 листопада. Функція, якої торкається план, мусить містити таблицю ## Plans зі стовпцями Plan, Status, Author і Approved. Перевірений файл функції не має розділу Plans, бо в тому дереві немає плану.

Специфікація завдання також визначає завдання як власний каталог і README.md під планом. Заголовок — # Task: {Title}. Обов’язкові поля — **Status:**, **Depends on:** (буквальне none, коли залежності немає) і **Model:** (small, medium, large або inherit). Каталог, який містить дочірні каталоги завдань, є планом, а не завданням. Файл завдання нижче використовує ці поля для першого завдання checkout. Його не було в запуску lint 2 листопада. URL нижнього рядка документа завдання — https://specscore.md/task-specification.

Форма плану зі специфікації плану, заповнена для 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*

Форма документа завдання зі специфікації завдання

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

Файл функції відповідає, що має робити форма checkout. План відповідає, як цю роботу поділено, і кожне вбудоване завдання називає критерій, який воно перевіряє. Документ завдання — листок, який бере людина або агент. Тримайте id критерію стабільним. checkout#ac:invalid-submission — рядок, який використовують і функція, і план.

Лінт шаблону в CI

specscore spec lint перевіряє дерево специфікацій на порушення структурних конвенцій. Чистий запуск друкує 0 violations found і завершується з кодом 0. Запуск, який знаходить порушення, друкує один рядок на кожне зауваження і завершується з кодом 1. Цей код виходу валить job CI. Неправильні аргументи завершуються з кодом 2. Відсутність specscore.yaml завершується з кодом 3. dogfood.yml встановлює CLI з SPECSCORE_VERSION, рівним v0.39.1, і потім виконує specscore spec lint на pull requests і на push до main. Уривок воркфлоу, звіт про збій і каталог правил є в Лінтувати специфікації в CI лінтером специфікацій.

Ліцензія формату — CC BY 4.0 у specscore/specscore. Ліцензія CLI — Apache-2.0 у specscore/specscore-cli.

Інші інструменти розробки за специфікаціями публікують інші перевірки. Речення нижче використовують лише те, що кажуть власні сторінки тих проєктів. Інструменти розробки за специфікаціями записують ті самі сторінки як прочитані 30 жовтня 2026 року, крім головної сторінки документації Spec Kit, яка друкує 28 вересня 2026 року.

OpenSpec документує openspec validate у своєму довіднику CLI. Ця команда перевіряє структуру зміни і специфікації OpenSpec і завершується ненульовим кодом, коли перевірка не минає. Вона не перевіряє заголовок SpecScore ### AC: і не індекс SpecScore.

README Task Master описує розбір PRD на завдання командою task-master parse-prd. Він не описує лінтер для того PRD. PRD і далі може бути текстом, який ви переписуєте у файл функції на цій сторінці. specscore spec lint — те, що тоді перевіряє файл функції.

GitHub Spec Kit описує агентний воркфлоу, чиї фази пишуть артефакти Markdown. Та головна сторінка документації не описує команду, яка лінтує README функції SpecScore у CI. Порівняння тих інструментів — інструменти розробки за специфікаціями.

Шаблон специфікації, який може прочитати Claude Code

Файли — це Markdown, тож агент, який може прочитати репозиторій, може прочитати шаблон. Claude Code — агент, на якого націлена сторінка CLI Skills. Та сторінка документує ai-plugin-specscore, тонкий плагін Claude Code, який обгортає CLI. Репозиторій плагіна — specscore/ai-plugin-specscore. Сторінка каже, що плагін подає specscore spec lint, specscore feature, specscore task і specscore feature change-status як команди плагіна. Рядки встановлення на тій сторінці — /plugin marketplace add specscore/ai-marketplace і /plugin install cli-skills@specscore.

Та сама сторінка документує specscore agent setup <agent-name> для claude, copilot, cursor, codex, antigravity.google, pi.dev або opencode, запуск усередині проєкту, яким керує SpecScore. SpecStudio Skills — керований воркфлоу (/ideate, /specify, /plan, /implement) і теж є плагіном Claude Code. Шаблон на цій сторінці — файл, який ці команди лінтують. Плагін не замінює README функції.

Питання й відповіді

Що таке шаблон PRD у Markdown?

Це документ вимог до продукту, записаний файлами Markdown фіксованої форми. У SpecScore ця форма — README функції: заголовок, статус, стислий виклад, проблема, поведінка з правилами #### REQ:, критерії приймання і відкриті питання. Файл checkout на цій сторінці — один із тих, які прийняв specscore spec lint.

Куди в шаблоні специфікації функції класти ідентифікатори REQ?

Під заголовок теми всередині ## Behavior, як #### REQ: {slug}. Id — {feature-path}#req:{slug}. Критерії приймання перелічують ці id в **Requirements:**. Завдання плану перелічує id критерію в **Verifies:**.

Чим критерій приймання відрізняється від сценарію?

Критерій приймання — абстрактна умова. Сценарій — конкретний потік Given/When/Then у _tests/. Специфікація критеріїв приймання каже, що критерій не мусить приписувати кроки. Файл сценарію їх приписує.

Чи оцінює лінтер прозу PRD?

Ні. specscore spec lint перевіряє структуру: заголовки, обов’язкові розділи, рядки індексу і посилання на кшталт P-001 і P-002. Він не вирішує, чи продукт — добра ідея. Лінтувати специфікації в CI лінтером специфікацій — довша розповідь про цю команду.

Чи може Claude Code використати цей шаблон специфікації?

Так. Шаблон — це Markdown у репозиторії. Плагін CLI Skills подає specscore spec lint і команди функції та завдання всередині Claude Code. specscore agent setup claude пише файл інструкцій для того агента. Плагін не вигадує іншого шаблону.

Чи план замінює специфікацію функції?

Ні. README функції — джерело вимог і критеріїв приймання. План розкладає цю функцію на завдання, і кожне завдання вказує назад через **Verifies:**. Специфікація плану і специфікація завдання — два документи цього поділу.

Джерела

Функцію checkout, індекс функцій, README специфікації і specscore.yaml прийняв specscore spec lint 2 листопада 2026 року зі specscore 0.55.1 і з 0.39.1. Зразки плану і завдання дотримуються опублікованих специфікацій і не входили до того запуску. Сторінки конкурентів — ті, що пов’язані нижче; огляд інструментів записує їх як прочитані 30 жовтня 2026 року, крім головної сторінки документації Spec Kit, яка друкує 28 вересня 2026 року.