# Шаблон PRD в Markdown для программирования с ИИ Canonical: https://specscore.md/ru/articles/feature-spec-template/ Обновлено: 5 ноября 2026 Документ требований к продукту (PRD, product requirements document) — проза, которая называет проблему и рамки до того, как работу делят на задачи. [Спецификация функции](https://specscore.md/feature-specification) — файл SpecScore для одной возможности продукта: что она делает, зачем существует и как ведёт себя. Markdown — это формат простого текста этого файла. [Разработка по спецификациям](https://specscore.md/ru/spec-driven-development/) (SDD, spec-driven development) — практика писать спецификацию до кода и считать спецификацию источником правды. В [SpecScore](https://specscore.md/) требование (REQ) — именованное правило внутри функции. [Критерий приёмки](https://specscore.md/acceptance-criteria-specification) (AC, acceptance criterion) — необязательное абстрактное условие, которое указывает на одно или несколько таких правил. Сценарий — конкретный пример, записанный шагами Given, When и Then. [План](https://specscore.md/plan-specification) — документ, который делит функцию на задачи. [Задача](https://specscore.md/task-specification) — одна единица работы, которую может закончить человек или агент. [Непрерывная интеграция](https://specscore.md/ru/validators/) (CI, continuous integration) — автоматическая проверка каждого предлагаемого изменения. Проверка — команда [интерфейса командной строки](https://specscore.md/ru/cli/) (CLI, command-line interface), `specscore spec lint`, из CLI в [specscore/specscore-cli](https://github.com/specscore/specscore-cli). [Easy Approach to Requirements Syntax](https://specscore.md/ru/articles/ears-requirements/) (EARS) — шаблон предложения, который может использовать требование. Claude Code — это ИИ-агент программирования, для которого на этом сайте написан плагин [CLI Skills](https://specscore.md/ru/ai/cli-skills/). Этот шаблон спецификации функции — тот файл функции плюс план и задача, которые ссылаются обратно на него. ## Что это за шаблон спецификации функции PRD часто бывает одним файлом прозы, который читает человек. SpecScore хранит то же описание в файлах, которые может проверить линтер. [Спецификация функции](https://specscore.md/feature-specification) называет функцию атомарной единицей спецификации продукта: каталогом под `spec/features/`, чей `README.md` — единственный источник правды о том, что делает функция. [Спецификация плана](https://specscore.md/plan-specification) называет планом документ, который раскладывает эту функцию на задачи. Сценарий, в [спецификации сценария](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md), — конкретный файл Given/When/Then в каталоге `_tests/` функции. [Спецификация критериев приёмки](https://specscore.md/acceptance-criteria-specification) держит критерий абстрактным: она говорит, что должно быть истинным, а сценарий говорит, как это доказать. Файл checkout ниже — заполненный шаблон. Вместе с индексом функций, README спецификации и `specscore.yaml` команда `specscore spec lint` приняла его с 0 нарушениями. Эту проверку запустили 2 ноября 2026 со specscore 0.55.1 и с 0.39.1, тегом, который устанавливает [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). Строка панели SpecScore Studio в файле функции — это строка, которую несут README функций в [specscore/specscore](https://github.com/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 артефактов](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md) говорит, что каждый артефакт несёт ключ `format:` во frontmatter YAML, а артефакт со статусом несёт ещё `status:`, зеркало токена `**Status:**` в теле. Та же функция говорит, что принуждающие правила lint выходят после льготного периода. Проверенный файл включает оба ключа. Эта страница не утверждает, что pin v0.39.1 отвергает файл, который их опускает. ### README функции, который принял specscore spec lint (2 ноября 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* ``` ### Индекс функций из того же запуска 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 спецификации из того же запуска lint ```markdown # Checkout specification ## Open Questions None at this time. ``` ### specscore.yaml из того же запуска lint ```yaml # 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](https://specscore.md/ru/articles/lint-specs-in-ci/). README спецификации в этом дереве имеет один раздел, Open Questions, и говорит `None at this time.` Файл конфигурации — это то, что CLI ищет вверх по каталогам. Без `specscore.yaml` команда завершается с кодом 3 и называет `specscore init`. ## Идентификаторы REQ, критерии приёмки и сценарии [Спецификация требования](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) кладёт каждое правило под тематический заголовок внутри `## 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](https://specscore.md/ru/articles/ears-requirements/). ### Критерий приёмки [Спецификация критериев приёмки](https://specscore.md/acceptance-criteria-specification) говорит, что каждый критерий — это заголовок `### AC: {slug}` внутри `## Acceptance Criteria`, затем строка `**Requirements:**`, которая перечисляет значения `{feature-id}#req:{slug}`, затем абстрактное утверждение того, что должно быть истинным. Критерии необязательны. Спецификация говорит добавлять критерий, когда объединение двух или более связанных требований добавляет ясности. Файл checkout объединяет оба правила в `checkout#ac:invalid-submission`. Утверждение не содержит Given, When или Then. [Как писать критерии приёмки](https://specscore.md/ru/articles/acceptance-criteria/) — это руководство по написанию. Правило `ac-heading-format` ([ac_heading.go](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/ac_heading.go) на теге CLI v0.55.1) проверяет, что заголовок — `### AC: ` с id в kebab-case. [Статья о линте](https://specscore.md/ru/articles/lint-specs-in-ci/) записывает, что это правило не требует строки `**Requirements:**` и не оценивает слова. Спецификация критериев приёмки всё же требует этой строки. ### Сценарий [Спецификация сценария](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) помещает сценарий в `_tests/`, который не является подфункцией и исключён из индекса функций. Файл начинается с `# Scenario: {Title}`, строки `**Validates:**`, указывающей на требование или критерий, и раздела `## Steps`, ключевые слова которого написаны заглавными буквами: GIVEN, WHEN, THEN и AND. Каждый каталог `_tests/` должен содержать README с индексом сценариев. Образец ниже — эта форма файла. Он не входил в запуск lint 2 ноября. `specscore spec lint` не проверяет ключевые слова шагов сценария. `specscore rehearse` запускает файлы сценариев. [Rehearse](https://specscore.md/rehearse) — это этот запускатель. Воркфлоу dogfood запускает линтер и не вызывает rehearse. ### Форма файла сценария по спецификации сценария ```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 ``` Читайте три слоя по порядку. Требование говорит правило. Критерий приёмки говорит, что должно быть истинным для правил, которые он называет. Сценарий даёт один конкретный поток. Агенту, который видит только прозу PRD, приходится выдумывать это разделение. В шаблоне оно уже есть. ## Планы и задачи README плана лежит в `spec/plans/{plan-slug}/README.md`. [Спецификация плана](https://specscore.md/plan-specification) требует заголовок `# 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](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/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, потому что в этом дереве нет плана. [Спецификация задачи](https://specscore.md/task-specification) также определяет задачу как собственный каталог и `README.md` под планом. Заголовок — `# Task: {Title}`. Обязательные поля — `**Status:**`, `**Depends on:**` (литерал `none`, когда зависимости нет) и `**Model:**` (`small`, `medium`, `large` или `inherit`). Каталог, который содержит каталоги дочерних задач, — это план, а не задача. Файл задачи ниже использует эти поля для первой задачи checkout. Его не было в запуске lint 2 ноября. URL колонтитула документа задачи — `https://specscore.md/task-specification`. ### Форма плана из спецификации плана, заполненная для 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* ``` ### Форма документа задачи из спецификации задачи ```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* ``` Файл функции отвечает, что должна делать форма checkout. План отвечает, как эта работа разделена, и каждая встроенная задача называет критерий, который она проверяет. Документ задачи — лист, который берёт человек или агент. Держите id критерия стабильным. `checkout#ac:invalid-submission` — строка, которую используют и функция, и план. ## Линтовать шаблон в CI `specscore spec lint` проверяет дерево спецификаций на нарушения структурных соглашений. Чистый запуск печатает `0 violations found` и завершается с кодом 0. Запуск, который находит нарушения, печатает одну строку на каждое замечание и завершается с кодом 1. Этот код выхода роняет job CI. Неверные аргументы завершаются с кодом 2. Отсутствие `specscore.yaml` завершается с кодом 3. [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) устанавливает CLI с `SPECSCORE_VERSION`, заданным как `v0.39.1`, и затем запускает `specscore spec lint` на pull requests и на push в main. Фрагмент воркфлоу, отчёт о сбое и каталог правил — в [линтовании спецификаций в CI](https://specscore.md/ru/articles/lint-specs-in-ci/). Лицензия формата — [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) в [specscore/specscore](https://github.com/specscore/specscore). Лицензия CLI — [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) в [specscore/specscore-cli](https://github.com/specscore/specscore-cli). Другие инструменты разработки по спецификациям публикуют другие проверки. Предложения ниже используют только то, что говорят собственные страницы этих проектов. [Обзор инструментов](https://specscore.md/ru/spec-driven-development/tools/) записывает те же страницы как прочитанные 30 октября 2026, кроме домашней страницы документации Spec Kit, которая печатает 28 сентября 2026. [OpenSpec](https://github.com/Fission-AI/OpenSpec) документирует `openspec validate` в своём [справочнике CLI](https://openspec.dev/docs/cli). Эта команда проверяет структуру изменений и спецификаций OpenSpec и завершается ненулевым кодом, когда проверка не проходит. Она не проверяет заголовок SpecScore `### AC:` и не проверяет индекс SpecScore. README [Task Master](https://github.com/eyaltoledano/claude-task-master) описывает разбор PRD на задачи командой `task-master parse-prd`. Он не описывает линтер для этого PRD. PRD по-прежнему может быть исходным текстом, который переписывают в файл функции на этой странице. `specscore spec lint` — это то, что затем проверяет файл функции. [GitHub Spec Kit](https://github.github.io/spec-kit/) описывает агентный воркфлоу, фазы которого пишут артефакты Markdown. Эта домашняя страница документации не описывает команду, которая линтует README функции SpecScore в CI. Сравнение этих инструментов — [обзор инструментов](https://specscore.md/ru/spec-driven-development/tools/). ## Шаблон спецификации, который может прочитать Claude Code Файлы — это Markdown, поэтому агент, который может читать репозиторий, может читать шаблон. Claude Code — агент, на которого нацелена страница [CLI Skills](https://specscore.md/ru/ai/cli-skills/). Эта страница документирует `ai-plugin-specscore`, тонкий плагин Claude Code, который оборачивает CLI. Репозиторий плагина — [specscore/ai-plugin-specscore](https://github.com/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 ` для `claude`, `copilot`, `cursor`, `codex`, `antigravity.google`, `pi.dev` или `opencode`, запущенный внутри проекта под управлением SpecScore. [SpecStudio Skills](https://specscore.md/ru/ai/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/`. [Спецификация критериев приёмки](https://specscore.md/acceptance-criteria-specification) говорит, что критерий не должен предписывать шаги. Файл сценария это делает. ### Оценивает ли линтер прозу PRD? Нет. `specscore spec lint` проверяет структуру: заголовки, обязательные разделы, строки индекса и ссылки вроде `P-001` и `P-002`. Он не решает, хороша ли идея продукта. [Линтовать спецификации в CI](https://specscore.md/ru/articles/lint-specs-in-ci/) — более подробный рассказ об этой команде. ### Может ли Claude Code использовать этот шаблон спецификации? Да. Шаблон — это Markdown в репозитории. Плагин [CLI Skills](https://specscore.md/ru/ai/cli-skills/) предоставляет `specscore spec lint` и команды функции и задачи внутри Claude Code. `specscore agent setup claude` пишет файл инструкций для этого агента. Плагин не выдумывает другой шаблон. ### Заменяет ли план спецификацию функции? Нет. README функции — источник требований и критериев приёмки. План раскладывает эту функцию на задачи, и каждая задача указывает назад через `**Verifies:**`. [Спецификация плана](https://specscore.md/plan-specification) и [спецификация задачи](https://specscore.md/task-specification) — два документа этого разделения. ## Источники Функция checkout, индекс функций, README спецификации и specscore.yaml были приняты specscore spec lint 2 ноября 2026 со specscore 0.55.1 и с 0.39.1. Образцы плана и задачи следуют опубликованным спецификациям и не входили в этот запуск. Страницы конкурентов — те, что связаны ниже; обзор инструментов записывает их как прочитанные 30 октября 2026, кроме домашней страницы документации Spec Kit, которая печатает 28 сентября 2026. - [Спецификация функции](https://specscore.md/feature-specification) - [specscore/specscore — спецификация функции](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md) - [specscore/specscore — спецификация требования](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [Спецификация критериев приёмки](https://specscore.md/acceptance-criteria-specification) - [specscore/specscore — спецификация критериев приёмки](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — спецификация сценария](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [Спецификация плана](https://specscore.md/plan-specification) - [specscore/specscore — спецификация плана](https://github.com/specscore/specscore/blob/main/spec/features/plan/README.md) - [Спецификация задачи](https://specscore.md/task-specification) - [specscore/specscore — спецификация задачи](https://github.com/specscore/specscore/blob/main/spec/features/task/README.md) - [specscore/specscore — соглашение о frontmatter артефактов](https://github.com/specscore/specscore/blob/main/spec/features/artifact-frontmatter-convention/README.md) - [specscore/specscore](https://github.com/specscore/specscore) - [specscore/specscore — лицензия CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) - [specscore/specscore-cli](https://github.com/specscore/specscore-cli) - [specscore-cli — лицензия 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 — правила плана P-001 и P-002](https://github.com/specscore/specscore-cli/blob/v0.55.1/pkg/lint/plan_rules.go) - [Линтовать спецификации в CI линтером спецификаций](https://specscore.md/ru/articles/lint-specs-in-ci/) - [Как писать критерии приёмки, которые проверит ИИ-агент](https://specscore.md/ru/articles/acceptance-criteria/) - [Синтаксис требований EARS с объяснением и примерами](https://specscore.md/ru/articles/ears-requirements/) - [CLI Skills — SpecScore CLI внутри Claude Code](https://specscore.md/ru/ai/cli-skills/) - [SpecStudio Skills](https://specscore.md/ru/ai/specstudio-skills/) - [specscore/ai-plugin-specscore](https://github.com/specscore/ai-plugin-specscore) - [Что проверяет SpecScore](https://specscore.md/ru/validators/) - [Rehearse](https://specscore.md/rehearse) - [Справочник 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) - [Документация GitHub Spec Kit (дата страницы 28 сентября 2026)](https://github.github.io/spec-kit/) - [Инструменты разработки по спецификациям](https://specscore.md/ru/spec-driven-development/tools/) ## Связанное - [Разработка по спецификациям с Claude Code и Cursor](https://specscore.md/ru/articles/claude-code-specs/) - [Спецификация функции](https://specscore.md/feature-specification) - [Спецификация критериев приёмки](https://specscore.md/acceptance-criteria-specification) - [Спецификация плана](https://specscore.md/plan-specification) - [Спецификация задачи](https://specscore.md/task-specification) - [Как писать критерии приёмки, которые проверит ИИ-агент](https://specscore.md/ru/articles/acceptance-criteria/) - [Синтаксис требований EARS с объяснением и примерами](https://specscore.md/ru/articles/ears-requirements/) - [Линтовать спецификации в CI линтером спецификаций](https://specscore.md/ru/articles/lint-specs-in-ci/) - [Разработка по спецификациям](https://specscore.md/ru/spec-driven-development/) - [Инструменты разработки по спецификациям](https://specscore.md/ru/spec-driven-development/tools/) - [CLI Skills для Claude Code](https://specscore.md/ru/ai/cli-skills/) - [CLI](https://specscore.md/ru/cli/)