---
name: corp-doctor
description: >-
  Use when a Personal Corp operating loop needs setup, repair, a new department,
  or task routing: HQ files and agent rules, GitHub issue workflow, corp-* owner
  map, department repositories, or deciding which repo an issue belongs to.
  Triggers: "corp doctor", "почини контур", "заведи отдел", "куда положить
  задачу", "настрой штаб", "проверь операционку". Replaces corp-init, corp-new
  and task-routing.
---

# Corp Doctor

Один вход во все операции над контуром Personal Corp: диагностика, ремонт, новый отдел, маршрутизация задачи.

Скилл не собирает систему вслепую. Сначала он выясняет, что уже есть, потом чинит недостающее.

## Phase 0 — Меню

Первое действие: показать меню и дождаться явного выбора. До ответа человека ничего не читать и не создавать.

```text
Что делаем?

1. Диагностика — посмотреть контур и показать расхождения без правок
2. Починить — закрыть найденные расхождения по согласованному плану
3. Новый отдел — приватный corp-* репозиторий и запись о нём в штабе
4. Маршрут задачи — определить, в какой репозиторий кладётся issue
5. Собрать с нуля — HQ, правила агента, задачи, карта отделов

"всё" = 1 + 2
```

Если человек уже сформулировал запрос ("заведи отдел под продажи"), назвать выбранный пункт вслух и идти дальше без меню.

---

## 1. Диагностика

Только чтение. Ничего не создавать и не менять.

Проверить и показать таблицей "есть / нет / расходится":

**Штаб**

- `AGENTS.md` существует и содержит правила агента, границы и карту отделов
- `CLAUDE.md` подключает те же правила
- есть файл владельца штаба с контекстом человека
- есть точка старта по задачам
- карта отделов совпадает с папками, которые лежат рядом

**Операционный слой**

- определён источник состояния задач: файлы или трекер
- один и тот же факт не лежит в двух местах одновременно
- закрытые задачи не висят активными в планах

**Отделы**

- каждый corp-* репозиторий из карты существует и доступен
- у каждого отдела есть свои правила
- нет отдела без домена и нет домена без владельца

Результат фазы: список расхождений, каждое с одной строкой "что сломано" и одной строкой "как чинится". Дальше остановиться и спросить, чинить ли.

---

## 2. Починить

Работать только по расхождениям из фазы 1 и только после согласия человека.

Порядок:

1. Показать план правок списком: файл, что меняется, зачем.
2. Дождаться подтверждения.
3. Внести правки по одной, не смешивая независимые изменения.
4. Повторить диагностику и показать, что закрылось.

Не переписывать чужие формулировки ради стиля. Чинится расхождение, а не вкус.

---

## 3. Новый отдел

Отдел это папка и репозиторий, которые отвечают за один домен и копят по нему опыт. Отдел заводится, когда у работы появилась повторяемость.

### Вводные

Спросить недостающее:

| Значение | По умолчанию |
|---|---|
| Название отдела | спросить |
| Домен: за что отвечает | спросить |
| Владелец на GitHub | спросить |
| Корень локальных репозиториев | `~/Documents/GitHub` |
| Файл штаба с картой отделов | спросить |
| Префикс репозитория | `corp-` |

### Preflight, только чтение

1. Проверить, что папка с таким именем ещё не занята.
2. Проверить, что репозитория с таким именем нет у владельца.
3. Проверить, что в карте отделов нет строки с этим доменом.
4. Показать результат проверки и сухой план: что будет создано.

### Дальше только после подтверждения

1. Создать локальную папку из шаблона отдела.
2. Инициализировать git.
3. Создать приватный репозиторий. Публичная видимость не предлагается.
4. Первый коммит с правилами и README отдела.
5. Добавить одну строку в карту отделов штаба: название, домен, путь.

Репозитории отдела приватные по умолчанию. Публиковать только по явному требованию человека и отдельным решением.

---

## 4. Маршрут задачи

Задача кладётся туда, где живёт её домен. Одна задача существует в одном месте.

### Шаг 1. Прочитать карту

Найти карту отделов в правилах текущей папки или в штабе. Формат:

```yaml
routing:
  - pattern: "бот, рассылка, онбординг"
    repo: owner/bot-repo
  - pattern: "контент, уроки"
    repo: owner/content-repo
  - pattern: "стратегия, сквозное"
    repo: owner/main-repo
```

### Шаг 2. Сопоставить

Найти отдел по ключевым словам задачи. Совпадений нет: спросить человека, а не угадывать.

### Шаг 3. Проверить дубли

Поискать в целевом репозитории похожие задачи. Дубль найден: обновить существующую задачу вместо создания новой.

### Шаг 4. Создать

Создать задачу с понятным условием завершения. Проверить, что нужные метки существуют в целевом репозитории.

### Красные флаги, остановиться

- Задача подходит сразу к двум отделам: спросить владельца, а не выбирать самому.
- Домена нет ни в одном отделе: возможно, нужен новый отдел, пункт 3 меню.
- Задача сформулирована без результата: сначала уточнить, что должно стать правдой.

---

## 5. Собрать с нуля

Порядок сборки. Каждый шаг заканчивается проверкой у человека.

1. **Штаб.** Скопировать шаблон штаба, заполнить владельца, оставить карту отделов пустой.
2. **Правила агента.** Заполнить таблицу "где живёт правда" под реальные файлы человека.
3. **Задачи.** Начать с первого уровня: один файл с задачами на сегодня.
4. **Первый отдел.** Завести один отдел под самый болезненный повторяемый процесс. Не заводить пять сразу.
5. **Ритм.** Договориться, в какой день недели проходит ретро и планирование.

Пустые файлы под будущие отчёты, решения и словари не создавать. Их создаст соответствующий скилл, когда появится содержание.

---

## Границы

- Не выдумывать факты о контуре. Не найден источник, сказать "не знаю" и назвать, чего не хватает.
- Не создавать второй источник состояния, если у темы уже есть владелец.
- Не публиковать приватное и не расширять доступ без явного решения человека.
- Не смешивать независимые правки в одном шаге.
- Секреты и токены в файлы контура не попадают.

## Условия остановки

Остановиться и спросить человека, если:

- выбранный пункт меню требует удаления существующих материалов;
- один и тот же факт найден в двух местах и непонятно, какое главное;
- домен задачи не совпал ни с одним отделом;
- запрошено создание публичного репозитория.

## Связанные скиллы

- `manager` — синхронизация работы сессии с задачами.
- `weekly-retro` — недельный срез и подъём паттернов в правила.
- `weekly-planning` — приоритеты следующей недели.