
С середины апреля до середины июня я почти не трогал фичи продукта.
Я строил OwlMeans — конвейер разработки, который превращает пользовательские истории в софт. А работа вокруг него была разбросана. Стратегия, заметки о бренде, исследования и тексты для сайта лежали в разных местах.
Всякий раз, когда я просил агента помочь, я заново рассказывал ему о компании.
На то, чтобы это изменить, ушло два месяца. Я собрал рабочее пространство, где теперь живут знания компании и идёт регулярная работа.
Проблема всплывала в обычных задачах.
Для статьи нужно было актуальное позиционирование. Для правки сайта — реальные возможности продукта. Для исследования — вопрос клиента, на который мы пытались ответить.
Каждый раз требовались одни и те же факты, а я по-прежнему вписывал их вручную. Иногда я упускал оговорку. Иногда в черновик попадал посыл из прежней версии компании.
Толковый агент справлялся с материалом, который получал от меня. А вот надёжного места, где этот материал искать, я ему так и не дал.
Разница оказалась принципиальной. Я мог шлифовать промпт под каждую задачу. Или сделать так, чтобы рабочие знания компании было проще находить и обновлять. Я взялся за второе.
Общая база знаний
Вики компании я завёл в Markdown.
Там стратегия, знания о клиентах, правила бренда и документация продукта. Индексы папок подсказывают агенту, где искать. У каждой страницы своя конкретная тема, а новая находка ложится рядом со знанием, которое она меняет.
Похоже на канцелярскую работу. Во многом это она и есть.
На одну и ту же базу могут опираться и исследования, и практическая работа. Если статье нужен факт о продукте, агенту есть где его проверить. Если правка сайта вскрыла устаревший факт, в вики есть куда записать исправление.
Записям в базе всё равно нужен критический взгляд. Непроверенное представление о рынке не становится правдой оттого, что агент аккуратно разложил его по папкам. Открытые гипотезы мы держим отдельно от проверенных знаний.
Следующим слоем стали навыки.
Я записал процессы, которые повторял раз за разом: исследования, подготовку статей, синхронизацию сайта и поддержку документации продукта. Каждый навык описывает задачу и внутренние правила, которые легко упустить.
Тогда исправление может улучшить следующий запуск. Но его нужно вписать обратно в подходящую инструкцию: модель не выучит компанию навсегда только потому, что я поправил её в чате.
Навык может устареть, как и любой документ. Кто-то должен проверять, что описанная в нём процедура всё ещё соответствует инструментам и самой работе.
Спецификация Agent Skills задаёт общий формат папки и метаданных. А инструкции внутри наших навыков писать и поддерживать по-прежнему нам.
Код рядом с компанией
Ещё я подключил к рабочему пространству наши репозитории.
На текстах это сказалось вполне ощутимо. Статью о релизе теперь можно было начинать с реализации, а не с воспоминаний о том, что мы собирались выпустить. Техническая документация могла отличать закоммиченный код от идеи из дорожной карты.
Подключение не стирает разницу между этими источниками. Проектный документ описывает намерение. Коммит показывает реализацию. Ни тот ни другой не доказывает, что конкретный рабочий сценарий клиента успешно прогнали.
Для компании, которая продаёт конвейер разработки на ИИ, держать эти различия на виду — часть работы.
Эта структура сразу пригодилась в работе над статьями.
Я мог надиктовать тему, и агент сверялся с нашей вики и внешними источниками, готовил черновик и пропускал его через редакторскую проверку. Картинки и адаптации для соцсетей шли отдельными шагами. Публикация — только по запросу.
Фактам больше не нужно было переезжать из моей памяти в каждый промпт.

То же устройство помогло и в работе над сайтом. Публичную страницу и внутреннее описание можно было сверить, пока и то и другое было под рукой.
Работать без меня компания от этого не научилась. Я по-прежнему сам выбирал, что публиковать, проверял утверждения и решал, какая работа заслуживает внимания.
Этот опыт мы переносим и в Услуги OwlMeans. Там, кроме самого софта, важно описать рабочий процесс и подготовить передачу проекта. Для этого нужен конкретный объём работ под проект клиента, а не обещание, что бизнес будет вести агент.
Файлы памяти
Июньская версия этой истории описывала файлы контекста, которыми я тогда пользовался. С тех пор устройство поменялось.
К октябрю общие инструкции жили в AGENTS.md и в единой папке навыков, а там, где нужно, — небольшой мост CLAUDE.md. Отдельные копии инструкций под каждого агента перестали быть схемой, на которую стоит равняться.
Актуальная документация Claude Code о памяти разделяет инструкции проекта и автоматическую память, так что прежнее огульное утверждение, будто у этого инструмента нет постоянной памяти, больше не годится.
У нашей базы знаний другая задача. В ней записано, что решено в OwlMeans, какие факты подкрепляют утверждение о продукте и какой рабочий процесс применять к задаче. Мне нужно, чтобы эту базу можно было открыть и проверить из любого инструмента.
Более позднюю структуру репозиториев подробнее описывает история о том, как мы перестроили обвязку для агентов.
Во что это обошлось
Для основателя-одиночки два месяца — большой крюк.
С рабочим пространством повторяющуюся работу легче подхватывать, но, пока я его строил, фичи продукта откладывались. А ещё появилась постоянная обязанность: инструкции и знания нужно держать актуальными.
Я бы вложился в это снова, потому что сам работаю в этой структуре. Но начал бы с меньшего. Надёжная база для нескольких регулярных задач полезна ещё до того, как станет системой для всей компании.
Отредактировано 15 октября 2026 года. Рассказ о крюке с апреля по июнь не изменился; описания структуры репозиториев и памяти выше отделяют первоначальное устройство от нынешнего.