Рекрутер
Что движется по вакансиям, где срывается срок и чьё решение требуется. Отделяем работу рекрутера от ожидания руководителя.
Видеть исполнение.
Принимать решения.
Персональный агент Антона для контроля рекрутера и руководителей отделов: задачи, метрики, отчёты и договорённости — в одной проверяемой сводке.
Руководители
Сданы ли отчёты, выполнены ли обещания, где отклонение от плана. Для каждого отдела — свои определения показателей.
Решения Антона
Факт, источник, вопрос, следующее действие. Агент готовит картину исполнения; решение остаётся за собственником.
01Источники
Таблицы · чаты · встречи
02Правила
Периоды · сроки · метрики
03Проверка
Факт · пробелы · отклонения
04Сводка
Решения · вопросы · действия
Пример формата, данные вымышлены
Что увидит собственник
Нужно решение
По вакансии А ожидается обратная связь руководителя.Зависимость от нанимающего руководителя. В реальном отчёте: ссылка на договорённость, срок и дата последней проверки.
Просрочено
По задаче Б истёк согласованный срок, подтверждения выполнения нет.Вопрос рекрутеру: что сделано, что блокирует и какой следующий шаг? Отсутствие подтверждения не доказывает отсутствие работы.
Недостаточно данных
В таблице есть принятый оффер, фактический выход ещё не подтверждён.Не включаем его в показатель выходов. Запрашиваем статус по утверждённому определению метрики.
Нет свежих данных
Отдел А: отчёт за текущий период не найден.Это пробел отчётности. Нельзя сделать вывод о выполнении плана по прошлой неделе.
Отклонение
Отдел Б: факт ниже согласованного плана.В реальном отчёте: показатель, период, формула, дельта и ссылка на диапазон. Причина пока требует подтверждения.
На проверке
Руководитель сообщил о выполнении поручения.Проверяем результат по критерию приёмки и сохраняем подтверждение. Сообщение «готово» само по себе недостаточно.
Первый релиз: один рекрутер, одна таблица, выбранные чаты. Сначала ручная сверка, затем расписание; после приёмки — один отдел.
Как читать план
Существует → адаптировать — навыки уже есть в Workspace или HappyM.
Предлагается → разработать — название и сценарий, готового скилла пока нет.
Подключение → проверить — требуется настройка в аккаунте Антона.
БЛОК 01
Контроль исполнения
Подтверждённая задача: дать Антону регулярную картину исполнения: что обещали, что сделали, где отклонение от плана, чего не хватает в отчётах и какое решение требуется от собственника. Агент готовит проверяемые сигналы и вопросы; управленческие и кадровые решения принимает Антон. Количество сообщений в чате не является показателем качества работы.
0.1. Что нужно определить один раз
Реестр ролей и отделов: кто сдаёт какой отчёт, куда, с какой периодичностью и к какому сроку. Состав отделов уточнить, не переносить старую структуру автоматически.
Паспорт каждого показателя: определение, единица, формула, период, источник, план, направление «лучше/хуже», порог сигнала и владелец. Не все показатели суммируются: различать количество за период, остаток на дату и конверсию.
Единый реестр задач: ID, роль ответственного, ожидаемый результат, срок, статус, подтверждение выполнения, блокер, ссылка на исходную договорённость. Перенос срока хранить в истории.
Карта источников: таблица — источник цифр; чат — договорённости и пояснения; протокол встречи — решения. Конфликтующие значения показывать рядом, а не выбирать молча.
Границы доступа и обработки: для пилота использовать синтетические или обезличенные агрегаты. Персональные данные кандидатов/сотрудников и индивидуальные оценки — только по whitelist-правилам компании; не включать их в публичную демонстрацию.
0.2. Контроль рекрутера — первый пилот
Предлагаемый новый скилл recruiting-control собирает картину по согласованным вакансиям и задачам. Готового скилла пока нет. Он использует общие правила numbers-review и chat-digest, не дублирует их расчёты и извлечение.
Кандидаты на показатели, которые нужно утвердить с Антоном:
| Что смотреть | Как читать показатель | Что получает Антон |
|---|---|---|
| Активные вакансии и их возраст | От даты согласованного открытия до даты отчёта; отдельно приоритет и плановая дата закрытия | Вакансии без движения и риск срыва срока |
| Воронка подбора | Отклики → скрининг → интервью → офферы → принятые офферы → фактические выходы; определить, какие этапы реально ведутся | Где теряется поток; гипотезы причин отдельно от фактов |
| План/факт по результату | Фактические выходы и закрытия по согласованному определению; принятый оффер не приравнивать к выходу | Дельта к плану и вопросы по незакрытым позициям |
| Конверсии | Для согласованной когорты и окна наблюдения; деление на ноль → «нет базы», не 0% | Корректные сравнения без смешения разных недель |
| Задачи и обратная связь | Просроченные обещания рекрутера и ожидание ответа нанимающего руководителя показывать отдельно | Что может сделать рекрутер и где нужно вмешательство Антона |
Выход: краткая сводка по вакансиям, просрочкам, внешним блокерам и решениям Антона. У каждого сигнала — период, источник, дата обновления и конкретное отклонение. Это контроль процесса, не автоматический рейтинг сотрудника. candidate-research/eval-screening/response-screening не заменяют этот сценарий: они решают другие задачи.
0.3. Контроль руководителей — масштабирование после пилота
Предлагаемый новый скилл management-control использует единый формат отчёта и отдельные паспорта показателей для каждого отдела.
Проверяет, сдан ли отчёт в срок, заполнены ли обязательные поля и свежие ли данные.
Сравнивает план/факт и динамику по определённым правилам; не сравнивает напрямую несопоставимые отделы.
Сопоставляет обещания на планёрке со статусом задач и подтверждением результата. «Выполнено» без подтверждения — отдельный статус проверки.
Выделяет повторяющиеся отклонения, переносы сроков, зависимости между отделами и вопросы собственнику.
Готовит повестку встречи: факт → вопрос руководителю → требуемое решение. Причина отклонения считается подтверждённой только при наличии источника.
Шаблон отчёта руководителя: период; показатель/план/факт/источник; задачи со сроками и результатом; блокеры; пояснения; решения, которые нужны от Антона. Для старта достаточно Google-таблицы; CRM не обязательна.
0.4. Предлагаемые повторяющиеся задачи
Время ниже — проект для обсуждения, не созданные расписания. Перед включением согласовать часовой пояс Антона и сроки сдачи отчётов. Не запускать каждую проверку отдельным агентом по сотруднику или показателю.
| Задача | Когда предлагается | Что делает | Результат |
|---|---|---|---|
| Проверка готовности отчётов | После согласованного срока сдачи | Проверяет наличие, полноту, свежесть и доступность источников | Список пробелов; «нет данных» не означает «плохая работа» |
| Ежедневный контроль | Будни, 11:00, если отчёты уже доступны | Одним проходом обновляет задачи из выбранных чатов и цифры, запускает контроль рекрутера; позже — отделов | Одна сводка Антону: новые отклонения, просрочки, блокеры и решения |
| Подготовка к планёрке | Например, понедельник 10:30, если встреча в 11:00 | Сводит данные за завершённую неделю и незакрытые договорённости | Повестка с вопросами и источниками |
| Контроль решений встречи | Следующим ежедневным запуском после появления протокола | Добавляет подтверждённые поручения, сохраняет сроки и критерии | Обновлённый реестр без дублирования задач |
Ежедневную сводку выдавать по согласованному расписанию; дополнительные уведомления — только о новых существенных отклонениях, изменении статуса или сбое. Один и тот же сигнал не рассылать повторно без изменений. Напоминания сотрудникам готовить как черновики; автоматическую отправку отдельно согласовать по получателям, содержанию и правилам.
0.5. Надёжность и приёмка
Хранить отметку последнего успешного чтения отдельно по источникам. После сбоя дочитывать пропущенный период, включая выходные; удалять дубли по ID источника/задачи.
Если источник недоступен или устарел — явно показывать неполное покрытие, не выдавать старые цифры за текущие. Порог просрочки не назначать без согласования.
Расчёты выполнять формулами/кодом с контрольными итогами. Текстовые выводы привязывать к сообщениям, строкам отчёта или протоколу.
Пилот: один рекрутер, одна таблица и выбранные рабочие чаты, затем один отдел. Сначала ручная сверка, затем расписание; расширение — после приёмки.
До запуска проверить на синтетических примерах: дубль поручения; перенесённый срок; пропущенный отчёт; недоступный чат; нулевой знаменатель; оффер без выхода; задача заблокирована другим отделом; сообщение за выходные. Ожидаемый результат каждого примера фиксируется заранее.
Критерий пилота: все контрольные примеры обработаны по утверждённым правилам, цифры совпадают с ручной сверкой, есть ссылки на источники, нет пропавших/дублированных задач и ложных отметок выполнения. Проверка на новом наборе примеров и финальная приёмка — человеком; независимая проверка по правилам
automate.Эффект измерить по времени подготовки сводки до/после, числу пропущенных договорённостей и доле сигналов, потребовавших исправления. Не обещать рост эффективности до замера.
БЛОК 02
Существующие скиллы
Основной набор
Onboarding из HappyM — основа для переноса и последующей адаптации.
Решение Кристины от 28.09.2026: использовать существующий happym-onboarding из sergevalovoi/happym-workspace, а не разрабатывать предложенный ранее owner-onboarding на основе team-onboarding.
Источник: SKILL.md HappyM ↗. Скилл прочитан на GitHub; адаптация пока не выполнялась, финальное имя не выбрано.
Обязательный результат для Антона: заполненные роль в компании, приоритетные задачи, метрики и прохождение теста по моделям поведения с формированием AGENT-PERSONALITY.md.
В текущем HappyM уже есть интервью о роли, метрике и 2–3 трудоёмких задачах. При адаптации отдельно добавить приоритеты, период и план/факт по метрикам, если известны; отсутствующие значения не придумывать.
Аудит и Talent Q — необязательные источники. Готового JSON у Антона, вероятно, нет: он проходит tools/behavior-profile-tool.html и экспортирует новый behavior-profile-*-with-agent.json. Файл содержит профиль человека и рассчитанный профиль ассистента. Отсутствие аудита не мешает этому пути.
Перенести вместе со скиллом сам HTML-тест, reference/behavior-compensation-table.md и reference/ai-maturity-levels.md. По инструкции тест занимает около 16 минут и включает 50 раундов; экспорт подтверждён чтением кода, прохождение теста в браузере пока не проверялось.
Исправить необязательность поведенческой части: в версии Антона тест — обязательный этап завершения онбординга. Если прерван, сохранить прогресс и вернуться; не подменять профиль предположениями.
Адаптировать HappyM/Claude-контекст, пути и перечень доступных скиллов под Антрекот/Codex; убрать ссылки на чужой аудит как факт об Антоне. Согласовать структуру файлов контекста; результаты теста и личный профиль хранить локально вне Git.
remember — память и сохранение решений.Назначение: сохранять договорённости, причины решений и правила; находить их в следующих задачах без повторного объяснения.
Адаптация: проверить работу в Codex, настроить чтение индекса памяти и исключение личных данных из Git.
polish — доводка рабочих текстов.Назначение: сообщения команде, письма партнёрам, поручения, выступления.
Адаптация: примеры под собственника, понятные критерии качества, ограниченное число итераций. Не добавлять вымышленные факты ради убедительности.
lightresearch — поиск информации и сравнение вариантов.Назначение: справки, поиск поставщиков и решений, сравнение предложений с источниками.
Адаптация: убрать зависимость от недоступного Workflow и обязательного запуска множества агентов; сделать простой рабочий сценарий поиска и проверки в Codex.
automate — мастер создания автоматизации.Назначение: вести Антона от «делаю это регулярно руками» до проверенного рабочего процесса; подробный маршрут — в разделе 3.
Адаптация: исправить инструменты, команды и пути под Codex; убрать чужой контекст; добавить этап настройки расписания.
Служебные скиллы для automate
automation-log — сохранять ход сборки, решения, ошибки и следующий шаг отдельно для каждого процесса.automation-report — собирать итог пилота: что работает, как проверено, ограничения, фактический эффект. Убрать обязательную форму отчёта сотрудника Сержу.run-log — фиксировать реальные прогоны и время ручного/агентского выполнения. Не придумывать экономию времени без исходного замера.Эти три скилла положить в комплект как зависимости мастера. Антону не требуется изучать их как отдельные команды.
Инструкции подключения — использовать как основу
hands-setup — переработать под доступные инструменты Codex для файлов и браузера.gdrive-connect — переписать под реальное подключение Google Drive/Sheets в Codex.telegram-mcp-setup — актуализировать сервер, команды, ОС, хранение авторизации и проверку доступа.calendar-gmail-mcp-setup из пакета Metz — использовать опыт настройки календаря; почту не включать автоматически.По потребности после старта
voice-transcribe — если Антон регулярно даёт голосовые или работает с аудиозаписями. Проверить зависимости и пути; не дублировать Granola там, где уже есть готовый транскрипт.reflect — недельный разбор приоритетов, решений и результатов собственника.prototype — простые калькуляторы, дашборды и прототипы под конкретный запрос.council — несколько точек зрения на сложное решение; отдельное согласование многoагентного запуска и бюджета.Техническая оговорка: адаптация не сводится к замене слова Claude на Codex. В текущих инструкциях встречаются чужие команды, .Codex/skills, описание сервисов Anthropic и отсутствующие инструменты. Нужно проверить также вспомогательные скрипты, шаблоны и ссылки. Текущий token-report не включать как готовый: его скрипт читает логи Claude.
БЛОК 03
Новые скиллы
Все названия в этом разделе рабочие. Готовых файлов этих скиллов в предлагаемом комплекте пока нет. Приоритет определить на онбординге; необязательно писать их все до первого урока.
recruiting-control — приоритет №1: контроль процесса подбора. Объединяет метрики, задачи, сроки и блокеры рекрутера; правила и состав показателей — раздел 0.2. Использует общие навыки извлечения и проверки цифр.management-control — контроль отчётности и исполнения по отделам. После пилота рекрутера: единый реестр задач, отдельные паспорта показателей и сводка вопросов Антону; раздел 0.3.delegate — постановка задач команде.Вход: мысль, текст или расшифровка голосового Антона.
Выход: поручение с результатом, контекстом, ответственным, сроком, ограничениями и критерием приёмки.
Если срок или ответственный не названы — уточнить либо явно отметить пробел. Подготовка текста не означает его отправку.
meeting — подготовка к встречам и разбор итогов.До встречи: собрать цель, историю договорённостей, открытые вопросы, необходимые цифры и повестку.
После встречи: выделить решения и задачи из заметок/транскрипта, приложить источник, сохранить договорённости.
Источники: календарь, документы, выбранные чаты, Granola при подключении.
numbers-review — разбор управленческих отчётов.Вход: конкретная таблица и согласованные определения показателей.
Выход: план/факт, отклонения, проверка расчётов и вопросы ответственным.
Начать с одного отчёта Антона. Не зашивать предполагаемые KPI и не объяснять причины отклонений как факты без подтверждения.
chat-digest — задачи и договорённости из рабочих чатов.Вход: выбранный список чатов и период с последнего успешного сбора.
Выход: новые задачи, договорённости, сроки, ответственные и вопросы, требующие решения Антона, со ссылками на сообщения.
Нужны правила удаления дублей, учёта выходных, обработки недоступных чатов и хранения отметки обработанного периода.
Это хороший кандидат для первой автоматизации, если Антон подтвердит ценность сценария.
daily-brief — сводка собственника из нескольких источников.Объединяет встречи дня, открытые вопросы из чатов, итоги встреч и выбранные показатели.
Добавлять после того, как отдельные источники и правила работают. Для первого пилота достаточно chat-digest.
workspace-setup — единый мастер настройки и диагностики.Собрать из существующих инструкций подключения; общий скилл ещё нужно разработать.
Проверяет окружение, ведёт через авторизацию, выполняет тесты и записывает, какие источники реально доступны.
Не обещает готовность по статусу «Connected»: подтверждает её чтением тестового файла, сообщения или события.
БЛОК 04
Автоматизация
automate — мастер создания процесса. chat-digest или другой рабочий скилл — результат его работы. Автоматизация Codex — механизм запуска этого результата по расписанию.
Маршрут мастера:
1
Паспорт задачи: что повторяется, как часто, кто использует результат, сколько времени занимает сейчас.
2
Декомпозиция: шаги, входы и выходы; где нужны расчёты, отбор информации или решение человека.
3
Правила: что включать, что исключать, как действовать при неполных и противоречивых данных.
4
Источники: необходимые файлы, чаты, таблицы, MCP/плагины; проверка доступа.
5
Формат результата: шаблон сводки/отчёта и место сохранения.
6
Критерии приёмки: тестовые примеры, ожидаемый результат, критические ошибки.
7
Сборка и проверка: создать рабочий скилл и необходимые скрипты, выполнить ручной запуск, исправить ошибки, проверить на новых примерах.
8
Расписание: задать дни, время, часовой пояс, место результата, уведомления и поведение при пропуске запуска/недоступности источника.
9
Приёмка Антоном: подтвердить качество, зафиксировать ограничения и измеренный эффект.
Пример: «Каждый будний день в 11:00 собирать новые задачи и договорённости из согласованных чатов». На каждом запуске агент выполняет готовую инструкцию, а не проводит интервью заново.
Расписание — встроенная возможность Codex. Для него не требуется отдельный «cron-скилл». Скилл и шаблоны можно распространять через GitHub; авторизация и расписание настраиваются в окружении Антона. До запуска проверить доступность среды выполнения и MCP в назначенное время; не обещать работу на выключенном устройстве с локальным сервером. Документация задач по расписанию ↗.
БЛОК 05
Подключения
Часть потребностей закрывается готовыми плагинами Codex, часть — отдельными MCP-серверами. В GitHub размещаем инструкции, шаблоны конфигурации и сведения о проверенных версиях, а не авторизацию Антона.
Приоритетные подключения
GitHub — подключаем к Codex прямо на первом уроке.
Для доступа к репозиторию стартового агента, получения Workspace и последующих обновлений скиллов и инструкций.
На уроке: подключить аккаунт GitHub к Codex, проверить доступ к нужному репозиторию, клонировать его и открыть папку как Workspace.
Подключение GitHub и локальное клонирование проверить отдельно: доступ к репозиторию через интеграцию не заменяет проверку работы Git на устройстве.
До урока команда готовит репозиторий и выдаёт Антону необходимый доступ. Подключение выполняем вместе с ним, а не оставляем обязательным домашним заданием перед уроком.
Google Drive + Google Таблицы.
Для документов, планов, отчётов и показателей.
Предпочтительный путь: доступный официальный Google Drive plugin, который охватывает Drive, Docs, Sheets и Slides.
Проверка: найти тестовый документ, прочитать заданный диапазон, отдельно проверить запись на копии таблицы.
Telegram.
Для чтения выбранных рабочих чатов, поиска договорённостей и подготовки сводок.
Кандидат: проверенная закреплённая версия стороннего chigwell/telegram-mcp.
Начать с чтения согласованных чатов; проверить поиск известного сообщения, ссылки и полноту периода. Личный Telegram MCP и Telegram-бот — разные сценарии доступа.
Календарь.
Для повестки дня, подготовки к встречам и планирования.
Уточнить провайдера: Google Calendar или другой. Для Google рассмотреть соответствующий плагин.
Проверить события и часовой пояс. Создание событий с участниками — отдельное действие по поручению.
Включить в план настройки
WhatsApp.
Для рабочих переписок, которые не дублируются в Telegram.
Отдельный пилот стороннего MCP; конкретную реализацию выбрать после проверки устройства и сценария. Один из кандидатов — lharries/whatsapp-mcp с локальным мостом и QR-входом.
Проверить синхронизацию, полноту истории и доступные ограничения. Пока подключение не готово — использовать предоставленный рабочий фрагмент.
Granola.
Для заметок и расшифровок встреч; источник для meeting и последующих поручений.
Подтвердить, что Антон использует или планирует использовать сервис. Проверить доступность интеграции и возможности его аккаунта.
Проверка: найти тестовую встречу, получить заметки/транскрипт и ссылку на источник. Не обещать доступ ко всем старым встречам без проверки.
Playwright / браузер.
Для сайтов и веб-интерфейсов, где задачу нельзя удобно выполнить через прямой коннектор.
Если нужен именно Playwright MCP — настроить и проверить его отдельно. Если доступный браузерный инструмент Codex уже закрывает сценарий, второй инструмент необязателен.
Проверка: открыть тестовый сайт, прочитать данные и выполнить безопасное тестовое действие. Браузер не заменяет все прямые подключения.
Возможности, которые также проверить
Таблицы, документы, PDF, презентации: доступные навыки/плагины и библиотеки для чтения, создания и проверки файлов. Это не обязательно отдельные MCP.
Расшифровка аудио: если нужны голосовые из мессенджеров и локальные записи, не покрываемые Granola.
Веб-поиск: для
lightresearch; отдельный платный поисковый MCP добавлять только при недостаточности доступного поиска.CRM, почту, Notion, Maps и n8n пока не включать без подтверждённой задачи. GitHub включён в обязательную практику первого урока. Для файловой памяти отдельный MCP не требуется.
Источники по вариантам подключения: плагины Codex ↗, конфигурация MCP ↗, Telegram MCP ↗, пример WhatsApp MCP ↗. Granola и Playwright здесь — требования к проверке и настройке, не утверждение об их готовности в аккаунте Антона.
БЛОК 06
Workspace и GitHub
AGENTS.md: роль агента, порядок чтения контекста, выбор скиллов, проверка результатов, работа с разрешениями.Шаблоны контекста: бизнес, роль, приоритетные задачи и метрики Антона;
AGENT-PERSONALITY.md — правила поведения агента по результатам теста. Окончательное разделение файлов определить при адаптации HappyM onboarding; прежние OWNER.md/PREFERENCES.md не являются утверждённым требованием.Шаблон
SOURCES.md: согласованные чаты, таблицы, документы, календарь; актуальный статус доступа..agents/skills/: выбранные адаптированные скиллы вместе с необходимыми scripts/references/assets.setup/: инструкции подключения, шаблоны конфигурации, проверенные версии и тесты готовности.examples/: синтетическая переписка, таблица и заметки встречи для первого урока.README.md: короткий путь от клонирования до первой полезной задачи.CHANGELOG.md и .gitignore: обновления и исключение личных данных.Codex использует .agents/skills для навыков репозитория; проектная MCP-конфигурация может находиться в .codex/config.toml для доверенного проекта. Документация навыков ↗, документация MCP ↗.
Заполненные личные файлы, память, заметки, рабочие выгрузки, результаты, токены, session-файлы и локальные базы переписок не публиковать. Не копировать клиенту весь текущий Workspace с данными других компаний. Подключения Кристины не переходят Антону вместе с Git-клоном.
БЛОК 07
Решения команды
Рабочие заметки планёрки
Что уже согласовали?
Отметки действуют до обновления страницы. Скачайте итог, чтобы сохранить решения. Это не включает автоматизации.
Согласовано 0 из 7
1
Первый полезный сценарий: контроль рекрутера — задачи, показатели, сроки и блокеры. Подтвердить границы пилота: одна таблица, выбранные чаты и согласованные определения метрик; затем выбрать первый отдел для расширения.
2
Состав первого релиза: существующее ядро + мастер подключения +
automate; какой из новых рабочих скиллов создаём первым.3
Подключения к уроку: GitHub подключаем к Codex вместе с Антоном прямо на первом уроке; репозиторий и доступ готовим заранее. Для остальных подключений определить, что должно работать заранее, а что настраиваем следующим этапом. Подтвердить Granola, провайдера календаря и роль WhatsApp.
4
Ответственные: кто адаптирует скиллы, кто проверяет подключения, кто готовит учебные примеры и принимает качество.
5
Окружение Антона: ОС, версия/формат использования Codex, доступ к GitHub и способ авторизации в сервисах.
6
Данные для пилота: один разрешённый рабочий чат, одна таблица, одна заметка встречи; правила обработки данных.
7
Критерии готовности: чистый клон открывается в Codex; онбординг создаёт контекст; память восстанавливается в новой задаче; подключения проходят реальные тесты; первый процесс проходит ручную проверку, затем проверку запуска по расписанию.
Рекомендуемый порядок: собрать контекст и адаптировать существующие навыки → проверить источники → отработать одну задачу вручную → оформить повторяемый процесс → поставить его на расписание → расширять комплект по реальным задачам Антона.