Agent-Skills.md

Agent Skills: Manager — двусторонний мост между сессией и GitHub issues

>-

UncategorizedID: serejaris/ris-claude-code/manager

Repository

serejaris/ris-claude-code
serejarisLicense: MIT
20625

Install this agent skill to your local

pnpm dlx add-skill https://github.com/serejaris/personal-corp-skills/tree/HEAD/skills/manager

Skill Files

Browse the full folder contents for manager.

Download Skill

Loading file tree…

skills/manager/SKILL.md

Skill Metadata

Name
manager
Description
>-

Manager — двусторонний мост между сессией и GitHub issues

Железные инварианты — читать первым, повторять перед каждым синком

1-3 обязательны для любого issue, который трогает manager. 4-5 добавляются для активного issue текущей недели. 6-9 действуют в режиме записи и при закрытии.

  1. W-label — текущая неделя, будущая неделя или дата конкретной менторской сессии. Нет в репо — создать.
  2. Родительский эпик — ровно один parent через GitHub Sub-issues API. Всё, что не эпик само, имеет parent. Подробно: reference/parent-epic-rules.md.
  3. Трек различается по title + членству в эпике — track-labels (x26-bloom, ai-native-s2 и т.п.) больше не заводим.
  4. Project placement — активный issue текущей недели стоит на канонической GitHub Project-доске своего слоя и в глобальном недельном Project ris © corp / Project #4. W-label без Project placement = Расхождение Project.
  5. Родитель виден в Project — для активного child одного parent_issue_url мало. Видимый parent/root эпик тоже должен быть в нужном Project view с непустой status lane.
  6. Комментарий-запись о работе (режим записи, только при РЕАЛЬНОЙ работе по issue) — GitHub-комментарий в таймлайне: что сделано + ссылки на коммиты. Смена status/label/Project placement его не заменяет. Чисто механический re-label или Project-fix — без комментария.
  7. Дробность задач: никакого чат-журнала — если по треку появилось больше одного самостоятельного следующего шага или founder говорит, что за ходом тяжело следить, не превращать один issue в длинный журнал. Parent/track issue держит короткий канон: Status, Next issues, Decisions. Исполняемые шаги выносить в отдельные child/sibling issues под тем же эпиком — с W-label, Project placement и понятным критерием готовности.
  8. Чек-лист закрытия — закрывать issue можно, только когда: (а) нерешённые развилки и секция «Открыто» из тела перенесены в отдельный открытый issue; (б) каждый follow-up с датой вписан в tasks/WNN/<дата>.md своей даты; (в) параллельные открытые issues того же контура закрыты комментом-указателем «продолжение в #N» либо оставлены открытыми с причиной.
  9. Переход «нетронута → In progress» и запись предложений/драфтов в issue — при создании задача находится в статусе Backlog / Untouched (не тронута). Как только по задаче появилось первое предложение, черновик текста, драфт поста, спецификация или решение:
    • Статус задачи (в Project и body) ОБЯЗАТЕЛЬНО переводится в In progress.
    • Само подготовленное предложение/драфт/спецификация записывается прямо в тело задачи (в ## Proposed draft / solution или ## Updates), чтобы наработки и варианты не терялись в чате сессии.

Если родительского эпика нет ни в одном репо — вынести в предложение founder'у: создать новый или выбрать существующий, до синка.

ВАЖНО: не использовать generic-скиллы github-issues / gh-issues. Manager сам является каноническим workflow.

Выбор режима

Режим записи: founder сказал «синкни сессию», «зафиксируй», «обнови issues», ИЛИ вызвал /manager без аргументов в конце сессии.

Режим чтения: founder спросил о состоянии — «что по», «статус», «есть ли», «какие issues по».

Режим среды (денежный gate): «/manager midweek», «mid-week gate», «среда-чек», ИЛИ автозапуск по расписанию в среду утром. Агент инициирует сам, founder не просит. По умолчанию ничего не пишет в GitHub, но цель не статус-справка, а раннее предупреждение по денежным обещаниям недели — пока неделя ещё не сгорела.

Голый /manager: вывести артефакты из текущего разговора. Не просить founder'а перечислять всё заново. Составить короткий план исполнения (5-15 строк) и сразу выполнить — постоянное разрешение действует.

Manager НЕ используется для: идей без артефактов (это брейншторм); закрытия issue без явной команды founder'а; пакетных обновлений CRM — это CRM-процессы в репо crm, не manager.

Подробный алгоритм обоих режимов: reference/modes-read-write.md.

Постоянное разрешение на запись

Founder подтвердил: GitHub-записи manager'а разрешены по умолчанию. После тихой преднастройки и короткого плана исполнять точечные GitHub-записи не спрашивая отдельное «подтверди».

Покрыто: правки body, комментарии-записи о работе (инвариант 6), создание W-label, привязка parent/sub-issue, Project placement, статус In progress на затронутых активных issues, assignee @me (founder) по умолчанию, правки дневного плана в tasks/WNN/YYYY-MM-DD.md, создание issue, когда эпик, репо и рамка очевидны.

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

Преднастройка (ЖЁСТКОЕ ПРЕДУСЛОВИЕ)

Выполнить до ЛЮБОЙ команды gh search, gh issue и прочих GH-вызовов. Бюджет вывода в чат: 0 строк. Полный алгоритм: reference/search-algorithm.md → «Pre-flight».

  1. Прочитать ~/Documents/obsidian/0_hq/tasks.md ПЕРВЫМ — это курируемый индекс: Project ID, активные треки, указатели на репо. Без него поиск бьёт наугад.
  2. Снять снимок Project #4: gh project item-list 4 --owner serejaris --format json --limit 1000 > /tmp/manager-proj4.json (один раз за прогон; --limit 1000 обязателен).
  3. Страж дрифта HQ — если активная задача в tasks.md без repo#N, вывести Расхождение HQ tasks.
  4. Тихо проверить git status; показать только незакоммиченные артефакты, названные в сессии.
  5. Вычислить ISO-неделю, если tasks.md устарел.

Красный флаг: собираешься запустить gh search issues, не прочитав tasks.md — СТОП.

Где правда

| Нужно | Источник | |---|---| | Текущая неделя, активные треки | ~/Documents/obsidian/0_hq/tasks.md (читать ПЕРВЫМ) | | Сегодняшний план | tasks/WNN/YYYY-MM-DD.md + tasks/WNN/README.md | | Отдельные задачи | GitHub issues в serejaris/* | | Люди, компании, деньги | ~/Documents/GitHub/crm/ — ставить указатель [[crm-slug]], не переносить детали |

Project ID (реестр констант)

| Project | number | project-id | |---|---|---| | ris © corp | 4 | PVT_kwHOCisBXs4BCN8O | | Менторство 1-на-1 | 14 | PVT_kwHOCisBXs4BQrb1 | | Кружок Вайбкодинга | 28 | PVT_kwHOCisBXs4BR41f | | Colder — корпоративное обучение | 31 | PVT_kwHOCisBXs4BT5Hs | | Спортмастер — корпоративное обучение | 38 | PVT_kwHOCisBXs4Bec7S | | Personal Corp | 34 | PVT_kwHOCisBXs4BVZDi | | Школа Вайбкодинга | 5 | PVT_kwHOCisBXs4BDKxF | | Personal Corp Course Launch | 10 | PVT_kwHOCisBXs4BP8bu |

Status option IDs (ris © corp #4): Backlog = f75ad846, Ready = 08afe404, In progress = 47fc9ee4, In review = 4cc61d42, Done = 98236657. Status field id: PVTSSF_lAHOCisBXs4BCN8Ozg0fml0. Time field id: PVTF_lAHOCisBXs4BCN8OzhVKHhI.

Доска #31 — только Colvir. Спортмастер на неё не кладём (решение founder'а, 2026-07-25); он живёт на доске #38 с полем «Трек»: field id PVTSSF_lAHOCisBXs4Bec7SzhY3CWI, опции Product G1 = a0a5e557, Strategy = 2ed89da4, Договор и закупка = 099b1185. Status field id PVTSSF_lAHOCisBXs4Bec7SzhY3CSM (Todo f75ad846, In Progress 47fc9ee4, Done 98236657). Треков пока два — Product G1 и Strategy; process analysts треком не считается, пока не подтверждён.

Опции single-select не удалять через updateProjectV2Field — мутация пересоздаёт опции с новыми id и обнуляет значения на всех items. Если удаление всё же нужно: снять снимок значений до, удалить, переназначить по новым id.

Смысл лейнов (конвейер): Backlog — спеки ещё нет; Ready — спека в теле готова к исполнению; In progress — у исполнителя; In review — на приёмке; Done — приёмка пройдена. Агент, продолжающий работу после рестарта или компакции, восстанавливает состояние конвейера с доски Project #4 и из тел issues, а не из истории чата.

Полные field ID других досок и команды — reference/search-algorithm.md → «Project evidence commands».

Дисциплина Project API

Для доказательств по Project и смены статусов путь по умолчанию — issue-scoped GraphQL.

  • gh project item-list — только там, где этот скилл прямо его называет (снимок Project #4 в преднастройке).
  • Любое другое чтение Project — сначала батч-GraphQL по нужным issues, поле projectItems.
  • Перед любым gh project item-edit подтвердить живым issue-scoped GraphQL: issue существует, Project item существует, текущая lane, целевой Project и lane.
  • Если rate limit не даёт получить это доказательство — остановить Project-синк и сообщить Project lane pending: rate limit.

Красный флаг: собираешься запустить gh project item-list <domain-project> до батч-чтения состояния issues — СТОП. Сначала GraphQL projectItems.

Маршрутизация по доменам

| Домен трека | Где живёт эпик | |---|---| | Поток школы (Кружок) | serejaris/teach-vibecoding (канон маршрутизации: скилл multi-repo-initiatives) | | Образовательная программа / партнёрство | teach-vibecoding / teach-personal-corp | | Менторство / сессия | teaching-репо, issues сессий S<N> | | B2B сделка | serejaris/crm | | Продуктовый запуск | репо самого продукта | | Research | serejaris/research-corp |

Полный алгоритм выбора эпика по доменам: reference/parent-epic-rules.md → «Resolve epic».

Слои менторства: отношения и деньги → CRM/ledger; обзор трека → issue в teaching-репо; сессия S<N> → отдельный issue; delivery → child issue под S<N>.

Для Кружка (поток, урок, запуск, воронка, bot/funnel, публикации для учеников) сначала загрузить templates/kruzhok-product-task-hierarchy.md, потом синкать. Детальная иерархия → reference/kruzhok-hierarchy.md.

Формула заголовка issue

{object} — {action}
  • {object} узнаваемый (Sportmaster, Кружок #11 L3, Валентин S2)
  • em-dash — как разделитель
  • без дат, времени, дедлайнов и W-label — это живёт в labels, полях Project и body
  • без эмодзи и служебных префиксов (product:, epic:, ops:)
  • заголовок на русском; английский только для имён собственных и токенов

Полный свод с примерами и анти-паттернами: reference/issue-authoring.md → «Issue title convention».

Режим записи — шпаргалка

  1. Тихая преднастройка → прочитать tasks.md
  2. Кросс-репо поиск (батч-GraphQL при 3+ ключах) → найти и проверить родительский эпик
  3. Короткий план исполнения (5-15 строк) → сразу исполнить (постоянное разрешение)
  4. Обновить body, а не комментарий по умолчанию — Status / Next / ## Updates + SHA
  5. W-label + parent (Sub-issues API) + Project placement In progress + assignee @me по умолчанию (founder; существующего исполнителя не перетирать — см. reference/issue-authoring.md → «Assignee»)
  6. Комментарий-запись о работе, если работа была реальной
  7. Если в body или таймлайне уже 3+ разнородных обновления — сначала разделить: вынести открытые следующие шаги в отдельные issues под тем же эпиком, а в исходном оставить краткий статус и ссылки
  8. Синк дневного плана HQ: tasks/WNN/YYYY-MM-DD.md
  9. Учёт времени в time/log.csv + поле «Часы», если founder назвал время

Детали: reference/modes-read-write.md и reference/project-sync.md.

Режим чтения — шпаргалка

  1. Преднастройка → tasks.md
  2. Кросс-репо поиск (несколько ключей, батч-GraphQL)
  3. Отсеять ложные совпадения — показать их как IGNORED, а не прятать
  4. Батч-GraphQL по настоящим совпадениям → state + labels + parent + projectItems
  5. Сжатая таблица: repo#N «заголовок» | parent | W-label | Project | последняя активность | статус
  6. Режим чтения ничего не пишет в GitHub

Режим среды (денежный gate) — шпаргалка

Лёгкая проверка в среду между планированием (пн) и ретро (вс): ловит провал недели — воркшоп переносится, денежное обещание стоит — ДО воскресенья, когда неделя уже потрачена. Агент инициирует сам; founder отвечает максимум на один точечный вопрос. Времени founder'а ≈ 0.

Что считать деньгами (денежное обещание — бинарно, поле coprep_active) и откуда брать обещания недели (retros/W{NN}-outcomes.md, строки O*) — то же, что в retro / weekly-planning; здесь не дублируем. См. ~/Documents/GitHub/hq/.agents/skills/retro/SKILL.md (Iron Rule #16 + time-series поля cash_*) и weekly-planning Phase 5.

  1. Прочитать денежные обещания недели (только чтение, батчем):
    • открытые issues с денежным контуром = label текущей недели W{NN} + домены PC-продажи / Кружок / Спортмастер / менторство / ad-slot;
    • ~/Documents/obsidian/0_hq/retros/W{NN}-outcomes.md → строки O*, помеченные как денежные.
  2. Снять движение с понедельника (доказательствами, не самоотчётом): новые сделки и оплаты за окно недели по corp-sales/CLAUDE.md § Live cash truth при чистом reconcile; статус каждого денежного issue — комменты, коммиты (refs/closes), закрытие после понедельника; активность co-prep — соответствующий issue в corp-team (то же поле coprep_active, что в ретро).
  3. Если не движется (нет сделок + тишина в issue + co-prep молчит) — задать founder'у ОДИН самодостаточный вопрос с конкретикой: сущность целиком, одна развилка. Пример:

    «O1 не двинулся за 3 дня, воркшоп-преп стоит, corp-team#5 (co-prep) — 0 активности. Co-prep назначен или контур горит?»

  4. Если движется — короткое cash on track: <доказательство> (сделка / коммит / активность co-prep), без шума.

По умолчанию gate ничего не пишет в GitHub. Если по ответу founder'а нужен синк (re-label, статус, новый issue) — перейти в режим записи под постоянным разрешением.

Расписание: gate стоит повесить на автозапуск в среду утром через скилл schedule или cron. Не создавать cron из этого скилла — это решение founder'а. Пример команды для его подтверждения (не исполнять):

# среда 09:00 — авто mid-week cash gate
schedule: "0 9 * * 3" → /manager midweek

Главные анти-паттерны

  • Issue без родительского эпика — железный инвариант. Вынести в предложение, не создавать сироту.
  • Создание track-labels (x26-bloom, <slug>) — запрещено. Только title + членство в эпике.
  • Markdown Parent: #N в body, когда есть связь через API — дубликат, протухает.
  • Закрытие issue без явной команды founder'а — по умолчанию оставлять открытым с комментарием.
  • Схлопывание менторских сессий — обзор трека, S1, S2, delivery живут отдельными issues. Никогда не сворачивать в один.
  • Деньги в менторских задачах — деньги только в CRM/ledger, не в теле GitHub-issue.
  • Массовая правка tasks.md — manager читает недельный индекс, но не пишет в него; tasks/WNN/YYYY-MM-DD.md — writable.
  • Вопрос «подтверди» перед обычной записью — действует постоянное разрешение. Только жёсткие блокеры.
  • Голые номера — всегда repo#N «title», никогда просто crm#27.
  • Синк или закрытие после реальной работы без комментария-записи — инвариант 6.
  • Большой чат-журнал внутри одного issue — запрещено. Появились независимые действия, документы, ожидания ответа, созвоны → разделить на child/sibling issues, parent держит summary.
  • Закрытие с непереданными развилками и follow-up — сначала перенос («Открыто» → новый issue, даты → дневные файлы, хвосты → указатели), потом close.

Полный список ошибок: reference/issue-authoring.md и таблица ниже.

Частые ошибки

| Ошибка | Как правильно | |---|---| | Пропустить tasks.md перед gh search | СТОП. Сначала tasks.md — там ссылки на Project и слаги треков | | Закрыть delivery по менторству/LMS после локального смоука | Готовность для ученика = загруженное видео + video_id + смоук на проде + отправленная ссылка | | Принять смежный issue за нужный | Смежный = контекст; синкать только в issue с тем же артефактом/сессией/уроком/lane | | Превратить Related в ручной список задач | Блок Related = только контекст: без статусов, чек-листов, W-label и полей Project | | Забыть указатель [[crm-slug]] в issue про коммуникацию | В теле каждого такого issue должна быть ссылка [[<slug>]] | | Считать, что W-label достаточно | Нужны W-label + parent + Project placement с непустой lane | | Считать, что связи parent через API достаточно | Проверяй видимый root в Project и его status lane | | N×gh issue view поодиночке | Батч-GraphQL; одиночный вызов — только точечный fallback | | Коммит без refs <owner>/<repo>#N | Каждый коммит несёт refs-трейлер | | PRD в локальном md, а в issue только ссылка | Полный PRD живёт в теле issue; локальная копия — осознанный дубль, ссылка — GitHub-URL | | Пропустить создание W-label, которого нет в репо | Создай label, не пропускай | | Урок/сессия остались в prep-состоянии после даты события | Дата прошла + «готовлюсь» = Расхождение lifecycle; нужен итог после события | | Попросить founder'а открыть URL или файл руками | Никогда. Приноси содержимое сам через инструменты | | Локальный путь как результат в отчёте | Коммит + push + GitHub-URL ДО отчёта |

Навигация по reference

| Тема | Файл | |---|---| | Алгоритм режимов записи/чтения, шаблоны и язык вывода | reference/modes-read-write.md | | Преднастройка, Project ID подробно, батч-GraphQL, ключи поиска, ложные совпадения | reference/search-algorithm.md | | Родительский эпик, алгоритм выбора, агрегирующий parent, видимый root, смежные issues | reference/parent-epic-rules.md | | Синк дневного плана HQ, учёт времени, коммиты, PRD в issue, lifecycle, правила W-label | reference/project-sync.md | | Заголовки issue, критерий готовности, обновить или создать, менторство, комментарий vs body | reference/issue-authoring.md | | Иерархия Кружка, паттерн заголовков, правила обновления, чек-лист перед синком | reference/kruzhok-hierarchy.md | | Шаблоны тела (новый issue, менторская сессия, комментарий) | templates/issue-body-templates.md | | Полный шаблон иерархии задач по Кружку | templates/kruzhok-product-task-hierarchy.md |

Главное — повторение в конце

Перед любым gh-вызовом: прочитать tasks.md, иначе поиск бьёт наугад.

Каждый issue обязан иметь: W-label + parent (Sub-issues API) + Project placement с непустым статусом.

Режим записи всегда: In progress на затронутых issues; комментарий-запись при реальной работе; синк дневного плана HQ; при закрытии — чек-лист закрытия (инвариант 8).

Постоянное разрешение: план → исполнение без «подтверди». Спрашивать только при настоящей неоднозначности или жёстком блокере.

Режим среды: агент сам собирает денежные доказательства по corp-sales/CLAUDE.md § Live cash truth при чистом reconcile (+ денежные issues + co-prep); один точечный вопрос, только если обещание стоит, иначе cash on track. Определения денег и обещаний — общие с retro / weekly-planning, не дублировать.

Все тексты для founder'а — на русском. Технические токены (crm#27, W18, команды) — как есть.