project-init

# Project Init

Разовая настройка проекта под AI-агентское управление. Skill идёт через guided интервью, проверяет что уже существует, не перезаписывает чужое, создаёт только недостающее.

## Phase 0 — Меню настройки (ПЕРВОЕ действие)

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

Покажи пользователю:

```
Что настраиваем? Отметь нужное:

☐ 1. Локальные файлы — tasks.md · okr.md · decisions.md · AGENTS.md или CLAUDE.md (config block)
☐ 2. Настройка GitHub — Project + labels + список репо

«всё» = обе опции
```

Если пользователь выбрал «всё» или «1, 2» — запустить обе ветки по порядку (сначала 1, потом 2). Если выбрал только одну — пропустить вторую полностью на всех фазах.

**Не действуй пока ответа нет.** Это первое и единственное действие Phase 0.

## Phase 1 — Что уже есть (verify, только для выбранного)

Цель: до интервью узнать что existing, чтобы не задавать лишних вопросов и не overwrite'ить чужое.

### Если выбрана опция 1 — Локальные файлы

```bash
# Базовая папка проекта (стандарт: 0_hq/, но может быть любой)
ls -la 0_hq/ 2>/dev/null || echo "0_hq нет"

# Канонические файлы
for f in tasks.md okr.md decisions.md; do
  if [ -f 0_hq/$f ]; then echo "✓ 0_hq/$f"; else echo "— нет 0_hq/$f"; fi
done

# AGENTS.md / CLAUDE.md — для config block
# Используем тот что existing. Если оба есть — primary тот что не симлинк.
# Если ни одного — спросим в Phase 2 какой создать (по типу агента).
for f in AGENTS.md CLAUDE.md; do
  if [ -L 0_hq/$f ]; then echo "↪ 0_hq/$f → $(readlink 0_hq/$f)"
  elif [ -f 0_hq/$f ]; then echo "✓ 0_hq/$f ($(wc -l < 0_hq/$f) строк)"
  else echo "— нет 0_hq/$f"
  fi
done

# Если AGENTS.md или CLAUDE.md существует — есть ли уже config block?
grep -lA 5 "Agent Operations Config" 0_hq/AGENTS.md 0_hq/CLAUDE.md 2>/dev/null

# Если okr.md существует — какой период?
head -10 0_hq/okr.md 2>/dev/null
```

Записать в session: что уже existing, что отсутствует. На следующих фазах задавать вопросы только про missing.

### Если выбрана опция 2 — GitHub

```bash
# Какой github username?
gh api user --jq '.login'

# Существующие projects пользователя
gh project list --owner <username>

# Существующие репо
gh repo list <username> --limit 30 --json name,description

# Если знаем репо проекта — существующие labels
for repo in <repos>; do
  gh label list -R $repo --limit 50 | grep -iE "retro|epic|backlog|^W[0-9]"
done
```

Записать: есть ли подходящий Project, какие labels уже созданы, какие репо в scope.

## Phase 2 — Интервью (по одному вопросу, только под gap)

Правила:
- **Один вопрос за раз** — не overwhelm
- **Не спрашивать про existing** — если файл/конфиг уже есть, в интервью пропустить
- **Записывать каждый ответ сразу** — не копи в голове

### Если выбрана опция 1 — Локальные файлы

#### 1.1 Базовая папка проекта

Только если папки нет.

> «В какой папке держать канонические файлы? По умолчанию `0_hq/`.»

#### 1.2 Контекст бизнеса

Только если ни `AGENTS.md`, ни `CLAUDE.md` нет, или ни в одном из них нет config block'а.

> «Чем занимаешься? Тип бизнеса, solo или с командой?»
> «Какие продукты/услуги продаёшь? Цены, где они живут (лендинг, бот, и т.д.)»

Если ни один из файлов не существует, дополнительно спросить:

> «Какой агент основной — Claude Code или Codex/другой? От этого зависит имя файла: `CLAUDE.md` для Claude Code, `AGENTS.md` для универсального. Можно создать оба и связать симлинком — но обычно один.»

#### 1.3 OKR / North Star (только если `okr.md` отсутствует или период устарел)

Если файл есть и период current — пропустить, только перепривязать в config.

##### 1.3.a — Период и North Star

> «На какой горизонт ставим цели? (Q2 = квартал / H2 = полугодие / 2026 = год)»
> «Сформулируй North Star одним предложением: к концу периода у тебя/нас будет ___».

Anti-pattern: если ответ начинается с «увеличить X на Y%» — это KR, не North Star. Уточни: «А что у тебя будет когда X вырастет на Y%? Это и есть North Star».

##### 1.3.b — Objectives (1-3 на период)

> «Какие 1-3 крупных направления должны двигаться чтобы North Star стал реальностью?»

Спрашивать по одному. Per O ещё:
- Название (короткое — 3-7 слов)
- **Why** одно предложение мотивации

Anti-pattern: 4+ Objectives на квартал для founder-of-one. STOP, попросить сократить до топ-3.

##### 1.3.c — Key Results (2-4 на каждый Objective)

Per O спросить 2-4 KR. Per KR:

> «Как поймём что O двигается? (a) к дате X есть Y — binary, или (b) метрика Z достигла N — численное»
> «Где это будет measure'иться? Конкретный путь — файл, sales.db query, GitHub issue, dashboard».

Anti-pattern: **KR без source-of-truth pointer**. STOP, спросить «где будем мерить?». Без pointer'а KR превратится в воздух.

##### 1.3.d — Guard rails (опционально)

> «Какие метрики хочешь мониторить как guard rails — не достигать, а держать в норме? Например "выручка/неделя ≥ $X" или "доля исходящих ≥ N в неделю". Это защита от Goodhart's law: KR можно загейминговать, guard rails ловят перекос.»

Можно пропустить если пользователь не готов.

##### 1.3.e — Cadence

> «Когда ревьюим OKR? По умолчанию — в `weekly-retro` Phase 1.5 (еженедельно прогресс) + monthly snapshot. Подходит?»

### Если выбрана опция 2 — GitHub

#### 2.1 Репо

Если репо ещё не определены.

> «Какие репо относятся к этому проекту? Возьми 5-7 ключевых для weekly operations, остальные подключим позже. Категоризировать: execution / growth / infrastructure.»

Для каждого репо спросить категорию (одна из трёх).

#### 2.2 Project

Если Project уже existing — спросить:
> «Использовать `<Project N>` (нашли в gh project list) или создать новый?»

Если нет:
> «Название Project'а? Например "Personal Corp" или "<Brand> ops".»

#### 2.3 Routing

> «Какие задачи идут в какой репо? Pattern → repo. Например: "bot, broadcast" → hsl-mozg, "lessons" → teach-vibecoding.»

Минимум 3 routing rule. Можно дополнять позже.

## Phase 3 — Создание (per selected only)

### Опция 1 — Локальные файлы

#### 3.1.a Создать структуру

```bash
mkdir -p <project-folder>/ret