# SpecScore vs BMAD Method

Canonical: https://specscore.md/uk/vs/bmad-method/

[BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD) (проривний метод гнучкої розробки під керуванням ШІ) — це спосіб [з відкритим вихідним кодом](https://github.com/bmad-code-org/BMAD-METHOD) провадити гнучке постачання з ШІ-агентами: прояснити роботу, спланувати її, побудувати й перевірити, записуючи рішення. Документ вимог до продукту (PRD) — прозовий опис того, що будувати і для кого; карта workflow методу створює такий документ, потім архітектуру й історії. [Розробка на основі специфікацій](https://specscore.md/uk/spec-driven-development/) (SDD) — ширша ідея, всередині якої перебувають обидва: поведінку задають до коду. [SpecScore](https://specscore.md/uk/) — це формат [з відкритим вихідним кодом](https://github.com/specscore/specscore) для цієї специфікації плюс [інтерфейс командного рядка](https://specscore.md/uk/cli/) (CLI). [Безперервна інтеграція](https://specscore.md/uk/validators/) (CI) — автоматична перевірка кожної запропонованої зміни — може завершитися невдачею, коли файл SpecScore структурно хибний.

## Що в них спільного.

- Обидва не дозволяють агенту вигадувати продукт, поки він пише код.
- Обидва зберігають документи планування в репозиторії, у Markdown, поруч із роботою.
- Обидва очікують, що людина затвердить план, перш ніж реалізація піде своїм ходом.

## Що BMAD Method робить добре.

README проєкту, прочитаний 30 жовтня 2026, називає v6.12 стабільним релізом, а v7 — preview на гілці main. Дата v7 в тому README вже минула. Вважайте назви ліній знімком.

### Метод, який сам обирає масштаб

README каже, що невеликі зміни йдуть одразу в збірку, а більша робота отримує планування. [Карта workflow на main](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/reference/workflow-map.md) розписує фази: PRD (`PRD.md`), необов’язкову UX-специфікацію, `architecture.md` із записами рішень, файли епіків та історій, потім спринт. Це повний гнучкий цикл, а не один промпт.

### Брама до реалізації

Та сама карта перелічує `bmad-check-implementation-readiness`, який повертає PASS, CONCERNS або FAIL до реалізації. В агента product-manager у v6 також є крок validate-PRD. Це брами workflow, які запускає агент. Це не окремий лінтер формату, який ви спрямовуєте на довільне дерево Markdown.

### Його справді опубліковано

Метод випущено [за ліцензією MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE) у публічному репозиторії. Стабільне встановлення з README — `npx bmad-method install`, і воно просить Node.js 20.12 або новіший і Python 3.10 або новіший. Сайт [bmadcode.com](https://www.bmadcode.com/) каже, що метод безкоштовний.

## Порівняння функцій.

BMAD — це процес. SpecScore — формат артефакту, на який процес може націлюватися. Таблиця порівнює ці ролі.

| Можливість | BMAD Method | SpecScore |
| --- | --- | --- |
| Основна роль | Гнучкий метод: агенти, навички і workflow від ідеї до перевіреного коду | **Відкритий формат специфікацій + CLI** |
| Артефакти планування | PRD, UX-специфікація, архітектура, епіки та історії, статус спринту — на карті workflow, прочитаній 30 жовтня 2026 | **Ідеї, фічі, плани, завдання** у дереві spec/, з ідентифікаторами вимог |
| Перевірка роботи | Брама готовності (PASS / CONCERNS / FAIL) і workflow validate-PRD, які запускає агент | **specscore spec lint** у CI, детерміновано. `/score` — ручна оцінка ШІ. |
| Ідентифікатори вимог | Історії та функціональні вимоги всередині PRD і файлів епіків. Це не REQ: slug зі SpecScore. | **REQ: slug** і ідентифікатори критеріїв приймання |
| Середовище виконання | Node.js і Python для встановлювача v6.12, описаного в README | **Нічого** понад один бінарник Go |
| Ліцензія | [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE), [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) формат · [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) CLI |

## Що додає SpecScore.

### Перевірка — це команда, а не крок методу

Результат готовності BMAD — рішення всередині його workflow. Результат SpecScore — код завершення процесу. [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) запускає `specscore spec lint` на кожному pull request. [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) оцінює артефакт рев’юерами, налаштованими в репозиторії; викликаєте його ви. CI цього не робить.

```
$ specscore spec lint

features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found
features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds
features/apply-discount/refunds:0 [error] readme-exists: README.md not found

3 violations found (3 errors)
```

### Формат переживає інший метод

Документи BMAD сформовані його workflow. Якщо припинити запускати BMAD, Markdown лишиться, але ніщо поза методом не забезпечує форму. Дерево SpecScore — це контракт. Інший workflow — включно з BMAD — може його писати, і лінтер усе одно застосовується.

### Історії та вимоги лишаються зв’язаними ідентифікатором

Історії BMAD несуть контекст далі, щоб агент не вирішував продукт наново. SpecScore робить зв’язок механічним: завдання плану цитує `REQ: slug`, а анотації `specscore:` плюс трейлери коміту `Verifies:` вказують код назад на критерій.

## Коли який використовувати.

### Беріть BMAD Method, коли…

- Вам потрібен повний гнучкий цикл — PRD, архітектура, історії, спринт, — який виконують агенти з workflow під конкретні ролі.
- Вам потрібні брама готовності і набір поглядів продукту, архітектури й тестів, який постачає метод.
- Ви стандартизуєте те, як команда пише промпти, і навички методу — цей стандарт.

### Використовуйте SpecScore, коли…

- Специфікація має падати в CI, коли хибні заголовок, посилання або статус, навіть якщо цього дня ніхто не запускає workflow BMAD.
- Вам потрібні сталі ідентифікатори вимог між інструментами, а не лише всередині файлів історій одного методу.
- Вам потрібен формат [з відкритим вихідним кодом](https://github.com/specscore/specscore), на який може націлитися інший процес.

## Метод може писати в цьому форматі.

BMAD відповідає на питання «як ми ведемо роботу». SpecScore відповідає на питання «який файл є контрактом і звідки CI знає, що він цілий». Команда може лишити PRD та історії BMAD для розмови, а фічу SpecScore — для вимог, які мають проходити лінт.

Використовуйте BMAD Method для циклу. Використовуйте SpecScore для артефакту, який перевіряє pull request.

## Джерела.

Публічні сторінки нижче прочитано 30 жовтня 2026 року. Ціни, назви тарифів і лінії релізів змінюються.

- [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)
- [BMAD-METHOD — ліцензія MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE)
- [Карта workflow BMAD (main, прочитана 30 жовтня 2026)](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/reference/workflow-map.md)
- [bmadcode.com](https://www.bmadcode.com/)
- [specscore/specscore — workflow CI dogfood](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)
- [specstudio-skills — навичка /score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md)
- [specscore/specscore — CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)
- [specscore/specscore-cli — Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)