# SpecScore vs Kiro Canonical: https://specscore.md/uk/vs/kiro/ [Розробка на основі специфікацій](https://specscore.md/uk/spec-driven-development/) (SDD) означає, що те, що програма має робити, записують до того, як ШІ-агент напише код. [Kiro](https://kiro.dev/) від Amazon Web Services (AWS) — це агентне середовище розробки — редактор, [інтерфейс командного рядка](https://specscore.md/uk/cli/) (CLI) і вебзастосунок, — яке перетворює промпт на специфікації Kiro: вимоги, дизайн і завдання. Ці вимоги використовують [EARS](https://kiro.dev/docs/specs/feature-specs/) (простий підхід до синтаксису вимог), речення вигляду «WHEN щось відбувається, THE SYSTEM SHALL щось зробити». [SpecScore](https://specscore.md/uk/) — це формат [з відкритим вихідним кодом](https://github.com/specscore/specscore) для самої специфікації плюс CLI, який перевіряє файли. [Безперервна інтеграція](https://specscore.md/uk/validators/) (CI) — автоматична перевірка кожної запропонованої зміни — може відхилити специфікацію SpecScore, яка порушує формат. ## Що в них спільного. - Обидва вважають написану специфікацію тим, з чого агент має будувати, а не стенограмою чату. - Обидва зберігають цю специфікацію як Markdown у проєкті, щоб її можна було рецензувати як код. - Обидва ділять роботу на вимоги, дизайн і завдання. Kiro породжує ці три файли. SpecScore — формат, який команда може зберегти після завершення сесії. ## Що Kiro робить добре. Власна документація Kiro, прочитана 30 жовтня 2026, описує продукт. Сторінку специфікації функції було позначено як оновлену 4 серпня 2026. ### Вимоги у фіксованій формі речення Специфікації Kiro вміщують поведінку в `requirements.md` за одним шаблоном EARS: WHEN умова виконується, THE SYSTEM SHALL зробити щось. Документація наводить приклад форми з невірними даними, а система показує помилку перевірки поруч із полем. Таку форму легше тестувати, ніж розпливчастий абзац. ### Повний шлях від промпта до завдань Специфікація функції проходить через вимоги, дизайн (`design.md`) і завдання (`tasks.md`). Можна почати з вимог або з дизайну. Quick Spec запускає всі три без зупинки на затвердження між ними. Специфікації Bugfix — окремий шлях. Документація також описує запуск незалежних завдань паралельно, хвилями, за графом залежностей у `tasks.md`. ### Перевірки всередині продукту Analyze Requirements, доступний в IDE і в CLI, шукає неузгодженості, неоднозначність, суперечливі обмеження і прогалини до дизайну. Correctness — тести на основі властивостей, виведені з цих рядків EARS, — зазначений лише для IDE, не для CLI, web чи mobile, у таблиці можливостей специфікацій. ## Порівняння функцій. Kiro — продукт, який накидає специфікації. SpecScore — формат, який репозиторій може перевірити. Таблиця порівнює ці ролі. | Можливість | Kiro | SpecScore | | --- | --- | --- | | Основна роль | Агентна IDE, CLI і вебзастосунок, які накидають специфікації й виконують завдання | **Відкритий формат специфікацій + CLI** | | Файли специфікації | `requirements.md` (або `bugfix.md`), `design.md`, `tasks.md` | **Дерево spec/** із Markdown + YAML | | Синтаксис вимог | Шаблон EARS: WHEN … THE SYSTEM SHALL … | **Ідентифікатори вимог** (`REQ: slug`) і критерії приймання [Given/When/Then](https://specscore.md/acceptance-criteria-specification) | | Перевірка специфікації | Analyze Requirements в IDE і CLI. Тести на основі властивостей в IDE. Не описано як лінтер формату для вашої власної CI. | **specscore spec lint** у CI. `/score` — окрема ручна оцінка ШІ. | | Де виконується | Kiro IDE, Kiro CLI, Kiro web. Частина перевірок лише в IDE. | **Будь-який репозиторій** — один бінарник Go, без облікового запису Kiro | | Ліцензія | [Ліцензія Kiro](https://kiro.dev/license/) каже, що IDE і CLI є матеріалами AWS (AWS Content) за клієнтською угодою AWS (AWS Customer Agreement). Kiro Crew — окремий [публічний репозиторій](https://github.com/kirodotdev/KiroCrew). | [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 | | Ціна | Безкоштовний рівень і платні плани. Цифри змінюються — див. [ціни Kiro](https://kiro.dev/pricing/), прочитані 30 жовтня 2026. | **Без плати** за формат і за CLI | ## Що додає SpecScore. ### Формат сам падає в CI Аналіз Kiro виконується всередині Kiro. Перевірка SpecScore — це команда. [Workflow dogfood](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) цього репозиторію запускає `specscore spec lint` на кожному pull request і в main. Зламана специфікація провалює завдання так само, як провалив би зламаний тест. Навичка [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) оцінює формулювання ШІ-рев’юерами; цей прохід ручний, і workflow вище його не запускає. ``` $ 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) ``` ### Специфікація не прив’язана до однієї IDE Специфікації Kiro — це Markdown, тож їх можна читати без продукту. Workflow, який їх створює і виконує, належить Kiro. Дерево SpecScore — ті самі файли для Claude Code, Cursor, Copilot або взагалі без агента: CLI не викликає модель, щоб лінтити. ### У вимог лишається ідентифікатор Документація Kiro описує простежуваність як проходження вимоги крізь реалізацію. Вона не описує сталий ідентифікатор, який переживе переписування. SpecScore адресує вимогу як `REQ: slug`, а критерій приймання — його власним ідентифікатором. ### EARS і Given/When/Then відповідають на різні питання EARS, як його документує Kiro, — це одне речення про поведінку системи. Критерії приймання SpecScore — сценарії Given/When/Then, прив’язані до ідентифікатора вимоги. Рядок EARS можна написати в прозі й усе одно тримати сценарій у файлі SpecScore, який перевіряє лінтер. Шаблони речень розібрано в [синтаксисі вимог EARS](https://specscore.md/articles/ears-requirements/). ## Коли який використовувати. ### Беріть Kiro, коли… - Вам потрібна агентна IDE від AWS, яка за промптом накидає вимоги, дизайн і завдання, а потім виконує завдання. - Вам потрібні речення EARS і, в IDE, тести на основі властивостей, породжені з них. - Ваша команда вже стандартизує редактор, CLI або вебзастосунок Kiro. ### Використовуйте SpecScore, коли… - Специфікація має лишатися правильною в CI після кінця сесії агента, у репозиторії, якому не потрібен Kiro. - Вам потрібні ідентифікатори вимог, статус життєвого циклу і детермінований результат лінта. - Ви хочете формат [з відкритим вихідним кодом](https://github.com/specscore/specscore), а програму перевірки — одним бінарним файлом. ## Kiro може накидати. SpecScore може відсікти. Ніщо тут не замінює редактор Kiro. Якщо команда пише промпти в Kiro, хай він накидає. Якщо специфікація має пережити сесію як перевірений файл, запишіть цей контракт у SpecScore і дозвольте `specscore spec lint` провалити pull request, коли ламається структура. Ці два файли можуть лежати в одному репозиторії. Оберіть Kiro для сесії. Оберіть SpecScore для артефакту, який завдання CI може відхилити. ## Джерела. Публічні сторінки нижче прочитано 30 жовтня 2026 року. Ціни, назви тарифів і лінії релізів змінюються. - [Документація Kiro — специфікації](https://kiro.dev/docs/specs/) - [Документація Kiro — специфікації функцій і EARS](https://kiro.dev/docs/specs/feature-specs/) - [Kiro — про продукт](https://kiro.dev/about/) - [Kiro — ліцензія](https://kiro.dev/license/) - [Kiro — ціни](https://kiro.dev/pricing/) - [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)