Pack Creator

/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 недоступен (новый пилот, нет данных в 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 продолжаем, не гадать.

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

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-различения)

Тест границы 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 (текущая)