# SpecScore vs Tessl Canonical: https://specscore.md/uk/vs/tessl/ [Розробка на основі специфікацій](https://specscore.md/uk/spec-driven-development/) (SDD) означає, що специфікацію задуманої поведінки написано до коду. [Tessl](https://tessl.io/) (Tessl AI Ltd) станом на 30 жовтня 2026 — платформа оснащення агентів: реєстр і контур керування для навичок, правил і плагінів, які завантажують агенти для коду. «Специфікація як джерело» — сильніше твердження в [есеї Tessl від червня 2025](https://tessl.io/blog/from-code-centric-to-spec-centric): специфікація — довговічний артефакт, а код виводиться з неї. [SpecScore](https://specscore.md/uk/) — це формат файлу [з відкритим вихідним кодом](https://github.com/specscore/specscore) для цієї специфікації, який перевіряє [інтерфейс командного рядка](https://specscore.md/uk/cli/) (CLI). [Безперервна інтеграція](https://specscore.md/uk/validators/) (CI) — автоматична перевірка кожної запропонованої зміни — запускає цю перевірку в цьому репозиторії. ## Що в них спільного. - Обидва кажуть, що промпт — слабке місце для зберігання наміру. Написана специфікація має пережити чат. - Обидва очікують, що ШІ-агент для коду прочитає специфікацію, перш ніж правити код. - Обидва можуть прикріпити тести до вимог, тож «готово» — це те, на що можна вказати. ## Що Tessl робить добре. Дві різні поверхні Tessl легко сплутати. Нотатки нижче тримають їх окремо, за сторінками, прочитаними 30 жовтня 2026. ### Ясний довід на користь специфікації як джерела Есей Simon Maple від 27 червня 2025 каже, що документ вимог до продукту (PRD) — проза для людей про те, що будувати, — зазвичай застаріває, а код стає єдиним джерелом істини. Альтернатива есею в тому, що змінюють специфікацію, а LLM породжує з неї код, тести й документацію. Це справжня позиція, а не гасло. ### Платформа контексту для агента [Документація Tessl](https://docs.tessl.io/) описує реєстр, керування, яке сканує й оцінює навички, оцінювання і спостережуваність між агентами. Документація каже, що навички — звичайні артефакти у вашому репозиторії і що платформа працює з Claude Code, Cursor, Copilot, Gemini та іншими. Оцінювання там означає оцінювання навички, а не оцінювання специфікації продукту. ### Офіційний tile розробки на основі специфікацій із перевірками в shell Tile [tessl-labs/spec-driven-development](https://tessl.io/registry/tessl-labs/spec-driven-development) за ліцензією MIT у [публічному репозиторії tile](https://github.com/tesslio/spec-driven-development-tile) вчить агента провести інтерв’ю, написати файли `.spec.md`, дочекатися схвалення, потім реалізувати. Сторінка реєстру перелічує `scripts/validate-specs.sh` і `scripts/check-spec-links.sh` для frontmatter, `targets` і посилань `[@test]`. Та сама сторінка каже, що tile — це керувальний контекст: жодних особливих команд, жодного фреймворку. ## Порівняння функцій. «Специфікація як джерело» — есей Tessl. Tile — пакет навичок поверх сьогоднішньої платформи. SpecScore — формат із версійованим лінтером. | Можливість | Tessl | SpecScore | | --- | --- | --- | | Основна роль | Платформа навичок для агентів, плюс tile розробки на основі специфікацій і есей 2025 року про специфікацію як джерело | **Відкритий формат специфікацій + CLI** | | Чим є специфікація | Есей: довговічне джерело, з якого породжують код. Tile: .spec.md, за яким агент реалізує, а код лишається у вас. | **Контракт поруч із кодом**. Лінт не перегенеровує код. | | Форма специфікації | Tile: YAML-frontmatter, glob-шаблони targets і посилання [@test] на файли тестів | **Markdown + YAML**, `REQ: slug`, [Given/When/Then](https://specscore.md/acceptance-criteria-specification) | | Перевірка специфікації | Shell-скрипти в комплекті tile, для frontmatter і посилань цього tile | **specscore spec lint** за форматом SpecScore, у CI цього репозиторію. `/score` — ручна оцінка ШІ. | | Ліцензія | Tile випущено під [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE). Платформа — продукт. Документація не публікує вихідний код платформи. | [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 | | Ціна | [Головна сторінка Tessl](https://tessl.io/), прочитана 30 жовтня 2026, описує безкоштовний рівень (1000 кредитів на місяць на один робочий простір) і платні корпоративні плани. | **Без плати** за формат і за CLI | ## Що додає SpecScore. ### Опублікований формат, а не скрипт tile Shell-скрипти tile перевіряють файли `.spec.md`, які цей tile просив агента написати. SpecScore перевіряє формат, описаний на цьому сайті. [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) встановлює закріплений реліз [specscore](https://github.com/specscore/specscore-cli) і запускає `specscore spec lint`. [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) — не це завдання: це ручна навичка, яка завершується з ненульовим кодом, коли ШІ-рев’юери повідомляють про проблеми. ``` $ 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) ``` ### Код лишається у вас в обох випадках — есей іде далі Есей 2025 року каже, що код слід перегенеровувати зі специфікації. Tile на сторінці, прочитаній 30 жовтня 2026, змушує агента реалізовувати за схваленою специфікацією і не описує компілятор, який замінює ваше дерево вихідного коду. SpecScore ніколи не забирає код. Специфікація — перевірений контракт; код лишається вашим. ### Тотожність вимоги Tile вказує вимогу на файли через `targets` і `[@test]`. SpecScore іменує вимогу `REQ: slug`, щоб план, завдання і трейлер коміту могли послатися на неї після того, як файли перемістяться. ## Коли який використовувати. ### Беріть Tessl, коли… - Вам потрібні реєстр, оцінювання і керування навичками, спільними для багатьох агентів і репозиторіїв. - Вам потрібен хід роботи з есею про специфікацію як джерело у вигляді керувального tile: інтерв’ю, схвалення .spec.md, потім реалізація. - Ви вже платите за платформу Tessl або пробуєте її і хочете її tile специфікації в цьому реєстрі. ### Використовуйте SpecScore, коли… - Сам формат специфікації має бути правильним у CI, зокрема в репозиторіях, де Tessl не встановлено. - Вам потрібні ідентифікатори вимог і лінтер, який не викликає модель. - Вам потрібен формат [з відкритим вихідним кодом](https://github.com/specscore/specscore) за ліцензією Creative Commons, окремо від платформи навичок. ## Специфікація як джерело і специфікація, яку можна лінтити. Есей Tessl має рацію в тому, що застарілий PRD програє коду. Перевірка формату — це те, завдяки чому специфікація лишається тим, чому ви довіряєте. SpecScore не породжує ваш застосунок зі специфікації. Він змушує специфікацію падати в CI, коли хибні структура, посилання або статус. Використовуйте Tessl, якщо потрібні платформа і tile. Використовуйте SpecScore, якщо артефакт у git — це те, що має довести pull request. ## Джерела. Публічні сторінки нижче прочитано 30 жовтня 2026 року. Ціни, назви тарифів і лінії релізів змінюються. - [Документація Tessl — що таке Tessl?](https://docs.tessl.io/) - [Головна сторінка Tessl](https://tessl.io/) - [Блог Tessl — чому самого коду недостатньо (27 червня 2025)](https://tessl.io/blog/from-code-centric-to-spec-centric) - [Реєстр Tessl — tessl-labs/spec-driven-development](https://tessl.io/registry/tessl-labs/spec-driven-development) - [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile) - [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)