Від середини квітня до середини червня я майже не торкався функцій свого продукту.
Я будував OwlMeans — конвеєр розробки, який перетворює користувацькі історії на програмне забезпечення. А робота навколо нього тим часом була розпорошена. Стратегія, нотатки про бренд, дослідження й тексти для сайту лежали в різних місцях.
Щоразу, коли я просив агента про допомогу, доводилося заново розповідати йому про компанію.
Щоб це змінити, я витратив два місяці. Зібрав робочий простір, де тепер тримаю знання компанії й виконую регулярну роботу.
Проблема виринала в найзвичайніших завданнях.
Для статті потрібне було актуальне позиціонування. Для змін на сайті — те, що продукт справді вміє. Для дослідження — питання клієнта, на яке ми намагалися відповісти.
Щоразу йшлося про ті самі факти, а я все ще вписував їх вручну. Часом забував про якесь застереження. Часом у чернетку потрапляв посил, що належав попередній версії компанії.
Сильний агент міг працювати з тим матеріалом, який я йому давав. А от надійного місця, де цей матеріал шукати, я йому не дав.
Ця різниця багато важила. Можна було поліпшувати промпт під кожне завдання або ж зробити так, щоб робочі знання компанії було легше знаходити й оновлювати. Я взявся за друге.
Спільна база знань
Вікі компанії я завів у Markdown.
Там зібрано стратегію, знання про клієнтів, правила бренду й документацію продукту. Індекси в теках підказують агентові, де шукати. Кожна сторінка присвячена конкретній темі, а новій знахідці місце поряд зі знанням, яке вона змінює.
Звучить як розкладання паперів по теках. Значною мірою так воно і є.
І дослідження, і практична робота можуть спиратися на ту саму базу знань. Коли статті потрібен факт про продукт, агентові є де його перевірити. Коли під час редагування сайту виявляється застарілий факт, у вікі є місце для виправлення.
Проте база знань не замінює критичного погляду. Неперевірене уявлення про ринок не стає правдою лише тому, що агент поклав його в упорядковану теку. Відкриті гіпотези ми тримаємо окремо від усталених знань.
Наступним шаром стали навички.
Я записав робочі процеси, які раз у раз повторював: дослідження, підготовку статей, синхронізацію сайту й підтримку документації продукту. Кожна навичка описує завдання й внутрішні правила, які легко проґавити.
Відтак виправлення може поліпшити наступний запуск. Для цього його треба записати у відповідні настанови: від того, що я виправив модель у чаті, вона не вивчить компанію раз і назавжди.
Навичка може застаріти так само, як документ. Хтось має перевіряти, чи її процедура досі відповідає інструментам і самій роботі.
Специфікація Agent Skills задає спільний формат теки й метаданих. А от інструкції всередині наших навичок пишемо й підтримуємо ми самі.
Код поруч із компанією
До робочого простору я підключив і наші репозиторії.
Для текстів це мало цілком практичне значення. Стаття про реліз могла відштовхуватися від реалізації, а не від спогадів про те, що ми збиралися випустити. Технічна документація могла відрізняти закомічений код від ідеї з роадмапу.
Підключення не стирає різниці між цими джерелами. Дизайн-документ описує намір. Коміт показує реалізацію. Жоден із них не доводить, що конкретний робочий процес клієнта вже успішно перевірили на практиці.
Для компанії, яка продає конвеєр розробки на основі ШІ, тримати ці відмінності на видноті — частина роботи.
Структура одразу знадобилася в роботі над статтями.
Я міг надиктувати тему, а далі агент перевіряв нашу вікі й зовнішні джерела, готував чернетку та проганяв її через редакторську перевірку. Зображення й адаптації для соцмереж були окремими кроками. До публікації доходило лише тоді, коли я про це просив.
Фактам більше не треба було мандрувати з моєї памʼяті в кожен промпт.
Та сама схема допомагала й у роботі над сайтом. Публічну сторінку й внутрішнє пояснення можна було звірити між собою, поки і те, і те було під рукою.
Працювати без мене компанія від цього не почала. Я, як і раніше, вирішував, що публікувати, перевіряв твердження й визначав, яка робота варта уваги.
Цей досвід позначається й на нашій роботі в межах послуг OwlMeans. Поряд із написанням програмного забезпечення важить і те, як описати робочий процес і підготувати передачу проєкту. Для цього потрібен конкретний обсяг робіт під проєкт клієнта, а не обіцянка, що бізнес вестиме агент.
Файли памʼяті
Червнева версія цієї історії описувала файли контексту, якими я тоді користувався. Відтоді налаштування змінилося.
До жовтня наші спільні настанови вже містилися в AGENTS.md і загальному каталозі навичок, а де треба, їх доповнював невеликий місток CLAUDE.md. Окремі копії інструкцій під кожного агента перестали бути схемою, на яку варто орієнтуватися.
Актуальна документація Claude Code про памʼять розрізняє інструкції проєкту й автоматичну памʼять. Тож старе огульне твердження, ніби в цього інструмента немає постійної памʼяті, тепер недоречне.
Наша база знань має інше призначення. Вона фіксує, що вирішили в OwlMeans, які докази підкріплюють твердження про продукт і який робочий процес застосовувати до завдання. Мені треба, щоб її й надалі можна було перевіряти незалежно від інструмента.
Пізнішу структуру репозиторіїв докладніше описано в історії про переробку обвʼязки.
Чого це коштувало
Два місяці для засновника-одинака — чималий гак.
З робочим простором повторювану роботу легше підхопити, але, поки я його будував, функції продукту чекали. До того ж зʼявився постійний обовʼязок: інструкції та знання мають лишатися актуальними.
Я вклався б у це знову, бо користуюся цією структурою в роботі. Але вдруге почав би з меншого. Надійна база знань під кілька регулярних завдань корисна ще до того, як стане системою для всієї компанії.
Переглянуто 15 жовтня 2026 року. Розповідь про те, як у квітні–червні я відклав продукт, лишилася без змін; описи структури репозиторіїв і памʼяті вище відрізняють початкове налаштування від теперішнього.