acai.sh

Open source набор инструментов для spec-driven разработки с участием ИИ, построенный вокруг спецификаций feature.yaml и ACID (Acceptance Criteria IDs). Аргументация автора о том, зачем это нужно и чем проект отличается от смежных инструментов спецификации, изложена в заметке specsmaxxing.

Суть в одной строке: хватит просить агента помнить от сессии к сессии, что должна делать разрабатываемая функциональность; напишите один раз нумерованный список критериев приёмки, пусть агент ссылается на эти номера из кода и тестов, и рецензируйте требования, а не файлы.

Компоненты

Организация публикует три репозитория:

acai-sh/cli - TypeScript CLI, распространяемый через npx @acai.sh/cli и релизы GitHub для Linux/macOS. Apache-2.0, ~10★, создан 2026-03-22.
acai-sh/server - бэкенд на Elixir/Phoenix/Postgres для self-hosted запуска, включающий дашборд, REST API, базу данных, сервис резервного копирования и reverse proxy. Apache-2.0, ~3★, создан 2026-02-27.
acai-sh/docs - сайт документации на базе Mintlify по адресу acai.sh.

Есть и хостинговая версия на app.acai.sh - автор пишет "бесплатно на какое-то время или навсегда", в зависимости от расходов на эксплуатацию. Разделение на hosted и self-hosted традиционное: код - OSS, хостинг - услуга.

Как всё устроено

feature.yaml  →  agent reads via `npx @acai.sh/cli skill`  →  agent writes code with `// AUTH-1` etc.
       │
       └────  `acai push --all` from CI  →  app.acai.sh dashboard with requirement-by-requirement review surface

Подкоманда CLI skill обучает агента соглашению: достаточно установить её один раз на проект, и агент научится читать feature.yaml, писать код со ссылками на ACID и отдавать статусы выполнения или блокировки. Дашборд нужен потому, что рецензирование требований устроено иначе, чем просмотр diff'ов: удобнее видеть список вроде "AUTH-2-1: завершено, назначено на claude-code, ожидает проверки", а не PR на 600 строк.

Целевое состояние - цикл plan -> implement -> review, где LLM выступает исполнителем, а человек проверяет результат на уровне требований. Примеры CI-хуков и интеграция цикла на момент этого ingest'а запланированы в roadmap.

Формат feature.yaml

feature:
    name: imaginary-api-endpoint
    product: api
    description: ...

components:
    AUTH:
      name: Authn and Authz
      requirements:
        1: Accepts Authorization header with `Bearer <token>`
        1-1: Token must be non-expired, non-revoked
        2: Respects the scopes configured for the owner
        2-note: See `access-tokens.SCOPES.1` for complete list of supported scopes

constraints:
    ENG:
      requirements:
        1: All actions are idempotent
        2: All HTTP 2xx JSON responses wrap their payload in a root `data` key

Разделение на components (функциональные требования, сгруппированные по зонам) и constraints (сквозные инженерные инварианты) - главное авторское решение формата. Иерархическая нумерация (2-1) даёт подтребованиям конкретный адрес. Соседние ключи *-note содержат перекрёстные ссылки. Флаги deprecated и replaced_by служат для сохранения истории прямо в спецификации, когда стабильная нумерация требует переименования.

Как автор позиционирует проект относительно аналогов

Из статьи:

GitHub SpecKit - "vibe coding с лишними шагами". Решает другую задачу (больше промптов, больше skill'ов), нежели согласование по ACID.
OpenSpec - расходится в философской предпосылке: OpenSpec считает, что спецификации описывают, как системы ведут себя сейчас; acai считает, что спецификации должны описывать, как системы должны себя вести.
Kiro - преобразует неструктурированный .md в синтаксис EARS. feature.yaml в acai метит в золотую середину между .md и EARS.
Traycer.ai - использует обычные .md-файлы; acai более требователен к структуре формата.

Пример использования

# in your project
npx @acai.sh/cli skill            # teach the agent the convention
# (write feature.yaml, hand the agent a prompt referencing it)

# CI / push to dashboard
ACAI_API_TOKEN=<secret> acai push --all

Промпт для агента, который автор предлагает вставлять дословно:

Dear Claude, ... Start by running npx @acai.sh/cli skill. This will teach you everything you need to know about our process for spec-driven development. Then, proceed to plan and implement the features specified in our spec files.

(Формулировка "Dear Claude / Love, [your-name]" - это авторская ирония; ключевая рабочая инструкция здесь - вызов npx @acai.sh/cli skill.)

Статус - watchlist

Внесён в watchlist с повторной проверкой 2026-08-03. Причины:

Проект одного автора, суммарно ~13★ на всех репозиториях на момент ingest'а, все три репозитория созданы за последние 2-3 месяца.
Хостинговый дашборд служит основной поверхностью для ревью. Self-hosting работает (сервер открыт), но он тяжеловесен: развёртывание стека Elixir/Phoenix/Postgres, включая reverse proxy. Большинство пользователей окажется на app.acai.sh - личном сервере автора без опубликованной бизнес-модели. Обещание "возможно, навсегда бесплатно" выглядит шатко.
Привязка к формату ощутима. Как только в кодовой базе появятся сотни ссылок // AUTH-2-1, переход с feature.yaml на другой инструмент спецификаций потребует миграционного скрипта.
Интеграция с CI/CD находится в roadmap, а не готова. Задуманный целевой процесс (реактивные циклы plan -> implement -> review) опирается на интеграции, которых пока нет.

Что позволит проекту выпуститься из watchlist'а: публичный переход заметного стороннего проекта на этот формат; появление примеров CI-хуков; второй контрибьютор в организации; прояснение разделения между hosted и self-hosted. При повторной проверке стоит также взглянуть, опубликовал ли автор "автоматизированный цикл plan -> implement -> review", на который он намекал.

Почему за проектом стоит следить, несмотря на watchlist

Соглашение об ACID как двунаправленных ссылках жизнеспособно независимо от самого продукта acai.sh - см. acceptance-criteria-ids для портативной версии. Даже если конкретно этот инструмент заглохнет, паттерн почти наверняка появится в более крупных системах (Cursor, Charlie Labs, GitHub), у которых есть достаточная база пользователей для его закрепления.

Ограничения

CLI только на TypeScript; портов на Python или Go пока нет (написать их, вероятно, тривиально, но сейчас это барьер для проектов не на Node, которым не хочется тащить зависимость от Node на этапе сборки).
Сервер написан на Elixir, что создаёт более высокий порог для self-hosting'а по сравнению с типичным бинарником на Go или Rust.
Интеграция с редакторами не документирована - агент изучает ACID через команду skill, но люди, пишущие feature.yaml, редактируют обычный YAML без валидации схемы, документации при наведении курсора или перехода к определению по ссылкам AUTH-2-1.
Соглашение наиболее полезно для бэкенда и функциональных возможностей. Возможности пользовательского интерфейса укладываются в схему хуже, поскольку автор явно исключает "дизайн и поверхностные требования" из рамок спецификации.

Связанные страницы

specsmaxxing - исходный пост, подробная аргументация и мысленный эксперимент
acceptance-criteria-ids - соглашение в отрыве от инструмента
acai-blog - блог на acai.sh
ceo-ai-psychosis - статья, где введён термин "AI psychosis"; автор acai использует его самокритично
ai-assisted-workflow - рабочий процесс Барберо со спецификацией до написания кода, близкая философия
clean-code-coding-agents - смежный аргумент о структуре кода как контексте для агента
building-syntaqlite-ai - пример из практики, где отсутствие дисциплины в спецификациях привело к переделкам
charlie-daemons, botctl, superhq, flue - смежные попытки решить более широкую задачу "реактивной фабрики софта", очерченную в посте

Репозиторий

github.com/acai-sh - cli (10★), server (3★), docs (Mintlify) - Apache-2.0