| 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 по теме разрешено, только если решения темы зафиксированы ДО генерации текста.
Проверка перед первой контентной фазой (и при смене темы пополнения):
- Существует ли
inbox/WP-NNN/drr/DRR.md текущего РП с ≥1 DR-записью
status: accepted и maps_to, покрывающим заполняемый раздел?
- Нет → предложить автору сформировать DRR: Intake (что уже в Pack по теме,
источники, противоречия) + DR-записи по шаблонам
.claude/skills/pack-creator/templates/ (DRR-index-template.md,
DR-record-template.md).
- Точечная правка (опечатка, одно различение через
/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):
- Кандидаты различений скилл извлекает из SoTA-источников самого Pack'а (
06-sota/*.md, собраны Шагом 1.5 pack-new): детерминированный парсинг строк вида distinction: X vs Y — строка ищется в ЛЮБОМ месте sota-sheet-файла (начало строки distinction:, разделитель vs), не только рядом с Claims. Найденные кандидаты подаются автору как чек-лист — автор выбирает применимые (механика чек-листа сохранена, она и делает режим посильным для cp.iwe ≤ 2; сменился только материал).
- LLM-fallback: если маркированных строк в SoTA-sheet нет — скилл предлагает переформулировки claims в форму «X ≠ Y», каждая помечается «предложение агента, требует подтверждения автора». Принятые автором дописываются в SoTA-sheet строками
distinction: X vs Y — следующий прогон уже детерминирован.
sota_sources: none в манифесте → сначала добрать источник (вернуться к Шагу 1.5 pack-new) ИЛИ формализовать практику автора как источник — fallback допустим только при недоступности внешнего SoTA по домену, с явной записью в 06-sota/: source: author practice, evidence: self-report / interview, claims: 2-4 тезиса, validity region: личный опыт автора. Голое «я так делаю» без формализации — не источник (размывает D11).- Соседние 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 заполнен):
- Обновить
.iwe-runtime/state/spf/{pack_id_slug}.yaml: spf_checkpoint: 03.
- Предложить автору паузу или переход к следующей фазе.
- Запомнить решение, не настаивать.
Шаг 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):
- Структурная проверка (SPF.SPEC.001):
Вызвать Skill: /verify
Артефакт — PACK-X/pack/X/. Эталон — SPF.SPEC.001 (структура и обязательные
секции Pack). VR.R.001 работает context-isolated, проверяет результат, не процесс.
- 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
mode: assembly | hybrid | full
cp_iwe_at_start: 2
spf_checkpoint: 03
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 — закрытие сессии
В конце каждой сессии скилла:
- Записать прогресс в
.iwe-runtime/state/spf/{pack_id_slug}.yaml (spf_checkpoint, last_session, notes).
- Снять
PACK_CREATOR_ACTIVE (через unset в обёртке или закрытие сессии Claude).
- Если фаза 11 пройдена и
/verify OK → предложить commit + push PACK-X.
- Если ещё не 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 (текущая)
