Manager — двусторонний мост между сессией и задачами
Развилка: где лежат задачи
Сначала прочитай файл правил штаба и файл правил отдела (AGENTS.md или CLAUDE.md).
- Там написано, что задачи лежат в файлах (
tasks/): работай по разделу «Уровень 1» ниже, остальной документ не нужен. - Задачи во внешнем источнике (GitHub issues): работай по остальному документу, начиная с «Уровень 2: задачи в GitHub issues».
- Строки о том, где лежат задачи, нет: предложи её дописать, например «Задачи отдела лежат в
tasks/», и спроси человека, прежде чем что-то писать.
Уровень 1: задачи в файлах
В конце сессии:
-
Найти задачу. Ищи задачу этой сессии в
tasks/отдела (путь берётся из правил: где лежат задачи). Файла нет: создайtasks/<ГГГГ-ММ-ДД>-<slug>.mdс разделами:markdown# <название задачи> ## Результат ## Контекст ## Как проверить ## Текущее состояние ## Следующий шаг ## Результат и решение человека -
Обновить файл задачи. Перепиши «Текущее состояние» (что сделано и где лежит) и «Следующий шаг» (одно действие). «Результат и решение человека» заполняет человек; агент пишет туда только его слова из сессии.
-
Сводка дня в штабе. Допиши в штаб строку в сводку дня со ссылкой на файл задачи. Файл сводки тот, что указан в правилах штаба; не указан:
tasks/<ГГГГ-ММ-ДД>.mdв штабе. Формат строки:- <отдел>: <что сделано> → ../<отдел>/tasks/<файл>.md. -
Саммари в чат. Коротко:
✓ сделано: ... ✎ ждёт человека: ... дальше: ...
Режим чтения на уровне 1: «что по <задаче>» ищется по tasks/ отделов из карты отделов штаба; ответ берётся из разделов «Текущее состояние» и «Следующий шаг».
Уровень 2: задачи в GitHub issues
Часть фреймворка Personal Corp — ведение бизнеса одного человека через AI-агентов.
Связывает работу сессии и GitHub issues в обе стороны. GitHub issues — источник правды по задачам; доска GitHub Project — источник правды о том, что активно. У manager два режима:
- Режим записи (синк) — в конце сессии: прочитать, что сделано, найти существующие issues, обновить их прогрессом + комментарием о работе, соблюсти инварианты родителя / W-label / Project, создать новый, только если ничего не подошло.
- Режим чтения (запрос) — в любое время: «что по треку X?», «статус Y?» → поиск по твоим репозиториям, сжатое состояние найденных issues с родительским эпиком, лейблами, местом в Project и последней активностью.
Manager — канонический процесс работы с issue. Не переключайся для этих операций на общий помощник по issue — manager владеет контрактом «прочитать — изменить — записать», инвариантами и синком Project.
Граница публичной поставки
Держи скилл переиспользуемым: владелец, репозитории, пути, ID досок и маршрутизация берутся из локального Manager Config пользователя. Никогда не включай в поставку журналы сессий, примеры клиентов, ссылки на приватные репозитории или копию личной установки.
Что читать дальше
Справочники лежат рядом со скиллом. Читай целиком тот, что нужен на текущем шаге; каждый начинается с оглавления.
| Шаг | Справочник |
|---|---|
| Любой вызов: выбрать режим, режим работы по умолчанию, язык ответа, источники правды, цикл планирования, когда применять и когда нет, pre-flight | references/modes.md |
| Режим записи: алгоритм синка, авторизация, связь коммита и issue, артефакты планирования, статус в Project, чистка плана при закрытии, «обновить или создать», комментарий как запасной канал | references/write-mode.md |
| Режим чтения: алгоритм, пакетное чтение состояния Project, доказательство родителя, связанный контекст, ложные совпадения | references/read-mode.md |
Поиск существующих issue: ключи, критерий совпадения, пакетный GraphQL и защиты jq | references/search.md |
Родительский эпик: что считается эпиком, как найти, агрегирующий родитель, видимый корень, блок Related, проверка до синка | references/parent-epic.md |
| W-label: текущая неделя, дата события, дрейфы, бэклог, быстрое создание лейбла | references/w-labels.md |
| Заголовок нового issue: формула, правила, примеры, антипаттерны | references/titles.md |
| Тело issue: критерий готовности, шаблоны тела, обновления и комментария | references/templates.md |
| Что показать пользователю: план, отчёт, ответ режима чтения | references/output.md |
| Интеграция с CRM (если включена в конфиге) | references/crm.md |
| Частые ошибки и антипаттерны — сверка перед выполнением плана | references/mistakes.md |
Настройка: Manager Config
До первого использования задай это в AGENTS.md проекта (предпочтительно) или в CLAUDE.md (совместимость). Если у проекта ещё нет конфига агента, запусти corp-doctor, чтобы создать или починить его.
markdown## Manager Config ### GitHub owner Имя пользователя или организация GitHub для поиска issue: - owner: your-github-handle ### Repos to scan (cross-repo issue search scope) Репозитории, в которых manager ищет: - ~/Projects/main - ~/Projects/ops - ~/Projects/marketing ### Tasks index file (optional) Путь к курируемому индексу текущей недели. Manager читает его ПЕРВЫМ, до любого `gh search`, чтобы сузить запросы: - tasks_index: ~/docs/tasks.md (если файла нет — manager работает без индекса, поиск идёт по всем repos) ### Tasks directory (optional) Путь к файлам планов дня и недели, которые создаёт weekly-planning: - tasks_dir: ~/docs/tasks/ ### Domain → repo routing | Domain | Repo | |--------|------| | коммерция / B2B-сделки | crm | | запуски продуктов | main | | эксплуатация / инфраструктура | ops | | контент | marketing | ### GitHub Projects integration Manager считает место в Project инвариантом (см. «Железные инварианты»). Объяви свои доски: - weekly_project: <number> # общая доска «всё активное на этой неделе» по всем репозиториям - weekly_project_owner: your-github-handle - status_field: Status # поле single-select, в котором хранится колонка - status_in_progress: In progress # имя (или id) опции активной колонки - domain_projects (optional): # доски по доменам, если они у тебя есть | Domain | Project number | | коммерция | <number> | | продукт | <number> | Закешируй здесь найденные ID полей и опций (`gh project field-list <N> --owner OWNER --format json`), чтобы manager не запрашивал их каждый запуск. ### W-label convention (optional) - enabled: true - format: W{NN} (ISO week) (если false — manager создаёт issues без weekly labels) ### Standing write authorization - mode: ask-each-time | execute-after-plan (по умолчанию: ask. execute-after-plan = manager выполняет записи после показа краткого плана, без отдельного подтверждения) ### CRM integration (optional) - crm_path: ~/Projects/crm - crm_pointer_format: [[<slug>]] (если не используется — секция игнорируется; см. references/crm.md)
corp-doctor — скилл первичной настройки и починки этого конфига. Метаданные типа заголовка здесь НЕ настраиваются: они живут в лейблах, дереве родителей и Projects (см. references/titles.md).
Железные инварианты
Каждый issue, который трогает manager, ОБЯЗАН соблюдать базовые три; активный issue текущей недели дополнительно соблюдает инварианты Project и комментария о работе:
- W-label (текущая или будущая неделя либо неделя конкретного события с датой) — если конвенция W-label включена в конфиге. Если лейбла нет в репозитории — создай его.
- Родительский эпик — ровно один родитель через GitHub Sub-issues API. Любой issue, который сам не эпик, обязан иметь родителя. См. references/parent-epic.md.
- Различение трека через заголовок + принадлежность к эпику — никаких лейблов-треков (
<track-slug>,<client>-deal). Трек узнаётся по тексту заголовка и принадлежности к эпику. - Место в Project — активный issue текущей недели обязан быть на доменной доске Project (если она у тебя есть) И в глобальном недельном Project. W-label без места в Project =
Project drift. - Видимый в Project родитель — для активного дочернего issue текущей недели одного
parent_issue_urlмало. Видимый корневой эпик сам должен быть в нужном Project view с непустой колонкой статуса. - Комментарий о работе — в режиме записи, только когда в этой сессии над issue шла РЕАЛЬНАЯ работа: обязательный комментарий в таймлайн с итогом сделанного + ссылками на коммиты. Смена статуса / лейбла / места в Project его НЕ заменяет. Чисто механическая перестановка лейбла или починка Project без содержательной работы = без комментария.
Без этого issue отслеживается неправильно. Если родительского эпика нет ни в одном репозитории — manager поднимает это в предложении и предлагает создать новый или выбрать существующий до синка. Никогда не оставляет issue-сирот.
Главное (повтор критичного в конце)
До любого вызова gh: прочитай индекс задач → иначе поиск вслепую.
Каждый issue несёт: W-label + родителя (Sub-issues API) + место в Project (непустая колонка статуса).
Режим записи всегда: In progress на затронутых активных issue; комментарий о работе при реальной работе; связь коммита и issue через SHA; тело — канал, комментарий — журнал.
Заголовок: {объект} — {действие} ({когда}), без доменного префикса; метаданные типа живут в лейблах / родителе / Projects.
Постоянная авторизация: следуй настроенному режиму — execute-after-plan выполняет ограниченные записи после плана без отдельного «подтверди»; ask-each-time (по умолчанию) показывает план, потом спрашивает. В обоих случаях спрашивай при настоящей неоднозначности или жёстком блокере.
Язык ответа следует проекту. Технические токены (<repo>#N, W18, команды) остаются как есть.
