# Найкращі інструменти розробки за специфікаціями у 2026 році

Canonical: https://specscore.md/uk/spec-driven-development/tools/

SpecScore — відкритий, лінтовний файловий формат для специфікацій, записаний у Markdown і YAML (YAML Ain't Markup Language). [Розробка за специфікаціями](https://specscore.md/uk/spec-driven-development/) (SDD) — це практика, за якої написана специфікація є джерелом істини, за яким будують код і щодо якого його перевіряють. Інструменти розробки за специфікаціями — це формати, робочі процеси й продукти, якими специфікації пишуть, зберігають і часом перевіряють. Документ вимог до продукту (PRD) — це проза, яка формулює проблему й обсяг до того, як хтось розіб’є її на задачі. [Легкий підхід до синтаксису вимог](https://kiro.dev/docs/specs/feature-specs/) (EARS) — це речення вимоги у формі «WHEN щось відбувається, THE SYSTEM SHALL зробити щось». [Інтерфейс командного рядка](https://specscore.md/uk/cli/) (CLI) — це програма, яку запускають у терміналі. [Безперервна інтеграція](https://specscore.md/uk/validators/) (CI) — це автоматична перевірка кожної запропонованої зміни.

Це порівняння інструментів розробки за специфікаціями охоплює [GitHub Spec Kit](https://github.com/github/spec-kit), [OpenSpec](https://github.com/Fission-AI/OpenSpec), [Kiro](https://kiro.dev/), [Tessl](https://docs.tessl.io/), [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD), [Task Master AI](https://github.com/eyaltoledano/claude-task-master), [CodeSpeak](https://codespeak.dev/), [Datarim](https://github.com/Arcanada-one/datarim), звичайний Markdown і [SpecScore](https://specscore.md/uk/). Публічні сторінки та репозиторії прочитано 30 жовтня 2026 року. Команди, розташування файлів і те, що перевіряє продукт, можуть змінитися; джерела внизу називають сторінку, з якої взято кожне твердження.

Для репозиторію вирішальне те, чи специфікація може сама провалити CI. У репозиторії сайту SpecScore [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) встановлює CLI SpecScore і запускає `specscore spec lint` на pull request і при push у main. Навичка [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) у specstudio-skills — це ручна оцінка ШІ артефакту. Викликаєте її ви. Цей робочий процес — ні.

## Інструменти розробки за специфікаціями, поруч.

Кожен рядок — це роль, а не бал. Назва веде до порівняння SpecScore, а заголовок нижче — до джерела комірки.

| Інструмент | Що це | Як специфікації пишуть і зберігають | Автоматична перевірка специфікації | Ліцензія | Кому підходить |
| --- | --- | --- | --- | --- | --- |
| [GitHub Spec Kit](https://specscore.md/uk/vs/spec-kit/) | Робочий процес агента, який створює артефакти Markdown | Каталог функції під `specs/`: `spec.md`, `plan.md`, `tasks.md` | `/speckit.analyze` повідомляє про прогалини між артефактами в сесії агента. Розширення спільноти можуть додати брами. | [MIT](https://github.com/github/spec-kit/blob/main/LICENSE) у [github/spec-kit](https://github.com/github/spec-kit) | Команда, якій потрібен один спільний процес для агента |
| [OpenSpec](https://specscore.md/uk/vs/openspec/) | Теки змін і команди агента, щоб домовитися до коду | Звичайний Markdown під `openspec/changes/`: proposal, specs, design, tasks | `openspec validate` перевіряє структуру зміни та специфікації і може завершитися ненульовим кодом, зокрема зі скрипту CI. | [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE) у [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) | Команда, якій потрібна легка тека зміни й перевірка структури |
| [Kiro](https://specscore.md/uk/vs/kiro/) | Агентні IDE, CLI і вебзастосунок AWS, які накидають специфікації | `requirements.md` в EARS, а також `design.md` і `tasks.md` | Analyze Requirements усередині Kiro, до проєктування. Сторінка специфікації функції описує цю перевірку в продукті. | IDE і CLI є матеріалами AWS (AWS Content) за [ліцензією Kiro](https://kiro.dev/license/) (AWS Customer Agreement). | Той, хто хоче, щоб Kiro накидав вимоги, дизайн і задачі |
| [Tessl](https://specscore.md/uk/vs/tessl/) | Платформа навичок агента і tile розробки за специфікаціями | Навички як файли в репозиторії. Tile пише `.spec.md` під `specs/`. | Tile постачає `scripts/validate-specs.sh` і `scripts/check-spec-links.sh`. Його GitHub Actions перевіряють лінтером сам tile. | Tile — [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE) у [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile). Платформа — продукт Tessl. | Команда, яка стандартизує навички агента або користується правилами tile «спочатку специфікація» |
| [BMAD Method](https://specscore.md/uk/vs/bmad-method/) | Гнучкий метод розробки, яку веде ШІ | Брифи, специфікації й архітектура, які можна перенести в інший робочий процес | README описує артефакти методу й робочі процеси агента. Лінтер формату для CI там не задокументовано. | [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), із повідомленням про торговельну марку в цьому файлі. | Команда, якій потрібен гнучкий агентний метод під розмір зміни |
| [Task Master AI](https://specscore.md/uk/vs/task-master-ai/) | Список задач для агентів кодування, розібраний із PRD | Проза PRD, часто `.taskmaster/docs/prd.txt`, далі згенеровані задачі | README описує розбір PRD на задачі. Лінтер для PRD там не описано. | [MIT із Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE) у [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) | Команда, яка вже має PRD і хоче розбити його на задачі |
| [CodeSpeak](https://specscore.md/uk/vs/codespeak/) | Агентний набір, який перетворює намір із чату на вимоги, зіставлені з кодом | Структуровані вимоги всередині продукту, зіставлені з кодом | Сайт каже, що вимоги застосовують при кожній зміні, всередині продукту. | [Умови використання](https://codespeak.dev/terms-of-service) (чинні з 3 березня 2026 року): CodeSpeak Ltd залишає за собою Сервіс, включно з його вихідним кодом. Сайт продукту не публікує репозиторій вихідного коду набору. | Команда, яка хоче знімати намір із чатів і тримати його зіставленим із кодом |
| [Datarim](https://specscore.md/uk/vs/datarim/) | Ітеративний робочий процес для Claude Code, Codex CLI, Cursor і Antigravity | `/dr-prd` записує PRD. Активні задачі лежать у `backlog.md`. | `/dr-compliance` і `/dr-dream lint` виконуються, коли ви викликаєте ці команди. | [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE) у [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim) | Команда, якій потрібні поетапні команди й беклог у репозиторії |
| [Plain Markdown](https://specscore.md/uk/vs/plain-markdown/) | Звичайний файл Markdown, який ви пишете й комітите | Будь-який файл `.md`, у каталозі, який ви оберете | Той перегляд, який ви зробите читанням, доки не додасте програму перевірки | Немає продукту й немає файлу ліцензії. Умови файлу — це умови репозиторію. | Коротка нотатка, спайк або перегляд, який ви зробите читанням |
| [SpecScore](https://specscore.md/uk/) | Відкритий формат специфікації та CLI, який лінтить файли | Markdown + YAML у дереві `spec/` | [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) запускає `specscore spec lint` на pull request і при push у main. [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) — ручна оцінка ШІ, і цей робочий процес її не запускає. | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) на формат у [specscore/specscore](https://github.com/specscore/specscore). [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) на CLI у [specscore/specscore-cli](https://github.com/specscore/specscore-cli). | Команда, якій потрібно, щоб файл специфікації провалював CI, коли ламається формат |

## GitHub Spec Kit

[GitHub Spec Kit](https://github.github.io/spec-kit/) — це відкритий набір інструментів, який задає агенту кодування процес: Specify, Plan, Tasks, Implement і Converge. Домівка документації Spec Kit, датована 28 вересня 2026 року, каже, що кожна фаза створює артефакт Markdown, який читає наступна фаза.

Ці файли лежать у каталозі функції під `specs/`. [Посібник з оновлення](https://github.github.io/spec-kit/upgrade.html), прочитаний 30 жовтня 2026 року, наводить шляхи на кшталт `specs/001-my-feature/spec.md`, а поруч `plan.md` і `tasks.md`. [Довідка з агентного SDD](https://github.github.io/spec-kit/reference/agentic-sdd.html) описує `/speckit.analyze` як звіт про неузгодженості між специфікацією, планом і задачами, без редагування файлів. `/speckit.clarify` і `/speckit.checklist` — це подальші команди, які ви запускаєте в агенті. Домівка документації також називає розширення спільноти, зокрема одне на ім’я CI Guard, які додають брами відповідності.

Ліцензія — [MIT](https://github.com/github/spec-kit/blob/main/LICENSE), у публічному репозиторії [github/spec-kit](https://github.com/github/spec-kit). Spec Kit пасує команді, яка хоче цей процес і згодна лишити специфікацію тим Markdown, який написав агент. Зіставлення зі SpecScore — на [SpecScore vs Spec Kit](https://specscore.md/uk/vs/spec-kit/).

## OpenSpec

[OpenSpec](https://github.com/Fission-AI/OpenSpec) від Fission-AI тримає кожну зміну у власній теці, щоб людина й агент могли домовитися до того, як буде написано код. [README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md), прочитаний 30 жовтня 2026 року, показує `openspec/changes/add-dark-mode/` із `proposal.md`, каталогом `specs/`, `design.md` і `tasks.md`. Вимоги — це звичайний Markdown: твердження SHALL і сценарій WHEN / THEN. Той самий README каже, що є підтримка 30+ ШІ-асистентів.

`openspec validate` перевіряє зміни та специфікації на структурні проблеми. [Довідка з CLI](https://openspec.dev/docs/cli), прочитана 30 жовтня 2026 року, документує ненульовий код виходу, коли перевірка не пройшла, і фрагмент shell, який може запустити завдання CI. Ця перевірка — структура змін і специфікацій OpenSpec.

Ліцензія — [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE), у [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec). OpenSpec пасує команді, якій потрібні тека зміни й ця перевірка структури. Див. [SpecScore vs OpenSpec](https://specscore.md/uk/vs/openspec/).

## Kiro

[Kiro](https://kiro.dev/) від Amazon Web Services (AWS) — це агентне середовище розробки: редактор, CLI і вебзастосунок. [Сторінка специфікацій функцій](https://kiro.dev/docs/specs/feature-specs/), оновлена 4 серпня 2026 року, проводить функцію крізь вимоги, дизайн і задачі. `requirements.md` використовує EARS. `design.md` і `tasks.md` лежать поруч. Quick Spec може виконати всі три без зупинки на погодження між ними.

Analyze Requirements шукає неузгодженості, двозначність, суперечливі обмеження й прогалини до проєктування. Цей розбір виконується всередині Kiro. Сторінка специфікації функції описує перевірку в продукті.

[Ліцензія Kiro](https://kiro.dev/license/), прочитана 30 жовтня 2026 року, каже, що IDE і CLI ліцензовано як матеріали AWS (AWS Content) за клієнтською угодою AWS (AWS Customer Agreement) або іншою письмовою угодою, а також AWS Intellectual Property License. Kiro пасує тому, хто хоче, щоб цей продукт накидав три файли. Див. [SpecScore vs Kiro](https://specscore.md/uk/vs/kiro/). Шаблони речень розібрано в [синтаксисі вимог EARS](https://specscore.md/uk/articles/ears-requirements/).

## Tessl

[Документація Tessl](https://docs.tessl.io/), прочитана 30 жовтня 2026 року, описує відкриту платформу для керування навичками агента: реєстр, керування, оцінювання і пов’язані засоби контролю. Навички, правила й документи — це файли в репозиторії.

Окремий артефакт, tile розробки за специфікаціями, публікують із [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile) і наводять у [реєстрі Tessl](https://tessl.io/registry/tessl-labs/spec-driven-development). README tile каже, що агент пише файли `.spec.md` у каталозі `specs/`, з YAML-frontmatter, `targets` і посиланнями `[@test]`. Там задокументовано `scripts/validate-specs.sh` і `scripts/check-spec-links.sh`, а також GitHub Actions, які перевіряють лінтером сам tile.

Ліцензія tile — [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE), у тому репозиторії. Документація описує платформу реєстру як продукт Tessl і не вказує публічний репозиторій усієї платформи. Tessl пасує команді, яка стандартизує навички, або команді, якій потрібне керування tile «спочатку специфікація, потім код». Див. [SpecScore vs Tessl](https://specscore.md/uk/vs/tessl/).

## BMAD Method

README репозиторію [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD), прочитаний 30 жовтня 2026 року, описує гнучкий метод розробки, яку веде ШІ. Там сказано, що метод можна пройти від початку до кінця або перенести його брифи, специфікації й архітектуру в робочий процес, який у вас уже є. Названа там стабільна лінія — v6.12. v7 описано як попередній перегляд на гілці main. Проєкт пише ім’я як BMad; репозиторій називається BMAD-METHOD.

README зосереджено на цих артефактах планування і на навичках агента, які їх створюють. Там не задокументовано команду, яка лінтить фіксовану схему специфікації в CI.

Ліцензія — [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). У тому файлі ліцензії є й повідомлення про торговельну марку BMad. Метод пасує команді, якій потрібен гнучкий цикл і яка лишить специфікацію в цих брифах і специфікаціях. Див. [SpecScore vs the BMAD Method](https://specscore.md/uk/vs/bmad-method/).

## Task Master AI

[Task Master AI](https://github.com/eyaltoledano/claude-task-master) — це список задач для ШІ-агентів, які пишуть код. README, прочитаний 30 жовтня 2026 року, рекомендує PRD, часто за шляхом `.taskmaster/docs/prd.txt`, і `task-master parse-prd`, щоб перетворити цю прозу на задачі. [Документація](https://tryhamster.com/docs/taskmaster) описує структуру задач, залежності й теги.

README вважає PRD входом, а список задач — тим, із чого працює агент. Лінтер формулювань або структури PRD там не описано.

Ліцензія — [MIT із Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE), у [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master). README каже, що з Task Master можна створювати продукти і що продаж самого Task Master або пропонування його як розміщеного сервісу виходить за межі цього надання. Пасує команді, яка хоче розбити PRD на задачі. Див. [SpecScore vs Task Master AI](https://specscore.md/uk/vs/task-master-ai/).

## CodeSpeak

Сайт [CodeSpeak](https://codespeak.dev/), прочитаний 30 жовтня 2026 року, описує агентний інженерний набір. Він знімає намір із чатів агента, перетворює цей намір на структуровані вимоги, зіставлені з кодом, і каже, що застосовує ці вимоги при кожній зміні. Сайт також каже, що вебінструмент відновлює намір із чатів, доки не вийде повний продукт.

[Умови використання](https://codespeak.dev/terms-of-service), чинні з 3 березня 2026 року, стверджують, що CodeSpeak Ltd залишає за собою Сервіс, включно з його програмним забезпеченням і вихідним кодом. Сайт продукту не публікує репозиторій вихідного коду цього набору, тож ця сторінка не називає для нього ліцензію на програмне забезпечення.

CodeSpeak пасує команді, яка хоче вимоги, зняті з розмови й збережені у зіставленні з кодом усередині цього продукту. Див. [SpecScore vs CodeSpeak](https://specscore.md/uk/vs/codespeak/).

## Datarim

README [Datarim](https://github.com/Arcanada-one/datarim) зі значком версії 4.9.0, прочитаний 30 жовтня 2026 року, описує ітеративний робочий процес для Claude Code, Codex CLI, Cursor і Google Antigravity. `/dr-prd` генерує PRD. Активні задачі лежать у `backlog.md`, а завершена історія — в `backlog-archive.md`.

`/dr-compliance` звіряє реалізацію з PRD, коли ви запускаєте цю команду. `/dr-dream lint` перевіряє базу знань на суперечності, сироти, зламані посилання, застарілий вміст і дублікати. Це команди робочого процесу.

Ліцензія — [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE), у [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim). Datarim пасує команді, якій потрібні ці поетапні команди на агентах, названих у README. Див. [SpecScore vs Datarim](https://specscore.md/uk/vs/datarim/).

## Plain Markdown

Звичайний Markdown — це специфікація як звичайний файл `.md`: заголовок, кілька пунктів, там, куди ви його комітите. Схеми немає. Перегляд — це хтось, хто читає файл, доки ви не додасте власну програму перевірки.

Немає продукту й немає файлу ліцензії, на який можна послатися. Умови файлу — та ліцензія, яку ви застосовуєте до репозиторію. Звичайний Markdown пасує для короткої нотатки, спайка або команди, яка перегляне прозу читанням. Див. [SpecScore vs plain Markdown](https://specscore.md/uk/vs/plain-markdown/).

## SpecScore

[SpecScore](https://specscore.md/uk/) — формат специфікації: функції, вимоги та критерії приймання як Markdown із YAML — і CLI, який перевіряє файли. Формат лежить у [specscore/specscore](https://github.com/specscore/specscore). CLI лежить у [specscore/specscore-cli](https://github.com/specscore/specscore-cli).

Як писати критерії, щоб агент міг їх перевірити, — у статті [як писати критерії приймання](https://specscore.md/uk/articles/acceptance-criteria/).

Шаблон специфікації функції в Markdown — вимоги, критерії приймання, план і завдання — у статті [шаблон PRD у Markdown](https://specscore.md/uk/articles/feature-spec-template/).

Розробка за специфікаціями з Claude Code і Cursor — файл функції, файл інструкцій агента і `specscore spec lint` у циклі описані у статті [розробка за специфікаціями з Claude Code і Cursor](https://specscore.md/uk/articles/claude-code-specs/).

Як запускати цей лінтер у безперервній інтеграції, описано в статті [лінтинг специфікацій у CI](https://specscore.md/uk/articles/lint-specs-in-ci/).

У репозиторії цього сайту [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) встановлює цей CLI і запускає `specscore spec lint` на pull request і при push у main. Специфікація, яка ламає формат, провалює це завдання. Навичка [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) — ручна оцінка ШІ: вона наново запускає налаштованих рецензентів, коли ви просите, і робочий процес dogfood її не викликає.

Ліцензія формату — [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). SpecScore пасує команді, якій потрібно, щоб специфікація провалювала CI, коли хибні заголовок, посилання або статус, хоч який агент написав файл. `openspec validate` — найближча структурна перевірка серед решти інструментів на цій сторінці; вона перевіряє власну форму зміни OpenSpec. Окремі порівняння починаються з [/vs/](https://specscore.md/uk/vs/).

## Як обрати.

Оберіть GitHub Spec Kit, OpenSpec, BMAD Method або Datarim, коли потрібен керований процес і Markdown, який можна переглянути в pull request. Оберіть Kiro, коли цей продукт має накидати вимоги EARS. Оберіть Task Master AI, коли PRD має стати списком задач. Оберіть CodeSpeak, коли намір треба знімати з чатів усередині цього продукту. Оберіть Tessl, коли йдеться про навички агента, а tile специфікації — необов’язкове керування.

Оберіть SpecScore, коли сам файл специфікації має провалювати CI. Перевірка в цьому репозиторії — `specscore spec lint` у [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). Робочий процес зі списку вище й далі може бути тим, як специфікацію пишуть.

## Джерела.

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

- [Документація GitHub Spec Kit (сторінка датована 28 вересня 2026 року)](https://github.github.io/spec-kit/)
- [Spec Kit — довідка з агентного SDD](https://github.github.io/spec-kit/reference/agentic-sdd.html)
- [Spec Kit — посібник з оновлення (шляхи specs/)](https://github.github.io/spec-kit/upgrade.html)
- [github/spec-kit — ліцензія MIT](https://github.com/github/spec-kit/blob/main/LICENSE)
- [Fission-AI/OpenSpec — README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md)
- [Довідка з CLI OpenSpec — openspec validate](https://openspec.dev/docs/cli)
- [Fission-AI/OpenSpec — ліцензія MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)
- [Документація Kiro — специфікації функцій і EARS (оновлено 4 серпня 2026 року)](https://kiro.dev/docs/specs/feature-specs/)
- [Kiro — ліцензія](https://kiro.dev/license/)
- [Документація Tessl — що таке Tessl?](https://docs.tessl.io/)
- [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)
- [Tile розробки за специфікаціями Tessl — ліцензія MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE)
- [bmad-code-org/BMAD-METHOD — README](https://github.com/bmad-code-org/BMAD-METHOD)
- [BMAD-METHOD — ліцензія MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE)
- [eyaltoledano/claude-task-master — README](https://github.com/eyaltoledano/claude-task-master)
- [Task Master — MIT із Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)
- [CodeSpeak](https://codespeak.dev/)
- [CodeSpeak — умови використання (чинні з 3 березня 2026 року)](https://codespeak.dev/terms-of-service)
- [Arcanada-one/datarim — README (значок 4.9.0)](https://github.com/Arcanada-one/datarim)
- [Datarim — ліцензія MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE)
- [specscore/specscore — dogfood.yml (specscore spec lint)](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)