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 с другим инструментом? запросите его.