---
name: manager
description: >-
  Ведёт задачи штаба: по итогам сессии обновляет файл задачи или issue на
  GitHub и отвечает на вопрос „что по задаче“. Если задачи лежат в файлах,
  обновляет файл задачи отдела и сводку дня в штабе. Если задачи на GitHub,
  ищет issue во всех репозиториях, обновляет описание issue, пишет комментарий
  о сделанной работе, следит за parent epic, W-label и местом на доске
  Project, убирает закрытые задачи из плана дня и недели. Применять по:
  „/manager“, „синкни сессию“, „обнови issues“, „зафиксируй прогресс“, „создай
  issue“, „статус задачи“, „что по …“, „есть ли issue по …“, „sync session“,
  „track status“, „what about …“. Не применять: план дня — daily, ретро —
  retro.
---

# 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. **Саммари в чат.** Коротко:

   ```
   ✓ сделано: ...
   ✎ ждёт человека: ...
   дальше: ...
   ```

Режим чтения на уровне 1: «что по <задаче>» ищется по `tasks/` отделов из карты отделов штаба; ответ берётся из разделов «Текущее состояние» и «Следующий шаг».

## Уровень 2: задачи в GitHub issues

Часть фреймворка Personal Corp — ведение бизнеса одного человека через AI-агентов.

Связывает работу сессии и GitHub issues в обе стороны. GitHub issues — источник правды по задачам; доска GitHub Project — источник правды о том, что активно. У manager два режима:

1. **Режим записи (синк)** — в конце сессии: прочитать, что сделано, найти существующие issues, обновить их прогрессом + комментарием о работе, соблюсти инварианты родителя / W-label / Project, создать новый, только если ничего не подошло.
2. **Режим чтения (запрос)** — в любое время: «что по треку X?», «статус Y?» → поиск по твоим репозиториям, сжатое состояние найденных issues с родительским эпиком, лейблами, местом в Project и последней активностью.

**Manager — канонический процесс работы с issue.** Не переключайся для этих операций на общий помощник по issue — manager владеет контрактом «прочитать — изменить — записать», инвариантами и синком Project.

### Граница публичной поставки

Держи скилл переиспользуемым: владелец, репозитории, пути, ID досок и маршрутизация берутся из локального Manager Config пользователя. Никогда не включай в поставку журналы сессий, примеры клиентов, ссылки на приватные репозитории или копию личной установки.

### Что читать дальше

Справочники лежат рядом со скиллом. Читай целиком тот, что нужен на текущем шаге; каждый начинается с оглавления.

| Шаг | Справочник |
|-----|------------|
| Любой вызов: выбрать режим, режим работы по умолчанию, язык ответа, источники правды, цикл планирования, когда применять и когда нет, pre-flight | [references/modes.md](references/modes.md) |
| Режим записи: алгоритм синка, авторизация, связь коммита и issue, артефакты планирования, статус в Project, чистка плана при закрытии, «обновить или создать», комментарий как запасной канал | [references/write-mode.md](references/write-mode.md) |
| Режим чтения: алгоритм, пакетное чтение состояния Project, доказательство родителя, связанный контекст, ложные совпадения | [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
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](references/titles.md)).

## Железные инварианты

Каждый issue, который трогает manager, ОБЯЗАН соблюдать базовые три; активный issue текущей недели дополнительно соблюдает инварианты Project и комментария о работе:

1. **W-label** (текущая или будущая неделя либо неделя конкретного события с датой) — если конвенция W-label включена в конфиге. Если лейбла нет в репозитории — создай его.
2. **Родительский эпик** — ровно один родитель через GitHub Sub-issues API. Любой issue, который сам не эпик, обязан иметь родителя. См. [references/parent-epic.md](references/parent-epic.md).
3. **Различение трека через заголовок + принадлежность к эпику** — никаких лейблов-треков (`<track-slug>`, `<client>-deal`). Трек узнаётся по тексту заголовка и принадлежности к эпику.
4. **Место в Project** — активный issue текущей недели обязан быть на доменной доске Project (если она у тебя есть) И в глобальном недельном Project. W-label без места в Project = `Project drift`.
5. **Видимый в Project родитель** — для активного дочернего issue текущей недели одного `parent_issue_url` мало. Видимый корневой эпик сам должен быть в нужном Project view с непустой колонкой статуса.
6. **Комментарий о работе** — в режиме записи, только когда в этой сессии над 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`, команды) остаются как есть.