pack-creator

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
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 при необходимости. После — продолжать с Шага 1.7.

Шаг 1.7 — DRR-гейт перед наполнением (WP-481 Ф2, DP.SC.195)

Декларативный precondition (дух CGUS — гейт, не жёсткий шаг): наполнение раздела Pack по теме разрешено, только если решения темы зафиксированы ДО генерации текста.

Проверка перед первой контентной фазой (и при смене темы пополнения):

1. Существует ли inbox/WP-NNN/drr/DRR.md текущего РП с ≥1 DR-записью status: accepted и maps_to, покрывающим заполняемый раздел?
2. Нет → предложить автору сформировать DRR: Intake (что уже в Pack по теме, источники, противоречия) + DR-записи по шаблонам .claude/skills/pack-creator/templates/ (DRR-index-template.md, DR-record-template.md).
3. Точечная правка (опечатка, одно различение через /ke) DRR не требует — порог «тема», не «любая правка». Автор вправе явно подтвердить «тема не требует DRR» — зафиксировать это в WP-context, не молчаливый пропуск.

Границы: DR-запись — owner решения; текст раздела — производная расфасовка (правку решения начинать с DR-записи). Одна запись = одно решение; отвергнутые альтернативы — в Options. Полный контракт — DP.SC.195.

Шаг 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-маркер). Вердикт: PASS/CONDITIONAL/FAIL. Проверка честная для seed-статуса: отсутствие педагогики, практик, трансфера и т.д. отмечается как missing(seed-expected), не блокирует PASS, если критичные координаты (D1, D7, D11) в порядке.

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

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

Скилл/роль	Когда	Граница
/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 (текущая)