---
name: pack-creator
description: Guide a PACK-X author through the SPF fill cycle 01-11. Calls R28 Diagnostician to select mode (assembly/hybrid/full SPF) and leads through phases. Protects the read-only upstream invariant via PreToolUse hook.
trigger_phrases:
  - "Создатель паков, "
  - "Pack Creator, "
realized_by:
  - DP.SC.048
  - DP.ROLE.062
related_methods:
  - SPF/process (01-11)
  - MIM.M.029 Pack Rework
version: 1.0.0
layer: L3
status: active
browser_safe: false
triggers:
  slash: [/pack-creator]
  phrases:
    - "Создатель паков, "
    - "Pack Creator, "
routing:
  executor: sonnet
  deterministic: false
---

# /pack-creator — сопровождение автора PACK-X по SPF-циклу

> ⚡ **Скилл-проводник, не автор.** Знание оригинирует автор Pack. Скилл удерживает
> процесс (SPF/process 01-11), защищает инвариант **read-only upstream FPF/SPF**
> и подстраивает глубину под cp.iwe автора.

## Контракт скилла

- **Вход:** автор намерен создать или продолжить наполнение PACK-X (после `/pack-new`).
- **Выход:** PACK-X с заполненными разделами 01-11 + state-файл `.iwe-runtime/state/spf/{pack_id_slug}.yaml` (локальный, вне Pack — WP-474 Ф3).
- **Время:** N сессий по 30-90 мин, чекпоинты после каждой фазы.
- **Не делает:** не пишет в `SPF/` и `FPF/` (блокируется hook'ом), не выполняет cross-pack consistency аудит (это R24 Аудитор), не декомпозирует деятельность (это R29 Артефактор).

## Когда вызывается

**Триггер-фразы:** «Создатель паков, …», «Pack Creator, …», slash `/pack-creator`.

**Сценарии (DP.SC.048 §5):**

- Автор сделал `/pack-new`, скаффолд готов, нужно наполнить 02-11.
- Автор продолжает работу над PACK-X через несколько сессий — скилл подхватывает
  с `spf_checkpoint` из state-файла.
- Автор не уверен, какой режим оригинальности выбрать — скилл вызывает R28 Диагност.

## Шаг 0 — диагностика автора (R28)

Перед началом работы — определить **cp.iwe** автора (компетенция «работа с
формализациями»). Это задаёт режим:

| cp.iwe | Режим      | Что делает автор                                                   | Что делает скилл                       |
|--------|------------|--------------------------------------------------------------------|----------------------------------------|
| ≤ 2    | assembly   | Выбирает distinction'ы из чек-листа шаблонов соседних паков        | Подаёт шаблоны, объясняет суть         |
| = 3    | hybrid     | Модифицирует шаблоны под свой домен                                | Подаёт шаблоны + вопросы на адаптацию  |
| ≥ 4    | full SPF   | Оригинирует distinction'ы, методы, формализации                    | Консультирует по форме (frontmatter, naming) |

**Если cp.iwe недоступен** (новый пилот, нет данных в Neon) → default **assembly**.
Не запускать `/diagnose` принудительно — спросить автора напрямую: «Какой у тебя
опыт с формализациями: впервые / есть / уверенно работаю?» и смапить ответ.

## Шаг 1 — scaffold через `/pack-new`

Если каталог `PACK-X/` не существует:

```
Вызвать Skill: /pack-new
```

Передать имя домена (существительное, не тема и не инструмент — см. CLAUDE.md §1).
`/pack-new` создаст структуру по `SPF/pack-template/` (разделы 01-11 пустыми
скелетами) и склонирует FPF/SPF при необходимости. После — продолжать с Шага 2.

## Шаг 2 — фазы SPF/process 02-11

Последовательность процесса — `SPF/process/01-domain-selection.md` … `11-review-and-evolution-cycle.md`.
Скилл ведёт автора по фазам **с записью прогресса в state-файл** (Шаг 7).

### Глубина оригинальности по режиму

- **assembly (cp.iwe ≤ 2)** — источник кандидатов = домен, не соседние Pack'и (WP-474 Ф6, разрыв #2: копирование содержания соседей давало «Pack в стиле IWE», не заземлённый в реальной практике — нарушение D11):
  1. **Кандидаты различений** скилл извлекает из SoTA-источников самого Pack'а (`06-sota/*.md`, собраны Шагом 1.5 pack-new): детерминированный парсинг строк вида `distinction: X vs Y` — строка ищется в ЛЮБОМ месте sota-sheet-файла (начало строки `distinction:`, разделитель ` vs `), не только рядом с Claims. Найденные кандидаты подаются автору как чек-лист — автор выбирает применимые (механика чек-листа сохранена, она и делает режим посильным для cp.iwe ≤ 2; сменился только материал).
  2. **LLM-fallback:** если маркированных строк в SoTA-sheet нет — скилл предлагает переформулировки claims в форму «X ≠ Y», каждая помечается «предложение агента, требует подтверждения автора». Принятые автором дописываются в SoTA-sheet строками `distinction: X vs Y` — следующий прогон уже детерминирован.
  3. **`sota_sources: none` в манифесте** → сначала добрать источник (вернуться к Шагу 1.5 pack-new) ИЛИ формализовать практику автора как источник — fallback допустим только при недоступности внешнего SoTA по домену, с явной записью в `06-sota/`: `source: author practice`, `evidence: self-report / interview`, `claims: 2-4 тезиса`, `validity region: личный опыт автора`. Голое «я так делаю» без формализации — не источник (размывает D11).
  4. **Соседние Pack'и (`PACK-*` в `${IWE:-$HOME/IWE}/`) — только образец ФОРМЫ:** структура заголовка `### <код>.D.NNN`, строка `**Maturity:**`, тест «можно ли проверить?». Копирование их СОДЕРЖАНИЯ (формулировок различений, терминов) в новый Pack запрещено.

- **hybrid (cp.iwe = 3):** кандидаты из SoTA-источников (как в assembly) + вопросы: «Что в твоём домене
  отличается?», «Какой термин замени, какой оставь?» Автор модифицирует формулировки сам; соседние Pack'и — форма only.

- **full SPF (cp.iwe ≥ 4):** скилл не даёт шаблоны, только напоминает требования
  формы (id-схема `<PACK>.D.NNN`, обязательные поля frontmatter, проверка тестом
  «можно ли проверить?»). Автор оригинирует distinction'ы с нуля.

### Чекпоинт после каждой фазы

После завершения раздела (например, 03-distinctions заполнен):

1. Обновить `.iwe-runtime/state/spf/{pack_id_slug}.yaml`: `spf_checkpoint: 03`.
2. Предложить автору паузу или переход к следующей фазе.
3. Запомнить решение, не настаивать.

## Шаг 3 — защита инварианта (PreToolUse hook)

Скилл устанавливает переменную окружения `PACK_CREATOR_ACTIVE=1` на время сессии.
Hook `pack-creator-spf-guard.sh` блокирует Write/Edit/NotebookEdit в путях
`~/IWE/SPF/*` и `~/IWE/FPF/*`. При срабатывании hook возвращает exit 2 с
объяснением.

**Что делать при срабатывании:**

- НЕ пытаться обойти (это hook bypass, CLAUDE.md §2.6).
- Если изменение **точечно для PACK-X** (новое distinction, метод, formalisation)
  → переписать путь на `PACK-X/pack/X/<раздел>/`. См. extension-механизм в
  `SPF/process/00-process-overview.md#extension-mechanism`.
- Если изменение **системное** (касается всех Pack, правка процесса/спецификации
  SPF) → это **отдельный РП на правку SPF** (governance-работа), не работа
  `/pack-creator`. Завершить текущую фазу, открыть `/wp-new` с владельцем
  upstream.

## Шаг 4 — verify через R23

После прохождения 02-11 (или промежуточного checkpoint):

1. **Структурная проверка (SPF.SPEC.001):**

```
Вызвать Skill: /verify
```

Артефакт — `PACK-X/pack/X/`. Эталон — `SPF.SPEC.001` (структура и обязательные
секции Pack). VR.R.001 работает context-isolated, проверяет результат, не процесс.

2. **Package-адекватность по E.4.DPF.DA (WP-474 Ф4, для seed-пакета):**

```
Вызвать Skill: /verify
Аргумент: pack <путь-к-PACK-X>
```

Проверяет 11 координат Domain Adequacy (D1-D11) по артефактам фаз Ф1-Ф3 (SoTA-лист, decision-record, seed-маркер) на порядковой шкале 0-5 с порогом допуска (floor 4, или 3 при явной заготовке — WP-474 Ф8.1). Вердикт: `DPFPackageAdequacyStatus` (`admissibleForDeclaredDPFUse` / `seedOnly` / `repairBeforeDPFUse`, плюс эскалационные значения). Проверка честная для заготовки: низкие значения по координатам зрелости (педагогика, практики, трансфер и т.д.) не блокируют `seedOnly` — приоритет ремонта задаётся сортировкой строк результата по значению, не списком «критичных» координат (WP-474 Ф8.3, пир-сессия 2026-09-05-27).

При расхождении эталону (любой проверке): скилл получает отчёт, возвращается на нарушенную фазу, повторяет.

## Шаг 5 — state management

> **Вынесено из дерева Pack (WP-474 Ф3, пир-сессия 2026-07-09-14-seed-mature-spf-state).**
> `.spf-state.yaml` — машинное состояние процесса заполнения (кто, когда, до какого чекпоинта), не содержание Pack. Оставление его внутри Pack означало бы, что при переносе/копировании Pack (командный форк, публикация) чужой автор получает вместе с содержанием чужой, бессмысленный для него прогресс-трекер. Contrast: `.pfad-decision.md` (Ф2) остался ВНУТРИ Pack — это человекочитаемая история происхождения, которая обязана путешествовать с Pack.

Файл: `.iwe-runtime/state/spf/{pack_id_slug}.yaml` — локально, вне git (`.iwe-runtime/` уже в `.gitignore` корня IWE).

`pack_id_slug` — имя директории Pack без префикса `PACK-` (например `PACK-product-management/` → `pack_id_slug: product-management`), НЕ поле `pack_id` манифеста — то содержит короткий мнемо-код (`DP`, `MIM`), а не slug (расхождение найдено и исправлено при WP-474 Ф3: изначальная версия этого правила ошибочно предполагала, что `pack_id` манифеста и есть slug с префиксом).

Источник имени директории — по приоритету: (1) если `/pack-creator` вызван с явным путём/именем Pack в аргументе («Создатель паков, продолжи PACK-X») — взять `{slug}` оттуда; (2) иначе, если текущая рабочая директория — сам Pack (содержит `00-pack-manifest.md`) — взять slug из её имени; (3) иначе — спросить пользователя, какой Pack продолжаем, не гадать.

Минимальная схема:

```yaml
pack_id: DP   # короткий код из манифеста, для справки — не используется в пути state-файла
mode: assembly | hybrid | full
cp_iwe_at_start: 2
spf_checkpoint: 03   # последний завершённый раздел SPF/process
last_session: 2026-05-31
notes: |
  свободный текст автора между сессиями
```

При повторном запуске `/pack-creator`: определить `pack_id_slug` из пути/имени директории Pack (`PACK-{slug}` → `{slug}`) → прочитать `.iwe-runtime/state/spf/{pack_id_slug}.yaml`, если существует → восстановить режим и точку входа, не повторять Шаг 0 (если `cp_iwe_at_start` свежее 30 дней). Не читать `.pfad-decision.md` для этого поиска — `wp:` там остаётся гуманитарной ссылкой для аудита, не механической точкой входа скилла.

Если `.iwe-runtime/state/spf/{pack_id_slug}.yaml` не найден (первый запуск, или машина сменилась и state не перенесли вручную) — считать это первым запуском, начать с Шага 0. Историю прогресса это не портит: сам Pack (заполненные разделы) — источник истины о том, что реально сделано; `.spf-state.yaml` — только удобный ярлык, не обязательная зависимость.

## Шаг 6 — соседи (Pack-различения)

| Скилл/роль                | Когда                                              | Граница                       |
|---------------------------|----------------------------------------------------|-------------------------------|
| `/pack-new`               | Скаффолд каталогов PACK-X (разово)                 | Скилл, не роль                |
| `/pack-creator` (эта)     | Наполнение 02-11, сопровождение N сессий           | R30, длинный процесс          |
| `/ke`                     | Захват одного факта в Pack/CLAUDE.md/memory        | Точечно, не процесс           |
| R29 Артефактор-Декомпозитор | Разбить деятельность на этапы (≥3h РП)           | Деятельность, не онтология    |
| R24 Аудитор               | Cross-pack consistency, аудит инсталляции          | За границей R30               |

**Тест границы R30:** «Это про наполнение онтологии одного Pack?» Да → R30.
«Это про разбиение работы на этапы?» → R29. «Это про сверку соответствия N
паков общему стандарту?» → R24.

## Шаг 7 — закрытие сессии

В конце каждой сессии скилла:

1. Записать прогресс в `.iwe-runtime/state/spf/{pack_id_slug}.yaml` (`spf_checkpoint`, `last_session`, `notes`).
2. Снять `PACK_CREATOR_ACTIVE` (через `unset` в обёртке или закрытие сессии Claude).
3. Если фаза 11 пройдена и `/verify` OK → предложить commit + push PACK-X.
4. Если ещё не end-of-process → отметить «продолжим с фазы N» в чате.

## Анти-паттерны

- ❌ Скилл оригинирует distinction'ы за автора (особенно в режиме full SPF).
- ❌ Скилл правит SPF/FPF «потому что так логичнее» — hook должен сработать; если
  обходишь — нарушаешь CLAUDE.md §2.6.
- ❌ Прыжок через фазы (03 → 07 без 04-06) — Pack получит дырки, R23 завалит verify.
- ❌ Запуск без state-файла, повторное прохождение Шага 0 каждую сессию.

## Источники

- **DP.SC.048** — service clause «Pack Creation»
- **DP.ROLE.062** — роль «Создатель паков» (R30)
- **SPF/process/00-process-overview.md** — общая карта процесса + extension-механизм
- **CLAUDE.md §1** — Pack Creation Gate, fallback chain
- **WP-369** — закрыт 31 мая, контекст создания роли
- **WP-377 Ф2.4** — реализация скилла + hook (текущая)

#!/usr/bin/env bash
# Smoke test: убедиться что hook блокирует write в SPF, но пропускает в PACK-X
set -euo pipefail

GUARD="$HOME/IWE/.claude/hooks/pack-creator-spf-guard.sh"

# 1. Pass-through когда PACK_CREATOR_ACTIVE не установлен
echo '{"tool_name":"Write","file_path":"'"$HOME"'/IWE/SPF/process/00-process-overview.md"}' | \
    bash "$GUARD"
rc=$?
[ "$rc" -eq 0 ] || { echo "FAIL: pass-through нарушен (rc=$rc)"; exit 1; }
echo "✅ Pass-through OK (без PACK_CREATOR_ACTIVE)"

# 2. Block при попытке write в SPF/
set +e
echo '{"tool_name":"Write","file_path":"'"$HOME"'/IWE/SPF/process/00-process-overview.md"}' | \
    PACK_CREATOR_ACTIVE=1 bash "$GUARD" 2>/dev/null
rc=$?
set -e
[ "$rc" -eq 2 ] || { echo "FAIL: SPF write не заблокирован (rc=$rc)"; exit 1; }
echo "✅ SPF write blocked OK"

# 3. Block при попытке write в FPF/
set +e
echo '{"tool_name":"Edit","file_path":"'"$HOME"'/IWE/FPF/FPF-Spec.md"}' | \
    PACK_CREATOR_ACTIVE=1 bash "$GUARD" 2>/dev/null
rc=$?
set -e
[ "$rc" -eq 2 ] || { echo "FAIL: FPF write не заблокирован (rc=$rc)"; exit 1; }
echo "✅ FPF write blocked OK"

# 4. Pass-through для write в PACK-X
echo '{"tool_name":"Write","file_path":"'"$HOME"'/IWE/PACK-test/pack/test/03-methods/TEST.M.001.md"}' | \
    PACK_CREATOR_ACTIVE=1 bash "$GUARD"
rc=$?
[ "$rc" -eq 0 ] || { echo "FAIL: PACK-X write заблокирован (rc=$rc)"; exit 1; }
echo "✅ PACK-X write OK"

echo ""
echo "=== ALL TESTS PASSED ==="