# Manager

> Sync session work into GitHub issues, or query track status across repos. Write: find/update issue + W-label. Read: "что по <track>". Triggers: "создай issue", "синкни сессию", "manager". Not day/week plans (daily-tasks).

- Skill: `serejaris/manager` (Agent Skill, multi-file: 23 files)
- Install (CLI): `npx skillmds@latest add serejaris/manager`
- Raw SKILL.md: https://api.skillmd.com/api/skills/serejaris/manager/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: serejaris (https://skillmd.com/u/serejaris)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/serejaris/manager

---


# 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 <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](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](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`, `<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](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](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`, команды) — как есть.