# SpecScore vs BMAD Method

Canonical: https://specscore.md/ru/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/ru/spec-driven-development/) (SDD) — более широкая идея, внутри которой находятся оба: поведение задают до кода. [SpecScore](https://specscore.md/ru/) — это формат [с открытым исходным кодом](https://github.com/specscore/specscore) для этой спецификации плюс [интерфейс командной строки](https://specscore.md/ru/cli/) (CLI). [Непрерывная интеграция](https://specscore.md/ru/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)