SpecScore vs Kiro
Розробка на основі специфікацій (SDD) означає, що те, що програма має робити, записують до того, як ШІ-агент напише код. Kiro від Amazon Web Services (AWS) — це агентне середовище розробки — редактор, інтерфейс командного рядка (CLI) і вебзастосунок, — яке перетворює промпт на специфікації Kiro: вимоги, дизайн і завдання. Ці вимоги використовують EARS (простий підхід до синтаксису вимог), речення вигляду «WHEN щось відбувається, THE SYSTEM SHALL щось зробити». SpecScore — це формат з відкритим вихідним кодом для самої специфікації плюс CLI, який перевіряє файли. Безперервна інтеграція (CI) — автоматична перевірка кожної запропонованої зміни — може відхилити специфікацію 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 |
| Перевірка специфікації | Analyze Requirements в IDE і CLI. Тести на основі властивостей в IDE. Не описано як лінтер формату для вашої власної CI. | specscore spec lint у CI. /score — окрема ручна оцінка ШІ. |
| Де виконується | Kiro IDE, Kiro CLI, Kiro web. Частина перевірок лише в IDE. | Будь-який репозиторій — один бінарник Go, без облікового запису Kiro |
| Ліцензія | Ліцензія Kiro каже, що IDE і CLI є матеріалами AWS (AWS Content) за клієнтською угодою AWS (AWS Customer Agreement). Kiro Crew — окремий публічний репозиторій. | CC BY 4.0 формат · Apache-2.0 CLI |
| Ціна | Безкоштовний рівень і платні плани. Цифри змінюються — див. ціни Kiro, прочитані 30 жовтня 2026. | Без плати за формат і за CLI |
Що додає SpecScore.
Формат сам падає в CI
Аналіз Kiro виконується всередині Kiro. Перевірка SpecScore — це команда. Workflow dogfood цього репозиторію запускає specscore spec lint на кожному pull request і в main. Зламана специфікація провалює завдання так само, як провалив би зламаний тест. Навичка /score оцінює формулювання ШІ-рев’юерами; цей прохід ручний, і 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.
Коли який використовувати.
Беріть Kiro, коли…
- Вам потрібна агентна IDE від AWS, яка за промптом накидає вимоги, дизайн і завдання, а потім виконує завдання.
- Вам потрібні речення EARS і, в IDE, тести на основі властивостей, породжені з них.
- Ваша команда вже стандартизує редактор, CLI або вебзастосунок Kiro.
Використовуйте SpecScore, коли…
- Специфікація має лишатися правильною в CI після кінця сесії агента, у репозиторії, якому не потрібен Kiro.
- Вам потрібні ідентифікатори вимог, статус життєвого циклу і детермінований результат лінта.
- Ви хочете формат з відкритим вихідним кодом, а програму перевірки — одним бінарним файлом.
Kiro може накидати. SpecScore може відсікти.
Ніщо тут не замінює редактор Kiro. Якщо команда пише промпти в Kiro, хай він накидає. Якщо специфікація має пережити сесію як перевірений файл, запишіть цей контракт у SpecScore і дозвольте specscore spec lint провалити pull request, коли ламається структура. Ці два файли можуть лежати в одному репозиторії.
Оберіть Kiro для сесії. Оберіть SpecScore для артефакту, який завдання CI може відхилити.
Джерела.
Публічні сторінки нижче прочитано 30 жовтня 2026 року. Ціни, назви тарифів і лінії релізів змінюються.
Інші порівняння.
Той самий формат поруч з іншими інструментами розробки за специфікаціями:
Усі разом, на одній сторінці: найкращі інструменти розробки за специфікаціями у 2026 році.
Зворотний зв'язок
Це порівняння базується на публічно доступній документації та вихідному коді. Щось невірно або застаріло? відкрийте issue з виправленням. Хочете, щоб ми порівняли SpecScore з іншим інструментом? запросіть його.