manager · git:20261026.da11dec · 2026-10-26 · sha256 08a76f0728f8c35c
manager git:20261026.da11decA
Immutable. This exact content never changes and is served at /api/v1/blob/08a76f0728f8c35c.
---
name: manager
description: >-
Связывает сессию с задачами штаба в файлах tasks/ или в GitHub issues.
Запись — «синкни сессию»: итог сессии в задачу и файл дня. Чтение —
«что по <задаче>»: текущее состояние задачи.
---
# Manager
Два режима: **запись** переносит итог сессии в задачу, **чтение** отвечает, что с задачей сейчас.
## Развилка: где лежат задачи
Сначала прочитай файл правил штаба и файл правил отдела (`AGENTS.md` или `CLAUDE.md`).
- Задачи лежат в файлах (`tasks/`): работай по разделу «Уровень 1», остальной документ не нужен.
- Задачи в GitHub issues: работай с раздела «Уровень 2: задачи в GitHub issues».
- Строки о том, где лежат задачи, нет: предложи её дописать, например «Задачи отдела лежат в `tasks/`», и спроси человека до первой записи.
## Уровень 1: задачи в файлах
Запись, в конце сессии:
1. **Найти задачу.** Ищи задачу этой сессии в `tasks/` отдела (путь из правил: где лежат задачи). Файла нет: создай `tasks/<ГГГГ-ММ-ДД>-<slug>.md` с разделами:
```markdown
# <название задачи>
## Результат
## Контекст
## Как проверить
## Текущее состояние
## Следующий шаг
## Результат и решение человека
```
2. **Обновить файл задачи.** Перепиши «Текущее состояние» (что сделано и где лежит) и «Следующий шаг» (одно действие). «Результат и решение человека» заполняет человек; агент переносит туда только его слова из сессии.
3. **Файл дня.** Допиши строку со ссылкой на файл задачи в файл дня штаба: путь из правил штаба, по умолчанию `tasks/<ГГГГ-ММ-ДД>.md` в штабе. Формат строки: `- <отдел>: <что сделано> → ../<отдел>/tasks/<файл>.md`.
4. **Саммари в чат:**
```
✓ сделано: ...
✎ ждёт человека: ...
дальше: ...
```
Чтение: «что по <задаче>» ищется по `tasks/` отделов из карты отделов штаба; ответ берётся из разделов «Текущее состояние» и «Следующий шаг».
## Уровень 2: задачи в GitHub issues
Источник правды по задаче — GitHub issue: тело, состояние, лейблы, эпик. Доска (GitHub Project) показывает, что активно на неделе, и обновляется вслед за issue.
1. **Запись** — в конце сессии: прочитать, что сделано; найти существующие issues; обновить их прогрессом и комментарием о работе; соблюсти инварианты эпика, W-label и доски; новый issue создать, только когда ни один не подошёл.
2. **Чтение** — в любое время: «что по <задаче>» → поиск по репозиториям из конфига, сжатое состояние найденных issues с эпиком, лейблами, колонкой доски и последней активностью.
Все операции с issue (прочитать, изменить, записать, синк доски) идут через manager: он держит контракт записи, инварианты и синк доски.
### Что читать дальше
Справочники лежат рядом со скиллом. Читай целиком тот, что нужен на текущем шаге; каждый начинается с оглавления.
| Шаг | Справочник |
|-----|------------|
| Любой вызов: выбрать режим, режим работы по умолчанию, язык ответа, цикл планирования, когда применять, pre-flight | [references/modes.md](references/modes.md) |
| Запись: алгоритм синка, авторизация, связь коммита и issue, артефакты планирования, колонка доски, чистка плана при закрытии, «обновить или создать», комментарий как запасной канал | [references/write-mode.md](references/write-mode.md) |
| Чтение: алгоритм, пакетное чтение доски, доказательство эпика, связанный контекст, ложные совпадения | [references/read-mode.md](references/read-mode.md) |
| Поиск существующих issue: ключи, критерий совпадения, пакетный GraphQL и защиты `jq` | [references/search.md](references/search.md) |
| Эпик: что считается эпиком, как найти, агрегирующий эпик, видимый корень, блок `Related`, проверка до синка | [references/parent-epic.md](references/parent-epic.md) |
| W-label: текущая неделя, дата события, дрейфы, бэклог, быстрое создание лейбла | [references/w-labels.md](references/w-labels.md) |
| Заголовок нового issue: формула `{действие} {объект}`, правила, примеры | [references/titles.md](references/titles.md) |
| Тело issue: критерий готовности, шаблоны тела, обновления и комментария | [references/templates.md](references/templates.md) |
| Что показать пользователю: план, отчёт, ответ на чтение | [references/output.md](references/output.md) |
| Интеграция с CRM (если включена в конфиге) | [references/crm.md](references/crm.md) |
| Частые ошибки — сверка перед выполнением плана | [references/mistakes.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
Место на доске — инвариант (см. «Железные инварианты»). Объяви свои доски:
- 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 без W-label)
### Standing write authorization
- mode: ask-each-time | execute-after-plan
(по умолчанию: ask-each-time — показать план и спросить. execute-after-plan — выполнить записи после показа краткого плана. В обоих режимах спрашивай при настоящей неоднозначности или жёстком блокере)
### CRM integration (optional)
- crm_path: ~/Projects/crm
- crm_pointer_format: [[<slug>]]
(если не используется — секция игнорируется; см. references/crm.md)
```
`corp-doctor` — скилл первичной настройки и починки этого конфига. Тип работы живёт в лейблах, эпике и на доске (см. [references/titles.md](references/titles.md)).
## Железные инварианты
Каждый issue, который трогает manager, соблюдает первые три; активный issue текущей недели — ещё 4–6:
1. **W-label** — текущая или будущая неделя либо неделя события с датой, если W-label включён в конфиге. Лейбла нет в репозитории — создай его.
2. **Эпик** — ровно один, через GitHub Sub-issues API. Каждый issue, который сам не эпик, привязан к эпику. См. [references/parent-epic.md](references/parent-epic.md).
3. **Трек задают заголовок и эпик.** Лейблы — только W-label и лейблы типа работы.
4. **Место на доске** — активный issue текущей недели стоит на доменной доске (если она есть) и на недельной доске. W-label без места на доске = `Project drift`.
5. **Эпик виден на доске** — для активного дочернего issue текущей недели эпик сам стоит на нужной доске с непустой колонкой статуса.
6. **Комментарий о работе** — в записи, когда над issue в этой сессии шла реальная работа: комментарий в таймлайн с итогом и ссылками на коммиты; он пишется в дополнение к смене колонки, лейбла или места на доске. Синк только лейбла или доски без работы над задачей обходится без комментария.
Эпика нет ни в одном репозитории — manager до синка показывает это в плане и предлагает создать новый эпик или выбрать существующий. После синка у каждого issue есть эпик.