Как Claude превращает переписку в решение: из ветки в документ

Самая дорогая фраза в рабочем чате - «мы же договорились». После неё выясняется, что договорились двое, поняли по-разному четверо, а фамилии не стояло ни у одного пункта.

Ветка переписки хранит всё: кто предложил, кто засомневался, где отвлеклись на подрядчика. Чего в ней нет - так это ответа на вопрос, что теперь делать. Этот переход и отдают Claude: ты кидаешь ему ветку целиком, он возвращает документ, в котором остались решения, владельцы, сроки и то, что повисло открытым. Контекст, эмоции, черновики мысли и три отменённых варианта туда не едут.

Тянет всю работу здесь форма запроса. Модель получает схему полей, каждое из которых обязано быть либо заполнено, либо честно помечено пустым, и расплывчатое «сделай итоги» через такую схему уже не проходит.

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

Чем протокол решения отличается от пересказа переписки?

Открой последние итоги, которые кто-то присылал в твой рабочий чат, и попробуй поставить по ним задачу исполнителю, не подглядывая в саму переписку. Если пришлось листать наверх, тебе присылали пересказ.

Пересказ отвечает на вопрос «о чём говорили», протокол - «что теперь делает каждый». В первом есть все участники, весь ход мысли и вежливые формулировки. Во втором остаётся только то, что меняет чьи-то действия, плюс список того, что ещё не решено. Оба могут занимать страницу, но пишутся для разных ситуаций.

Типичный пересказ звучит так: «обсудили вопрос цены, Миша предложил поднять на 15%, Лена сомневается из-за старых клиентов, договорились подумать». В одном предложении тут сразу три дырки: решение не названо, думающий не назначен, и никто не знает, когда это «подумать» кончится.

Протокол на том же материале:

Решение. Цену на базовый тариф поднимаем на 15% с 1 октября. Владелец. Лена. Срок. Новый прайс на сайте до 25 сентября. Открытый вопрос. Что делаем со старыми клиентами: сохраняем цену навсегда, фиксируем на полгода или переводим сразу. Решает Серёжа до 18 сентября.

Разговор за этими строками один и тот же, только во втором варианте никому не нужно ничего вспоминать, и сразу видно, что решение принято лишь частично: висит кусок с фамилией и датой. Слова «договорились подумать» этот кусок прячут, а протокол держит его на виду.

Модель нужна именно на переходе от одного к другому. Человек, который был в разговоре, честный протокол сразу не напишет физически: он помнит контекст и достраивает пропущенное в голове, не замечая. У Claude такой памяти нет. Он видит только текст, и если владельца в тексте нет, на его месте останется пустое поле.

Почему итоги встреч и чатов никто не читает?

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

Способов убить такой документ ровно три, и все три обычно встречаются в одном файле.

Первый способ - хронология. Итоги идут в порядке разговора: сначала про бюджет, потом отвлеклись на подрядчика, потом вернулись к бюджету. Читателю удобнее порядок по владельцам и срокам, ход самой беседы его не занимает. Хронология полезна в одном случае: когда потом придётся разбираться, почему решили именно так. Для этого хватит строки контекста под каждым пунктом.

Дальше идут безличные формулировки. «Было принято решение усилить работу с базой» - такую строку никто не выполнит. Пассив в протоколе всегда значит, что владельца не нашли и постеснялись об этом сказать.

Третьим стоит смешивание уровней. В одном списке лежат «запустить новую линейку продуктов» и «поправить опечатку на лендинге». Глаз перестаёт различать важное, документ читается как свалка.

Claude чинит все три механически, если задать форму. Хронологию ломает сортировкой по владельцу. Пассив убирает прямым запретом в промпте. Уровни разделяет, если попросить пометить каждый пункт как решение, задачу или открытый вопрос. Работа скучная, и человек делает её плохо просто потому, что лень. Похожая история с ежедневной сводкой на одну страницу: там всё держится на соблюдении формы каждый день без исключений, а глубина выводов модели вторична.

И отдельно про длину. Протокол по одной ветке, который не влезает на экран телефона, читать не будут. Двадцать пунктов означают, что в ветку слиплись несколько разных разговоров, и разбирать их надо порознь.

Из каких блоков собирается протокол, который реально читают?

Блоков четыре, и один из них всегда пытаются выкинуть. Это решения, задачи с владельцами и сроками, открытые вопросы и отклонённые варианты - последний как раз и кажется лишним. Первые три обязательны всегда, четвёртый снимает повторное обсуждение того же самого через месяц. Всё, что не попало ни в один блок, в документ не идёт - это главное правило формата.

Блок	Что в нём	Зачем нужен	Что ломается без него
Решения	Одна строка на решение, в настоящем времени, без «планируем»	Точка отсчёта для всех остальных	Через неделю спор, решили или обсуждали
Задачи	Действие + имя владельца + дата	Переводит решение в работу	Решение есть, движения нет
Открытые вопросы	Формулировка + кто решает + до какого числа	Честно показывает дыры	Дыра всплывает в момент, когда её уже нельзя закрыть спокойно
Отклонено и почему	Варианты, которые рассмотрели и не взяли	Защита от кругов	Тот же разговор заново с новым человеком

Про четвёртый блок ещё раз: не выкидывай. Он занимает три строки и снимает самый дорогой вид потерь - когда новый сотрудник или партнёр приходит с «а давайте попробуем скидки», а вы это уже считали и отказались. Без записи придётся считать снова.

Есть ещё элемент, который стоит добавлять, когда решение серьёзное: строка «на каком основании». Одного предложения хватает - на какие цифры или факты опирались. Пересказывать спор не нужно. Через полгода, когда решение начнёт разваливаться, смотреть ты будешь именно на эту строку: изменились ли исходные данные. Приём пришёл из инженерной практики записи архитектурных решений, где документ из трёх абзацев переживает систему, ради которой его писали.

Чего в протоколе быть не должно: оценок людей, цитат целиком, вложенных списков глубже второго уровня и слова «синергия».

Эта статья закрывает один вопрос - как из ветки переписки получить документ, по которому можно работать. В общей картине протокол только один орган: он фиксирует решения, но не помнит цифры дела, не ведёт клиентов и не собирает контент. Если хочешь увидеть, как отдельные приёмы складываются в систему, где у каждой роли свой участок, можешь забрать бесплатное обучение - доступ по почте, материал открывается сразу.

Как собрать ветку, чтобы Claude ничего не потерял?

Главный соблазн на этом шаге - причесать переписку перед отправкой. Убрать перепалку, свести три сообщения в одно, выкинуть «ага, понял». Причёсывать не стоит: именно в этом мусоре прячутся оговорки, из которых понятно, кто на самом деле взял задачу.

Отдавай ветку одним куском, с именами и датами, в том виде, в каком она есть. Границы определяй по смыслу: от постановки вопроса до последнего сообщения по теме.

1. Выдели диапазон. Найди сообщение, где вопрос впервые поставлен, и последнее сообщение по этому вопросу. Всё между ними - твоя ветка, даже если внутри есть сообщения на другие темы.
2. Скопируй с метаданными. Имя автора и дата у каждого сообщения обязательны. Без имён не будет владельцев, без дат модель не поймёт, какая формулировка новее.
3. Не удаляй противоречия. Если Миша сначала сказал «делаем», а через день «давайте отложим» - нужны оба сообщения. Пусть модель увидит конфликт и вынесет его в открытые вопросы; причёсанная тобой версия эту развилку сотрёт.
4. Добавь то, что было вне чата. Одна строка курсивом: «решение по бюджету принято на созвоне 3 сентября, в чате его нет». Иначе в протоколе появится дыра, которой в реальности нет.
5. Приложи артефакты. Таблица с расчётами, скрин прайса, кусок договора. Claude нормально читает вложения, и цифры в протоколе окажутся теми же, что в файле. Как модель работает с табличными данными, разобрано в материале про Claude и Excel.

Отдельный случай - созвоны. Источником становится расшифровка, и она всегда грязная: обрывки фраз, перебивания, «ага, ну да». Редактировать её не пытайся, это часы работы. Отдавай как есть и предупреди в промпте, что это автоматическая расшифровка с ошибками распознавания имён. С таким материалом модель справляется лучше человека - она не устаёт от третьей страницы.

Где ломается: скриншоты. Отдал ветку картинками - порядок сообщений может поехать, текстом надёжнее. И если в чате много пересылок из других чатов, помечай их: процитированное чужое мнение легко превращается в решение твоей команды.

Какой промпт превращает ветку в документ?

Попроси «сделай итоги» - получишь пересказ. Модель будет вежливой: достроит то, чего в тексте не было, назначит владельцем последнего писавшего, а чьё-то «а давайте вот так» аккуратно положит в решения.

Весь промпт ниже - защита от этой вежливости. Роль, жёсткая схема полей, запрет на домыслы и указание, что делать с пропусками. Пишется один раз и потом живёт годами с мелкими правками, так что копируй целиком.

Ты ведёшь протоколы решений в небольшой компании.
Ниже ветка переписки. Собери из неё документ.

Формат строго такой:

## Решения
Одна строка на решение. Настоящее время, активный залог.
Под каждым - строка "Основание:" с фактом или цифрой, если они были в тексте.

## Задачи
Таблица: Что сделать | Владелец | Срок | Из какого решения растёт.

## Открытые вопросы
Формулировка вопроса | Кто решает | До какого числа.

## Отклонено
Вариант и одна фраза почему.

Правила:
- Пиши только то, что есть в переписке. Ничего не додумывай.
- Если владелец не назван - пиши "не назначен". Не угадывай по контексту.
- Если срока нет - пиши "срок не задан".
- Если участники противоречат друг другу, более позднее сообщение
  считай актуальным, а противоречие вынеси в открытые вопросы.
- Мнение и предложение решением не считаются. Решение - это то,
  с чем явно согласились или что объявил принимающий решение.
- Максимум 10 пунктов в блоке "Задачи". Если больше - значит,
  в ветке несколько разных тем, скажи об этом отдельной строкой.

Переписка:
[текст]

Основную работу тут делают две строки. «Не назначен» вместо угадывания - потому что модель по умолчанию назначает владельцем того, кто последним написал что-то по теме, и это тихая ошибка, которую потом никто не ловит. И разделение мнения и решения: без этой строки любое «а давайте сделаем вот так» уезжает в блок решений, а через неделю выясняется, что никто не соглашался.

Результат удобнее получать отдельным документом. Тогда протокол правится на месте: меняешь формулировку, добавляешь пункт, и на выходе лежит готовый файл. Пересматривать длинную историю переписки с моделью для этого не приходится. Механика такого режима разобрана в статье про то, как ответ превращается в рабочий документ.

Под свою команду промпт донастраивают обычно в двух местах: добавляют список ролей, чтобы в документе стояло «маркетолог» вместо имени, и фиксируют формат даты. Второе звучит мелко, но когда протоколы начнут накапливаться, единый формат даты определит, получится архив или каша.

Как отличить решение от мнения, которое прозвучало громко?

В рабочем чате никто не пишет «принято решение». Пишут «ну ок», «давайте так», ставят палец вверх. Или просто молчат после чьего-то предложения, и Claude читает это молчание как согласие: возражения-то нет.

Граница проходит по согласию или полномочию. Решение - это либо явное «да, делаем» от того, кто может решать, либо формулировка, с которой никто не спорил и по которой пошли действия. Остальное - предложение, даже если высказано уверенно и повторено трижды. Ошибается модель здесь чаще всего и делает это незаметно.

Введи третью категорию. Кроме решений и открытых вопросов попроси отдельный блок «Похоже на решение, но согласия в тексте нет». Туда уедет всё спорное, и разбирать глазами придётся пять строк вместо всей ветки.

Назови в промпте, кто может решать. Одна строка: «решения по бюджету принимает Серёжа, по контенту - Аня». Тогда предложение подрядчика останется предложением, даже если оно самое громкое в переписке.

Проси цитату-подтверждение. Для каждого решения - короткая цитата из ветки, на которой оно стоит. Дешёвая страховка: если цитата выглядит как «ага, посмотрим», решение фальшивое. Заодно так ловится момент, когда модель начала пересказывать вместо того, чтобы читать.

Дальше вступает человек. Модель не знает, что Миша в этом чате всегда говорит «давайте» из вежливости, а решает через день голосом, и что «ок» от бухгалтера означает «я прочитал» и ничего больше. Эта часть не автоматизируется, и не надо её автоматизировать: тут нужен тот, кто несёт последствия. Та же граница проходит и в других задачах, где модель готовит материал, а решение остаётся за человеком - например, при подготовке к продающему звонку сценарий собирает модель, а говорит и обещает живой человек.

Почему без имени владельца пункт мёртв?

«Нужно обновить прайс» читается всеми как «кто-то обновит прайс», и через месяц на сайте по-прежнему старые цифры. Владелец - это человек, к которому ты придёшь с вопросом «где оно». Руками работу может делать кто угодно, отвечает один. Правило простое: один пункт, одно имя. Отдел, «маркетинг» и два человека через слэш не годятся - два владельца означают ноль владельцев, и каждая команда убеждается в этом на своём опыте.

Дальше начинаются честные неудобства.

Бывает, что владельца в переписке действительно нет. Обсудили, согласились, никто не взял. Claude напишет «не назначен» - и вот это ценный результат: в документе появится строка, которую в таком виде нельзя разослать. Придётся либо назначить, либо признать, что задачи нет. Оба варианта лучше подвешенного состояния.

Другой случай: владелец назначен, но сам об этом не знает. Человека вписали в чате, где его не было, или донесли до него пересказом. Поэтому в протоколе полезна отдельная колонка «знает ли владелец» с двумя значениями. Выглядит бюрократично - ровно до первого случая, когда задача не сделана, потому что человек о ней не слышал.

Третий вариант - владелец ты сам, и против трети пунктов стоит твоё имя. Модель не ошиблась, так выглядит диагноз распределения работы. Протоколы за месяц, сложенные вместе, показывают его без всякой аналитики: достаточно посчитать имена.

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

Что делать с открытыми вопросами, чтобы они не потерялись?

Их приятно записывать и не хочется закрывать. Там лежит то, о чём договориться не вышло, и каждый следующий заход болезненнее предыдущего.

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

1. Формулируй как выбор. «Разобраться с возвратами» провисит год, «возвраты принимаем 14 дней или 30» требует ответа сегодня.
2. Ставь имя того, кто решает. Обсуждать могут все, подписывает один.
3. Дата обязательна даже приблизительная. «До конца сентября» лучше, чем пусто. Пустая дата означает «никогда».
4. Переноси хвост в следующий протокол. Попроси Claude в начале нового документа выводить блок «осталось с прошлого раза» с датами. Вопрос, который переехал три раза, либо не нужен, либо им надо заняться сегодня.
5. Закрывай явно. У закрытого вопроса должна появиться строка в блоке решений с той же формулировкой. Иначе в архиве останется вопрос без ответа, и через полгода кто-то начнёт решать его заново.

Отдельная история - вопросы, которые закрыть нельзя в принципе: ждём ответа поставщика, ждём решения суда, ждём сезона. Выноси их в подблок «ждём внешнего события». Иначе они портят картину и создают ощущение бардака там, где его нет.

Как проверить протокол за три минуты?

Документ выглядит аккуратно, значит, можно рассылать. Так думают все, и это ровно та точка, где в компанию заезжает фраза, которой никто не говорил. Аккуратность тут ничего не доказывает: модель одинаково ровно оформляет и сказанное, и достроенное. Поэтому проверка нужна короткая, но всегда.

Что проверяешь	Как	Красный флаг
Решения	Читаешь цитаты-подтверждения	Цитата вида «посмотрим», «интересно», «ну ок»
Владельцы	Пробегаешь колонку с именами	«Команда», «мы», «не назначен» без твоей реакции
Сроки	Смотришь даты	Все сроки одинаковые или все в конце месяца
Цифры	Сверяешь с приложенным файлом	Округлённые числа там, где в источнике точные
Лишнее	Ищешь формулировки, которых не было	Красивые обобщения и выводы, которых никто не произносил

Последняя строка - главная. Модель иногда добавляет связку, которой в переписке не было: «поскольку конверсия падает, решено поднять цену». Про конверсию никто не говорил, это достроенная логика. Опасна она тем, что выглядит осмысленно, а через месяц читается как факт.

Отсюда одно правило: не помнишь фразу из переписки - не оставляй её в документе. Удалить лишнее дешевле, чем потом объяснять, откуда взялось.

И проверка на назначение, та самая, с которой всё началось. Дай протокол человеку, который в разговоре не участвовал, и попроси сказать, что он должен делать. Если переспросил - документ не готов. Тест грубый, но ловит больше любого чек-листа.

Чем отличается протокол для чата, созвона и почты?

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

Источник	Что забирать	Главная ловушка	Что добавить в промпт
Рабочий чат	Всю ветку с именами и датами	Реакция или эмодзи вместо согласия	«Реакцию считай прочтением, не согласием»
Расшифровка созвона	Текст целиком, не чистить	Имена распознаны неверно, реплики слиплись	«Это автоматическая расшифровка, имена могут быть искажены»
Почта	Последнее письмо плюс цитируемая история	Решение в хвосте старого письма	«Более позднее письмо главнее, хвосты используй как контекст»
Голосовые	Расшифровка целиком, без пересказа	Один человек, нет возражений - всё звучит как решение	«Один говорящий: считай решением только прямое утверждение»
Смешанный случай	Всё вместе, с пометками откуда	Порядок событий едет	Явно указать хронологию источников

Смешанный случай встречается чаще всех: часть в чате, часть на созвоне, финал в голосовом. Тут помогает простая вещь - перед текстом каждого источника пиши строку «источник: чат, 3-9 сентября» или «источник: созвон 10 сентября». Модель выстроит хронологию правильно, и в протоколе не окажется, что решение отменили до того, как приняли.

Ещё тонкость про длинные документы внутри переписки. Если в ветке обсуждают правки в договор, протокол по обсуждению и разбор самого документа - две разные задачи. Смешаешь в одном запросе - получишь ни то ни другое. Как работать со второй частью, показано в материале про то, как вычитать документ с Claude.

Где эта схема ломается?

Подводит она в неожиданных местах. Длина ветки и качество расшифровки к списку проблем почти не относятся.

Невысказанный контекст. Фраза «делаем как в прошлый раз» осмысленна для всех участников и пуста для модели. Claude перенесёт её в протокол дословно, и документ станет непонятным новому человеку. Лечение: перед текстом дай короткий блок фактов - что за проект, кто есть кто, что означают внутренние словечки. Это же ядро переиспользуется во всех задачах с моделью, собрать его один раз выгоднее, чем объяснять заново каждый раз; принцип разобран в статье про базу знаний для нейросети.

Политика. Иногда владельца не назначают по причине, далёкой от забывчивости: никто не хочет брать. И открытый вопрос висит потому, что закрыть его - признать чью-то неправоту. Протокол выставляет это на свет, и вместо благодарности можно услышать «зачем ты это записал». Готовься к такому разговору, а не удивляйся ему. Документ не виноват, он просто перестал прятать.

Решений не было. Самый неприятный случай: прогоняешь двухчасовую встречу и получаешь пустой блок решений и восемь открытых вопросов. Модель отработала честно: встреча прошла, решений на ней не приняли. Утешение одно - сегодня это ещё дешёвый вывод, через три недели он обошёлся бы дороже.

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

И техническая мелочь, которая портит больше, чем кажется: конфиденциальность. Ветка с ценами, фамилиями клиентов и условиями договоров уезжает в модель целиком. Реши заранее, что можно отдавать, а что заменить на роли и обезличенные обозначения. Практические вопросы доступа и настроек для работы из России собраны отдельно - как пользоваться Claude из России.

Как поставить это на поток, чтобы не делать руками?

Обычный путь такой: человек собирает красивый сценарий, который каждый вечер кладёт готовый документ в общую папку. Через месяц выясняется, что папку никто не открывает - формат неудачный, и это было видно с первого документа.

Форма сначала, автоматизация потом. Два-три месяца делай руками: копируешь ветку, прогоняешь промпт, правишь, рассылаешь. Автоматизируют только тот формат, который команда уже читает.

1. Один тип встреч. Возьми самую регулярную планёрку и веди протокол только по ней. Не пять форматов сразу, один.
2. Один шаблон промпта в сохранённом виде. Не переписывай каждый раз, иначе документы будут разной формы и сравнивать их станет нельзя.
3. Одно место хранения. Папка или база, где протоколы лежат по датам с понятными именами файлов. Протокол, оставшийся в переписке с моделью, через неделю не найти.
4. Проверка перед рассылкой всегда. Три минуты по чек-листу. Ни один протокол не уходит людям неглазанным - иначе однажды уйдёт достроенная моделью фраза, и доверие к формату кончится.
5. Только потом автоматизация. Когда формат устоялся, забор расшифровки и прогон через промпт собираются в сценарий, и от тебя остаётся правка и отправка. Как подступиться к такой сборке без программиста, разобрано в пошаговом разборе n8n, а общий принцип выбора первых задач - в материале про то, с каких задач начинать автоматизацию рутины.

Второй момент: протокол хорошо живёт рядом с другими короткими документами дела. Сводка отвечает на вопрос «что происходит», протокол - «что решили». Вместе они закрывают изрядную часть того, зачем люди устраивают лишние созвоны. Какие ещё участки закрываются похожим образом, собрано в обзоре задач для ИИ-ассистента в бизнесе.

Что делать, когда решение отменили или оно не сработало?

Первый порыв - открыть старый протокол и переписать в нём строку. Лучше так не делать: новое решение пишется в новый документ, со ссылкой на отменённое и одной строкой почему.

Решение. Возвраты принимаем 30 дней. Отменяет. Решение от 12 сентября (14 дней). Почему. Отказы от покупки с прямой ссылкой на срок возврата.

Эти три строки стоят того, чтобы их написать. Без них через квартал придёт новый человек, найдёт в архиве протокол от 12 сентября и начнёт работать по нему.

Правка старого документа выглядит аккуратнее, но убивает главное свойство архива: по нему перестаёт восстанавливаться, что знали и думали на момент решения. Если очень хочется - пометь в старом протоколе строкой «отменено, см. протокол от такого-то числа», но сам текст не трогай.

Есть ещё вещь, которая начинает работать, когда протоколов накопится несколько десятков. Их можно читать как данные: какие вопросы возвращаются, какие решения не доживают до месяца, у кого сроки регулярно съезжают. Красивой аналитики тут нет, зато зеркало честное. Какие вопросы к таким данным имеют смысл, а какие дают шум, разобрано в материале про ИИ для бизнес-аналитики.

И последнее. Протокол не делает решения правильными. Его работа - сделать их видимыми: с владельцем, датой и основанием. Дальше нужен человек, который посмотрит на это и скажет: тут мы ошиблись, разворачиваемся. Модель такого не скажет. У неё нет ни вкуса, ни ответственности, ни денег в этом деле.

Источники

• Академия Claude - учебные курсы Anthropic, включая материалы по рабочим сценариям и русскоязычные версии
• Документация Anthropic - основной справочник по возможностям и ограничениям моделей Claude
• Обзор промпт-инжиниринга Anthropic - какие элементы промпта влияют на точность результата
• Быть ясным и прямым в промптах - официальная рекомендация Anthropic по формулировке инструкций
• Справочный центр Anthropic - лимиты, работа с файлами, настройки приватности
• Architecture Decision Records - инженерная практика записи решений короткими документами
• Коллекция шаблонов ADR - десятки форматов записи решения, от одного абзаца до полного разбора
• GitLab Handbook: коммуникация - публичный регламент распределённой компании о письменной фиксации договорённостей
• Shape Up, Basecamp - методика работы с решениями и границами задач в небольших командах
• Who Has the D?, Harvard Business Review - классический разбор того, что происходит с решением без явного владельца
• Anthropic: Projects - механика рабочих пространств с общим контекстом для повторяющихся задач