Comments 10
Не понятно чем оно лучше spec-kit. Одна строчка в таблице совершенно голословна и кажется даже не притянута за уши, а вовсе выдумана
там же сцылка:
Двухпапочная модель OpenSpec (openspec/specs/ для текущих изменений, openspec/changes/ для предлагаемых обновлений) разделяет состояние и различия. Это масштабируемо при изменении существующих функций или работе с несколькими спецификациями. spec-kit хорошо подходит для новых разработок (greenfield/0→1), но обеспечивает меньшую структуру для обновлений между спецификациями и развития новых функций.
Я заполнил файл
openspec/project.mdактуальной информацией о проекте,
Можно глянуть на результат?
crush и warp уже давно формируют свою дб в проекте и AGENTS.md
Проблема в непредусмотрительности поведения при превышение контекста. Агент должен снова прочитать доки или историю. В некоторых ситуациях системный промт становится частью контекста и тоже удаляется, яркий пример gem боты gemini
Чем это принципиально отличается от claude code с его claude.md в корне и кучей md , которые генерят саб-агенты?
Давно пора создать формальный язык программирования для создания промптов LLM :)
Мы бы давно его навайбкодили, но..
Точняк!
Мне уже придумал SPEC-L и правдоподобную реализацию на Go сделал(даже lsp добавил), но я не проверял)
Проблема взаимодействия с LLM — это проблема создания надёжного канала коммуникации между человеческим intent и машинной execution.
SPEC-L решает её через:
Формализацию — убираем неоднозначность
Структурирование — разбиваем сложное на простое
Верификацию — встроенные проверки на каждом шаге
Интерактивность — протокол уточнений
Детерминизм — воспроизводимые результаты
Не болтайте ерундой