Ранее я уже рассказывал о Skaro (тут). С тех пор проект заметно изменился: вторая версия получилась не косметическим обновлением, а довольно глубокой переработкой самой модели работы.
Поэтому сейчас хочется не просто показать список новых функций, а нормально объяснить, что такое Skaro, для чего он нужен, почему я вообще продолжаю его развивать и куда хочу вести дальше.
Вопрос, который мне задают чаще всего
Когда показываешь новый инструмент для разработки с ИИ, почти сразу прилетает один и тот же вопрос: чем это отличается от Cursor, Codex, Claude Code и зачем вообще делать что-то ещё.
На мой взгляд, проблема здесь не в самом вопросе, а в исходной рамке. Обычно Skaro пытаются смотреть как на очередной инструмент того же класса: редактор, агент, генератор кода, оболочку вокруг LLM.
Но Skaro изначально задумывался не как ещё одна утилита, которая просто помогает писать код быстрее. И не как чат, в который периодически закидывают куски проекта. Его идея в другом.
Что такое Skaro
Если формулировать коротко, то Skaro — это напарник и среда для совместной работы над программным проектом вместе с ИИ.
Не в смысле «заменить разработчика». И не в смысле «поручить модели написать всё самой». А в смысле нормальной совместной работы, где у человека и у ИИ есть разные роли, и эти роли разделены естественно.
Человек ведёт проект. Он определяет замысел, принимает ключевые решения, держит архитектуру, требования, границы и смысл.
ИИ помогает как рабочая инженерная сила. Он участвует в обсуждении, помогает оформлять документы, раскладывать работу по этапам, формулировать задачи, писать реализацию, возвращаться к контексту и доводить работу до результата.
Именно в такой модели Skaro для меня имеет смысл.
В сгенерированном изображении есть опечатка :)
Почему вообще понадобился такой инструмент
Когда начинаешь работать над проектом вместе с ИИ всерьёз, довольно быстро становится заметна одна проблема.
Совместная работа человека и модели очень быстро производит большой объём мыслей, решений, гипотез, договорённостей, промежуточных выводов и уточнений. В голове это удержать невозможно. Размазывать это по случайным чатам тоже нельзя.
В какой-то момент проект начинает рассыпаться не потому, что не хватает кода, а потому, что теряется нить: почему приняли это решение, на чём держится архитектура, что уже было согласовано, как одна задача связана с другой, какие ограничения уже были зафиксированы.
Поэтому здесь нужна внешняя память проекта. Причём не абстрактная база знаний где-то сбоку, а рабочая структура, которая постоянно перед глазами и живёт рядом с самим проектом.
Почему в центре Skaro находятся артефакты
Именно для этого в Skaro есть артефакты.
Артефакты — это не документы ради документов и не бюрократия поверх разработки. Это фиксация того, что уже было придумано, обсуждено и согласовано: архитектуры, планов, вех, задач и других важных решений.
За счёт этого человек не теряет нить проекта. А ИИ работает не вслепую и не каждый раз «с чистого листа», а опирается на уже существующую основу.
Для меня это один из ключевых моментов. Если проект развивается вместе с ИИ, то значимая часть контекста должна жить не только в голове автора и не только в истории переписки, а в понятной структуре внутри репозитория.
И тогда появляется нормальная опора для дальнейшей работы.
Так выглядит структура папки .skaro: (структура урезана)
.skaro │ config.yaml │ constitution.md │ devplan.md │ secrets.yaml │ state.yaml │ token_usage.yaml │ usage_log.jsonl │ ├───architecture │ │ adr-001-использование-fastapi-в-качестве-веб-фреймворка.md │ │ adr-002-упрощённый-layered-monolith-как-архитектурный-патт.md │ │ adr-003-использование-psutil-для-сбора-системных-метрик.md │ │ adr-004-отказ-от-базы-данных-в-пользу-stateless-архитектур.md │ │ adr-005-отказ-от-docker-в-пользу-нативного-запуска-на-wind.md │ │ adr-006-отказ-от-аутентификации-и-авторизации-для-публично.md │ │ adr-007-использование-pydantic-settings-для-конфигурации-ч.md │ │ adr-008-синхронные-вызовы-psutil-в-async-эндпоинтах-без-as.md │ │ adr-009-стратегия-тестирования │ │ architecture.md │ │ chat-conversation.json │ │ │ └───diagrams ├───chat │ tasks.json │ ├───docs │ review-results.json │ ├───features ├───milestones │ ├───01-foundation │ │ │ milestone.md │ │ │ order.json │ │ │ │ │ ├───config-module │ │ │ │ clarifications.md │ │ │ │ plan.md │ │ │ │ spec.md │ │ │ │ tasks.md │ │ │ │ tests-confirmed │ │ │ │ tests.json │ │ │ │ verify.yaml │ │ │ │ │ │ │ └───stages │ │ │ └───stage-01 │ │ │ AI_NOTES.md │ │ │ ├───models_cache │ groq.json │ ├───ops └───templates adr-template.md ai-notes-template.md architecture-template.md constitution-template.md devplan-template.md plan-template.md security-checklist.md spec-template.md
Как выглядит нормальный сценарий работы
Тот сценарий, который я считаю правильным, выглядит примерно так.
Сначала человек вместе с ИИ продумывает проект и создаёт основные архитектурные документы.
Потом на их основе формирует план, разбивает его на вехи и задачи.
После этого начинается реализация — тоже вместе с ИИ, но уже не хаотично, а с опорой на зафиксированные решения.
Именно поэтому для меня важен чат везде, где действительно нужно обсуждение с ИИ. Его смысл не в наличии чата как такового, а в том, что архитектуру, план, задачи и другие рабочие материалы можно обсуждать прямо там, где они живут, и сразу сохранять результат в репозиторий.
Это делает работу цельной. Контекст не отрывается от места, к которому он относится.
Что изменилось в Skaro 2.0
Во второй версии мне было важно не просто добавить отдельные функции, а улучшить сам процесс совместной работы человека и ИИ над проектом.
То есть не «появилось ещё несколько экранов», а продукт был переработан так, чтобы такой способ работы стал понятнее, удобнее и естественнее в повседневной практике.
Ниже — основные изменения, которые для меня действительно важны.
Чат теперь встроен туда, где идёт работа
В Skaro 2.0 чат есть везде, где он действительно нужен для обсуждения с ИИ.
Это важное изменение не потому, что «в продукте появился чат». Чатов и без того достаточно.
Смысл в другом: обсуждение теперь происходит прямо в контексте артефактов, задач и рабочих страниц. Это позволяет не выпадать из процесса и не переносить важные разговоры в оторванное от проекта место.
Перед реализацией модель получает исходную опору
Перед выполнением задачи LLM получает первичный контекст и дальше уже сама запрашивает необходимые файлы для реализации.
Для меня это важный шаг к согласованности. Модель не просто получает короткий промпт и не начинает действовать почти вслепую. У неё есть отправная точка, а дальше она может добрать нужный материал по проекту в рамках задачи.
Это даёт более связную работу и уменьшает число ситуаций, когда реализация уезжает в сторону от уже принятых решений.
Авто-коммит по завершению задачи
В настройках можно включить автоматический коммит после завершения задачи.
Это не выглядит большой функцией на уровне презентации, но на практике очень полезно. Когда поток работы идёт быстро, такие вещи уменьшают трение и помогают держать ритм.
Статистика вынесена на отдельную страницу
Это сделало интерфейс чище и понятнее. Рабочие сценарии перестали спорить друг с другом за место на одном экране, а наблюдение за использованием моделей и активностью стало более собранным.
Стартовая страница теперь лучше отражает состояние работы
На стартовой странице появилась доска задач в стиле канбан.
Это удобно не только как красивый обзор. Такая доска помогает быстро понять текущее состояние проекта, увидеть, на чём остановился, и без лишнего переключения вернуться в работу.
Для инструмента, который должен помогать вести проект, а не просто разово генерировать фрагменты кода, это очень важный элемент.
Интерфейс стал более гибким и аккуратным
Во второй версии появилась лёгкая кастомизация темы: можно выбрать акцентный цвет или задать свой.
Кроме того, в целом был улучшен дизайн. Я не отношусь к интерфейсу как к декоративной части. Если продуктом пользуются как рабочей средой, он должен быть визуально спокойным, понятным и предсказуемым.
Поэтому в 2.0 я уделил внимание не только новым возможностям, но и тому, как всё это ощущается в ежедневной работе.
Были закрыты известные проблемы
Отдельно отмечу и более приземлённую часть работы: во второй версии были закрыты известные проблемы, которые мешали пользоваться продуктом так, как он задумывался.
Для меня такие изменения не менее важны, чем новые функции. Если инструмент претендует на роль постоянной рабочей среды, он должен быть устойчивым и собранным не только в идее, но и в повседневной эксплуатации.
Куда я хочу вести проект дальше
Ядро Skaro останется Open Source.
Это для меня принципиально. Базовая идея совместной работы над проектом с ИИ, опора на артефакты и проектную память, связка обсуждения и реализации — всё это должно оставаться открытым.
При этом дальше я хочу развивать вокруг Skaro отдельный workspace для команд и компаний.
Речь о более широкой рабочей экосистеме: совместная работа, права доступа, аналитика, контроль расходов, доски, общая организация процесса и другие возможности, которые нужны уже не одному разработчику, а команде.
Это следующий логичный слой развития. Но сам open source-проект при этом никуда не исчезает и не превращается в закрытую витрину.
Ищу партнёра-инвестора на ранней стадии
Сейчас я также открыт к диалогу с партнёром-инвестором ранней стадии.
У проекта есть рабочая основа, понятное направление развития и достаточно ясное видение того, во что он может вырасти дальше.
Если вам близка сама идея такого продукта и интересен разговор об этом направлении, можно написать мне в Telegram: @g2a_2.
Вместо итога
Для меня Skaro — это не попытка сделать «ещё один AI-инструмент». И не желание собрать вокруг модели очередную оболочку.
Я смотрю на него как на рабочую среду, в которой человек и ИИ вместе создают программный проект, а все ключевые решения, планы, вехи и задачи сохраняются в понятной структуре, чтобы работа не рассыпалась по памяти и случайным чатам.
Именно под это и была пересобрана версия 2.0.
Если вам интересна такая модель работы, буду рад обратной связи. А если вы уже работаете с ИИ в разработке и тоже упёрлись в проблему проектной памяти, согласованности решений и удержания контекста, тем более интересно сравнить подходы.
GitHub: https://github.com/skarodev/skaro
Сайт: https://skaro.dev
Документация: https://docs.skaro.dev
Telegram: https://t.me/skarodev Discord: https://discord.gg/zUv6AHuJwD
