Общие промпты для команды: один голос компании на всех

Как собрать общие Skills, шаблоны и правила в одном месте — чтобы вся команда звучала одинаково, без бардака и дублей. Структура папок, процесс, готовые примеры.

Зачем это нужно?

Ты раскатил Claude на команду. Каждый нашёл себе пару задач, сделал свои Skills, начал экономить время. Выглядит как успех.

Через месяц открываешь папку “Отправленные” у троих менеджеров и видишь: клиент А получил письмо в одном тоне, клиент Б в другом, клиент В в третьем. Одинаковый продукт, одинаковая ситуация — три разных компании на выходе.

Это не про то, что у тебя плохие сотрудники. Это про то, что каждый учил Claude в одиночку. Один писал Skill “ответ клиенту” так, другой эдак, третий вообще без Skill пишет каждый раз заново. Результат — компания звучит на три голоса.

Лечится это одним шагом: общая библиотека. Skills, шаблоны и правила лежат в одном месте, все ими пользуются, изменения вносит один ответственный. Один раз улучшил — вся команда сразу получила улучшенную версию. Этот гайд — про то, как такую библиотеку собрать, где её хранить и как поддерживать, чтобы она не превратилась в свалку через два месяца.

Пара слов по терминам:

Skill — именованная инструкция для Claude, которую ты один раз описал и сохранил. Разобрано в отдельном гайде.
Project (Проект) — рабочее пространство Claude со своими загруженными материалами и инструкциями.
Куратор — человек, который отвечает за качество библиотеки. Решает, что добавить, удалить, переписать.
Markdown — простой формат текстовых файлов с разметкой. Skills хранятся именно в нём.
Версионирование — когда у файла хранится история изменений: кто что менял и когда, можно откатиться назад.
README — файл с описанием: что здесь лежит, как этим пользоваться, кто ответственный.

Что даёт общая библиотека

Один голос компании. Клиенту всё равно, кто именно ему ответил — Вася или Маша. Ему важно, чтобы это звучало как одна компания. Общий Skill на письма клиенту даёт именно это: тон, структура, обязательные фразы — одинаковые у всех.

Новички не учатся с нуля. Пришёл новый менеджер — забрал готовые Skills из библиотеки и через час уже пишет письма в корпоративном стиле. Без “вот Вася у нас тут шаман, он покажет”.

Улучшения масштабируются. Кто-то нашёл, как улучшить Skill “ответ на жалобу” — добавил фразу, которая реально снимает напряжение. Один раз поменял в библиотеке — вся команда со следующего дня пишет лучше.

Знания не уходят с людьми. Если уходит менеджер, у которого были свои крутые Skills у него на ноутбуке — команда теряет их вместе с ним. Если те же Skills лежат в общей библиотеке — не теряет ничего.

Но есть и обратная сторона. Если кто-то добавил в библиотеку Skill с ошибкой — все используют ошибку. Если никто за библиотекой не следит — там накапливается мусор, и через полгода никто не может ничего найти. Поэтому дальше в гайде половина текста — не про папки, а про процесс поддержки.

Что именно хранится в библиотеке

Библиотека — это не “папка со всеми промптами”. Это четыре разные штуки, которые стоит хранить отдельно.

1. Skills. Готовые инструкции для повторяющихся задач. Письмо клиенту, ответ на жалобу, коммерческое предложение, пост для соцсетей, отчёт руководителю. Каждый Skill — это отдельный файл с чётким названием и описанием.

2. Шаблоны проектов (Projects). Если у тебя корпоративный план Claude, можно делать шаблоны Projects — уже настроенных рабочих пространств с загруженными материалами (прайсы, FAQ, база клиентов, примеры хороших писем) и инструкциями. Сотрудник получает готовый Project и сразу начинает работать, а не собирает его с нуля.

3. Шаблоны промптов. Это не Skills. Это просто текстовые заготовки, которые удобно быстро скопировать в чат Claude и подставить свои детали. Например, промпт “суммаризируй звонок” с плейсхолдерами “[имя клиента]”, “[тема встречи]”. Делать из этого Skill — оверкилл, а иметь под рукой — полезно.

4. Правила “чего НЕ делать”. Список типовых ошибок и того, как их избегать. Это не инструкция Claude — это инструкция команде. “Не отправлять письма с фразой ‘Доброго времени суток’”, “Не обещать скидки без согласования”, “Не отвечать на жалобы в пятницу вечером без проверки”. Хранится отдельно, потому что это правила для людей, а не для AI.

Когда ты путаешь эти четыре типа и валишь всё в одну кучу — библиотека становится нечитаемой через месяц. Каждый тип живёт в своей папке.

Где хранить: четыре варианта

У тебя есть четыре реалистичных варианта. Я расскажу, что каждый даёт и кому подходит.

Вариант 1: Claude Projects (корпоративный план). Если у команды подписка Claude Team или Enterprise — Projects можно шарить через саму платформу. Создал Project, настроил права (“только использовать” или “можно редактировать”), выдал доступ команде. Один человек обновил инструкцию — все сразу получили обновление, без ручного копирования. Это самый удобный вариант и естественный механизм кураторства: редактирование только у куратора, остальные на чтение. Минус один: нужен корпоративный план. Персональные Pro-подписки шарить Projects между аккаунтами не умеют.

Вариант 2: общая папка в облачном хранилище. Google Drive, Яндекс Диск, Dropbox — что уже есть у команды. Внутри — структура с файлами Skills в формате Markdown. Каждый скачивает нужные файлы и импортирует к себе в Claude. Плюс: работает с любой подпиской, не требует ничего покупать. Минус: нет автоматической синхронизации. Обновил Skill — нужно анонсировать команде, люди забывают перекачивать. Это самый реалистичный вариант для большинства команд без корпоративного Claude.

Вариант 3: внутренний wiki (Notion, Confluence). Если у команды уже есть Notion или Confluence — Skills можно хранить страницами в wiki. Плюс: удобный поиск, комментарии, история версий прямо в платформе. Минус: Skills всё равно нужно вручную переносить в Claude — скопировал, вставил. Дополнительный шаг каждый раз. Подходит командам, у которых Notion уже центр всей документации.

Вариант 4: GitHub (репозиторий). Репозиторий — это папка с файлами, где хранится история всех изменений: кто, когда, что поменял. Плюс: полное версионирование, возможность предложить изменение через pull request (запрос на изменение, который куратор одобряет или отклоняет). Минус: для нетехнической команды слишком сложно. Менеджеры по продажам pull request’ы делать не будут. Порог входа высокий. Подходит только командам, где половина уже живёт в GitHub.

Что выбрать. Есть корпоративный Claude — Projects. Нет, но есть общий облачный диск — облачная папка. Вся документация в Notion — Notion. Команда техническая — GitHub. Большинству команд подходит второй вариант, дальше в гайде исхожу из него.

Структура папок библиотеки

Вот конкретный пример структуры, с которой стоит начать. Она простая, её легко понять любому новичку, и она масштабируется до 50+ Skills без превращения в свалку.

Claude-библиотека/
├── README.md
├── skills/
│   ├── README.md
│   ├── email-клиенту-стандартный.md
│   ├── ответ-на-жалобу.md
│   ├── коммерческое-предложение.md
│   ├── пост-для-соцсетей.md
│   └── сводка-по-звонку.md
├── projects/
│   ├── README.md
│   ├── проект-продаж/
│   │   ├── instructions.md
│   │   ├── примеры-хороших-писем/
│   │   └── правила-компании.md
│   └── проект-поддержки/
│       ├── instructions.md
│       └── база-типовых-вопросов.md
├── prompts/
│   ├── README.md
│   ├── суммаризация-звонка.md
│   ├── подготовка-к-встрече.md
│   └── разбор-обратной-связи.md
└── rules/
    ├── что-не-делать.md
    ├── тон-компании.md
    └── слова-под-запретом.md

Что здесь важно:

README на верхнем уровне — это твой главный файл. В нём написано: зачем эта библиотека существует, кто куратор, как предложить изменение, как импортировать Skills к себе в Claude. Любой новичок открывает именно его и за 5 минут понимает, как пользоваться.

README в каждой подпапке — короткий список того, что внутри, с одной фразой описания на каждый файл. Без него через два месяца никто не будет помнить, что делает skill “сводка-по-звонку” и чем он отличается от “сводки-по-встрече”.

Имена файлов — человеческие, на русском. Не “skill_01_v3_final.md”, а “email-клиенту-стандартный.md”. Через дефис, без пробелов, понятно по названию.

Никаких файлов в корне, кроме README. Всё остальное — в соответствующих папках. Это базовая гигиена, но её постоянно нарушают.

Процесс поддержки библиотеки

Библиотека без процесса — это свалка. Через месяц там лежат три версии одного и того же Skill, половина устарела, никто не знает, чем пользоваться. Лечится это тремя вещами: ролями, процессом изменений и регулярной чисткой.

Роли

Куратор (1 человек). Часто это сам руководитель команды или HR. Принимает решения: что добавить, что удалить, что переписать. Отвечает за качество библиотеки. Занимает 30-60 минут в неделю — это не отдельная должность, это нагрузка поверх основной работы.

Принципиально важно: куратор один. Не двое, не трое, не “все решаем вместе”. Когда за качество отвечают все — не отвечает никто. Если нужен второй мозг для консультаций — ок, но финальное решение всегда за одним человеком.

Авторы — вся команда. Любой сотрудник может предложить новый Skill или изменение существующего. Это не иерархия, это просто разделение ответственности.

Пользователи — тоже вся команда. Все пользуются тем, что лежит в библиотеке.

Процесс добавления нового Skill

Автор создаёт Skill у себя — в личной папке, не сразу в библиотеке. Пробует на 3-5 реальных задачах за пару недель.
Если работает стабильно — отправляет куратору: “Вот Skill, вот примеры использования, предлагаю добавить, потому что [причина]”.
Куратор проверяет: соответствует ли тону компании, нет ли фактических ошибок, полезен ли не только автору, не дублирует ли существующие.
Если ок — добавляет файл в библиотеку, обновляет README соответствующей папки и пишет короткий анонс команде: “Добавил новый Skill ‘X’, используется для Y, забирайте”.
Через 2 недели собирает обратную связь: работает ли у всех, чего не хватает.

Процесс изменения существующего Skill

Любой может предложить изменение: “В Skill ‘X’ предлагаю заменить [это] на [это], потому что [причина]”.
Куратор рассматривает. Если согласен — меняет, если нет — объясняет почему.
После изменения — обязательно анонс: “Skill ‘X’ обновлён, новая версия здесь. Что изменилось: [список]. Старую версию не используйте”.

Критичный момент: без анонса изменений библиотека не работает. Люди не обновляют Skills по расписанию — они работают со своей локальной копией. Если не сказал “обновилось” — продолжают пользоваться старой версией. Анонс в общий чат команды — обязательная часть процесса.

Гигиена библиотеки (раз в квартал)

30 минут раз в три месяца — куратор садится и проходит по библиотеке:

Удали Skills, которыми никто не пользуется уже 2 месяца. Спроси в команде: “Кто пользовался Skill X за последний месяц?”. Если никто — удаляй. Мёртвые Skills засоряют библиотеку, их нужно удалять без сожалений.
Актуализируй то, что работает плохо. Собери жалобы (“Skill Y почему-то выдаёт ерунду в половине случаев”) — разберись и поправь.
Проверь, нет ли дубликатов. Если два Skills делают примерно одно и то же — выбери лучший, второй удали.
Обнови README. После всех изменений пройдись по списку файлов и убедись, что описания актуальные.

Если куратор не делает чистку — через полгода библиотека становится нечитаемой. Это не про “найти время”, это про регулярность.

Частые ошибки при построении библиотеки

Ошибка 1: нет куратора. “Давайте все решаем вместе”. Через месяц никто ни за что не отвечает, Skills добавляются хаотично, качество падает. Библиотека превращается в свалку.

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

Ошибка 2: нет структуры. Все файлы в одной папке, имена типа “skill1.md”, “skill2.md”. Через месяц никто ничего не находит.

Правильно: структура из примера выше, человеческие имена, README в каждой папке.

Ошибка 3: нет правил добавления. Любой может запихнуть что угодно в общую папку. Качество среднее по палате, потому что качество самого слабого участника = качество всей библиотеки.

Правильно: новый Skill проходит через куратора, даже если это занимает пару дней.

Ошибка 4: нет анонсов изменений. Куратор обновил Skill, а команде не сказал. Половина продолжает пользоваться старой версией, потому что они её скачали неделю назад.

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

Ошибка 5: слишком много сразу. “Давайте за первый месяц сделаем 50 Skills”. К концу месяца — 50 средних Skills, никто не знает, чем именно пользоваться, каждый выбирает своё.

Правильно: 5 отличных Skills в первый месяц лучше, чем 50 средних. Начни с самых частых задач, доведи их до отличного качества, потом добавляй следующие.

Ошибка 6: копировать чужие библиотеки целиком. “Нашёл в интернете готовый набор из 200 промптов, давайте возьмём”. Чужие промпты написаны под чужой тон, чужой продукт, чужих клиентов. У тебя они работать не будут или будут работать странно.

Правильно: черпай идеи из чужих библиотек (какие задачи вообще стоит покрывать), но писать Skills нужно самим — под свой продукт, свой тон, своих клиентов.

Если ты собираешь библиотеку для большой команды (20+ человек) и чувствуешь, что тонешь в вариантах организации — напиши мне на /consult, разберём твою ситуацию: какой вариант хранения, какая структура, какой процесс поддержки подойдут именно тебе.

Три готовых Skills для старта

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

Skill 1: email-клиенту-стандартный

Для менеджера продаж. Черновик письма клиенту в ответ на входящий запрос.

---
name: email-клиенту-стандартный
description: Написать черновик ответа клиенту по стандарту компании. Использовать, когда клиент прислал запрос или вопрос и нужен типовой ответ в корпоративном тоне.
---

Ты помогаешь менеджеру продаж написать черновик письма клиенту.

Тон: дружелюбно, но по-деловому. Без панибратства, без канцелярита. Никаких "Доброго времени суток", "Уважаемый клиент", "Заранее благодарю". Не начинай со "Спасибо за обращение" — это штамп. "вы" с маленькой буквы.

Структура:
1. Приветствие по имени, если имя известно. Иначе — "Здравствуйте".
2. Одна фраза, которая показывает, что я прочитал суть обращения.
3. Прямой ответ на вопрос. Без воды.
4. Если нужно — 2-3 пункта с деталями (сроки, цены, условия).
5. Одно конкретное следующее действие ("пришлите документы", "созвонимся завтра в 14:00").
6. Подпись: "С уважением, [имя], [должность], [компания]".

Длина основной части: не больше 6-7 предложений. Клиент должен прочитать письмо за 30 секунд.

Чего нельзя:
— Обещать скидки, если я не разрешил.
— Давать оценки сроков "наобум" — только если я их указал.
— Упоминать конкурентов.
— Восклицательные знаки (максимум один в приветствии).

После основного варианта предложи один альтернативный — на 3-4 предложения, для случая когда клиенту нужен только факт без объяснений.

Skill 2: ответ-на-жалобу

Для поддержки. Когда клиент недоволен и нужен аккуратный ответ.

---
name: ответ-на-жалобу
description: Написать ответ на жалобу клиента. Использовать, когда клиент выразил недовольство — сорванный срок, плохой продукт, наша ошибка. Задача — снять напряжение и предложить решение.
---

Ты помогаешь сотруднику поддержки ответить на жалобу.

Главный принцип: сначала признать проблему, потом решить, потом объяснить. Не наоборот. Если начать с объяснений — клиент решит, что мы оправдываемся.

Структура:
1. Обращение по имени.
2. Признание проблемы. Одна честная фраза без виляния. Слова подбираем под серьёзность: мелкая проблема — "мы недоработали", серьёзная — "это наш просчёт".
3. Конкретное решение. Что мы делаем прямо сейчас — глагол действия и срок: "вернём деньги до конца дня", "переделаем за свой счёт к пятнице".
4. Если уместно — компенсация (скидка, бонус). Только если я разрешил.
5. Короткое объяснение, как так получилось — 1-2 фразы, без технической кухни.
6. Извинение в конце, не в начале. Последняя строка перед подписью.

Чего нельзя категорически:
— Оправдываться ("у нас был тяжёлый день", "новый сотрудник").
— Перекладывать вину ("поставщик подвёл", "курьерская служба").
— Обещать "больше такого не повторится".
— Фразы "приносим извинения за доставленные неудобства", "ваше обращение важно для нас".
— Начинать со слова "Но" или "Однако".

Тон: спокойный, взрослый, уверенный. Не пресмыкаемся, но и не защищаемся. Нормальные взрослые люди, которые ошиблись и исправляют.

После основного варианта покажи смягчённую версию — для случая когда клиент очень сильно расстроен.

Skill 3: пост-для-соцсетей

Для маркетинга. Когда нужен пост в корпоративные соцсети по конкретной теме.

---
name: пост-для-соцсетей
description: Написать пост в корпоративные соцсети по заданной теме. Использовать, когда нужен полезный пост для аудитории — кейс, разбор, анонс, наблюдение.
---

Ты помогаешь маркетологу написать пост в соцсети компании.

Формат:
1. Первая строка — hook. Одна фраза, которая заставляет не пролистать: резкое наблюдение, конкретная цифра или провокационный вопрос. Никаких "Друзья, хотим поделиться...", "В сегодняшнем посте расскажем..." — это гарантированное пролистывание.
2. Контекст — 1-2 предложения: о чём пост, кому полезен.
3. Основная часть — 3-5 абзацев. Каждый абзац — одна мысль. Между абзацами пустые строки.
4. Если есть список — не больше 5 пунктов, короткие, с нейтральными маркерами.
5. Последняя строка — вопрос читателю или конкретный CTA.

Длина: 120-250 слов.

Тон: эксперт, который разговаривает с равным. Не снисходительно, не заискивающе. По делу, со своей позицией.

Запрещённые слова и фразы:
— "В современном мире", "в эпоху цифровизации".
— "Команда профессионалов", "высокое качество", "индивидуальный подход".
— "Революционный", "инновационный", "не имеющий аналогов".
— "Рады сообщить", "с удовольствием анонсируем".
— Любые канцеляризмы.

Чего не делать:
— Больше одного эмодзи на абзац.
— ВСЁ ЗАГЛАВНЫМИ.
— Хэштеги внутри текста — только в конце, максимум 3 штуки.

После основного варианта предложи 2 альтернативных hook'а.

Важно: эти Skills — стартовый набор. Их нужно адаптировать под твой тон, твой продукт, твоих клиентов. Не копируй как есть — прочитай, пойми логику, перепиши детали под себя. Через 2-3 недели использования ты сам поймёшь, что в них не так именно для вашей команды, и улучшишь.

С чего начать на этой неделе

Не пытайся построить всю библиотеку сразу. Разбей на шаги.

День 1. Реши, где будет жить библиотека. Есть корпоративный Claude — Projects. Нет — общая папка в облачном диске. Создай корневую папку “Claude-библиотека”.

День 2. Создай структуру подпапок (skills, projects, prompts, rules) и пустой README на верхнем уровне с описанием: что это, зачем, кто куратор.

День 3. Назначь куратора — открытым сообщением в команду. Не “давайте подумаем”, а “с сегодняшнего дня за библиотеку отвечает [имя]”. Без этого шага процесс не заработает.

Неделя 1. Куратор добавляет первые 3-5 Skills из самых частых задач команды.

Неделя 2-3. Команда пользуется. Куратор собирает обратную связь, корректирует Skills.

Месяц 2. Добавляются новые Skills по запросам команды. Тем, кто предложил — спасибо публично. Это создаёт культуру: предлагать улучшения поощряется.

Месяц 3. Первая квартальная чистка. Удаляется неактуальное, обновляется README.

Через квартал у тебя будет живая библиотека, которой реально пользуются. Не идеальная — но работающая. Это и есть цель.

Что ты только что получил

У тебя есть конкретный план: где хранить, как структурировать, кто отвечает, как добавлять новое, как поддерживать. И три готовых Skill’а, чтобы начать прямо сегодня.

Главное, что меняется после внедрения библиотеки: команда перестаёт звучать на десять голосов. Клиенты начинают ощущать компанию как одно целое. Новые сотрудники включаются в неделю, а не в квартал. И улучшения, которые нашёл один — получают все.

Следующий шаг

Библиотека работает, команда пользуется. Но как понять, окупается ли вся эта история? Подписка стоит денег, время на поддержку тоже стоит денег. Следующий гайд — метрики AI в команде: три простых показателя (часы, рубли, оценка команды), которые честно покажут, есть ли эффект. Без бюрократии и без 40-слайдных презентаций.

Для тех, кто хочет разобраться глубже

Этот раздел необязательный. Для работы с библиотекой хватит всего, что выше.

Почему именно Markdown. Skills хранятся в текстовых файлах в формате Markdown — простая разметка, где заголовки начинаются с решёток, списки с тире. Формат понимает Claude напрямую (не нужно конвертировать), его можно читать в любом текстовом редакторе, он не ломается между программами и легко сравнивается построчно. В отличие от Word или PDF — для библиотеки это идеально.

Что такое версионирование. Это когда система сама запоминает каждое изменение файла: кто, когда, что поменял. Можно откатиться на старую версию одним кликом. В Google Drive и Яндекс Диске базовое версионирование уже есть (правый клик — “история версий”). В GitHub оно полноценное. В Notion встроено прямо в интерфейс страницы. Для библиотеки Skills это критично: ты не хочешь потерять работающую версию из-за неудачного эксперимента.

Как работают Projects в корпоративных планах Claude. В планах Claude Team и Enterprise Project можно расшарить конкретным людям или всей организации. Права разные: “Can use” (только пользоваться) и “Can edit” (редактировать). Это встроенный механизм кураторства: куратор редактирует, остальные используют. Обновления применяются мгновенно — как только куратор поправил инструкции, все работают с новой версией. Персональные Pro такого не умеют.

Почему облачная папка хуже Projects, но лучше, чем ничего. Проблема одна: Claude не читает файлы из Google Drive напрямую. Сотрудник должен скачать Markdown-файл и положить его себе в папку Skills. Когда куратор обновил файл — сотрудник не узнает, пока не сказали. В Claude Projects обновление автоматическое. Но облачная папка не требует корпоративной подписки, а это часто решающий фактор.