--- name: Manager slug: manager category: Automation description: Manager syncs session work into GitHub issues and checks track status across repos. Use it to create or update issues, add weekly labels and parent links, or ask what’s happening on a track. github: "https://github.com/serejaris/personal-corp-os/tree/main/skills/manager" language: HTML stars: 224 forks: 25 install: "npx degit https://github.com/serejaris/personal-corp-os/tree/main/skills/manager ~/.claude/skills/manager" installs_to: ~/.claude/skills/manager source_path: skills/manager/SKILL.md collection_size: 25 category_size: 1754 collection_url: "https://dirskills.com/collections/serejaris/personal-corp-os" added: 2026-09-03T06:05:23.996Z last_synced: 2026-09-03T06:05:23.996Z canonical_url: "https://dirskills.com/skills/manager" --- # Manager Manager syncs session work into GitHub issues and checks track status across repos. Use it to create or update issues, add weekly labels and parent links, or ask what’s happening on a track. **Install:** ```bash npx degit https://github.com/serejaris/personal-corp-os/tree/main/skills/manager ~/.claude/skills/manager ``` ## README # 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](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](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](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](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 ` до батч-чтения состояния issues — СТОП. Сначала GraphQL `projectItems`. --- ## Маршрутизация по доменам | Домен трека | Где живёт эпик | |---|---| | Поток школы (Кружок) | `serejaris/teach-vibecoding` (канон маршрутизации: скилл `multi-repo-initiatives`) | | Образовательная программа / партнёрство | `teach-vibecoding` / `teach-personal-corp` | | Менторство / сессия | teaching-репо, issues сессий `S` | | B2B сделка | `serejaris/crm` | | Продуктовый запуск | репо самого продукта | | Research | `serejaris/research-corp` | Полный алгоритм выбора эпика по доменам: [reference/parent-epic-rules.md](reference/parent-epic-rules.md) → «Resolve epic». Слои менторства: отношения и деньги → CRM/ledger; обзор трека → issue в teaching-репо; сессия `S` → отдельный issue; delivery → child issue под `S`. Для Кружка (поток, урок, запуск, воронка, bot/funnel, публикации для учеников) **сначала загрузить** `templates/kruzhok-product-task-hierarchy.md`, потом синкать. Детальная иерархия → [reference/kruzhok-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](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](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/modes-read-write.md) и [reference/project-sync.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`, ``) — запрещено. Только 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](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 должна быть ссылка `[[]]` | | Считать, что W-label достаточно | Нужны W-label + parent + Project placement с непустой lane | | Считать, что связи parent через API достаточно | Проверяй видимый root в Project и его status lane | | N×`gh issue view` поодиночке | Батч-GraphQL; одиночный вызов — только точечный fallback | | Коммит без `refs /#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](reference/modes-read-write.md) | | Преднастройка, Project ID подробно, батч-GraphQL, ключи поиска, ложные совпадения | [reference/search-algorithm.md](reference/search-algorithm.md) | | Родительский эпик, алгоритм выбора, агрегирующий parent, видимый root, смежные issues | [reference/parent-epic-rules.md](reference/parent-epic-rules.md) | | Синк дневного плана HQ, учёт времени, коммиты, PRD в issue, lifecycle, правила W-label | [reference/project-sync.md](reference/project-sync.md) | | Заголовки issue, критерий готовности, обновить или создать, менторство, комментарий vs body | [reference/issue-authoring.md](reference/issue-authoring.md) | | Иерархия Кружка, паттерн заголовков, правила обновления, чек-лист перед синком | [reference/kruzhok-hierarchy.md](reference/kruzhok-hierarchy.md) | | Шаблоны тела (новый issue, менторская сессия, комментарий) | [templates/issue-body-templates.md](templates/issue-body-templates.md) | | Полный шаблон иерархии задач по Кружку | [templates/kruzhok-product-task-hierarchy.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`, команды) — как есть.