菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Создание нового рабочего продукта (РП) с записью в 5 мест атомарно. Используй когда появляется новая задача, которой нет в плане недели.
Многотуровый диалог писателя (Claude) с напарником (Kimi) по задаче пилота (DP.SC.154). Ведёт turn-loop, обнаруживает CONSENSUS/ESCALATE, после консенсуса — Decision Gate (зафиксировать vs реализовать → ревью → проверить → задеплоить), синтезирует report.md через Agent tool.
Регистрация косяка агента в системе учёта WP-316 L1. Без LLM — детерминированный скрипт без WP Gate.
Аудит пользовательской инсталляции IWE. Запускает scripts/iwe-audit.sh + MCP healthcheck + smoke-test ритуала через sentinel-механику (контракт dry-run-contract.md), передаёт отчёт subagent'у в роли VR.R.002 Аудитор (context isolation) → verdict ✅/⚠️/❌ по 6 компонентам (Inventory, L1 drift, DS-strategy, L3 customizations, MCP, ритуал). Используй после restore из бэкапа, после update.sh, или при еженедельной сверке.
Протокол закрытия недели (Week Close). Ретро 7 дней + carry-over в новую неделю + платформенные шаги (бэкап, dirty repos).
Протокол закрытия дня (Day Close). Алиас для /run-protocol close day — симметрия с /day-open.
| 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. Скилл удерживает процесс (SPF/process 01-11), защищает инвариант read-only upstream FPF/SPF и подстраивает глубину под cp.iwe автора.
/pack-new)..iwe-runtime/state/spf/{pack_id_slug}.yaml (локальный, вне Pack — WP-474 Ф3).SPF/ и FPF/ (блокируется hook'ом), не выполняет cross-pack consistency аудит (это R24 Аудитор), не декомпозирует деятельность (это R29 Артефактор).Триггер-фразы: «Создатель паков, …», «Pack Creator, …», slash /pack-creator.
Сценарии (DP.SC.048 §5):
/pack-new, скаффолд готов, нужно наполнить 02-11.spf_checkpoint из state-файла.Перед началом работы — определить cp.iwe автора (компетенция «работа с формализациями»). Это задаёт режим:
| cp.iwe | Режим | Что делает автор | Что делает скилл |
|---|---|---|---|
| ≤ 2 | assembly | Выбирает distinction'ы из чек-листа шаблонов соседних паков | Подаёт шаблоны, объясняет суть |
| = 3 | hybrid | Модифицирует шаблоны под свой домен | Подаёт шаблоны + вопросы на адаптацию |
| ≥ 4 | full SPF | Оригинирует distinction'ы, методы, формализации | Консультирует по форме (frontmatter, naming) |
Если cp.iwe недоступен (новый пилот, нет данных в Neon) → default assembly.
Не запускать /diagnose принудительно — спросить автора напрямую: «Какой у тебя
опыт с формализациями: впервые / есть / уверенно работаю?» и смапить ответ.
/pack-newЕсли каталог PACK-X/ не существует:
Вызвать Skill: /pack-new
Передать имя домена (существительное, не тема и не инструмент — см. CLAUDE.md §1).
/pack-new создаст структуру по SPF/pack-template/ (разделы 01-11 пустыми
скелетами) и склонирует FPF/SPF при необходимости. После — продолжать с Шага 2.
Последовательность процесса — 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):
06-sota/*.md, собраны Шагом 1.5 pack-new): детерминированный парсинг строк вида distinction: X vs Y — строка ищется в ЛЮБОМ месте sota-sheet-файла (начало строки distinction:, разделитель vs), не только рядом с Claims. Найденные кандидаты подаются автору как чек-лист — автор выбирает применимые (механика чек-листа сохранена, она и делает режим посильным для cp.iwe ≤ 2; сменился только материал).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-* в ${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.Скилл устанавливает переменную окружения PACK_CREATOR_ACTIVE=1 на время сессии.
Hook pack-creator-spf-guard.sh блокирует Write/Edit/NotebookEdit в путях
~/IWE/SPF/* и ~/IWE/FPF/*. При срабатывании hook возвращает exit 2 с
объяснением.
Что делать при срабатывании:
PACK-X/pack/X/<раздел>/. См. extension-механизм в
SPF/process/00-process-overview.md#extension-mechanism./pack-creator. Завершить текущую фазу, открыть /wp-new с владельцем
upstream.После прохождения 02-11 (или промежуточного checkpoint):
Вызвать Skill: /verify
Артефакт — PACK-X/pack/X/. Эталон — SPF.SPEC.001 (структура и обязательные
секции Pack). VR.R.001 работает context-isolated, проверяет результат, не процесс.
Вызвать 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) в порядке.
При расхождении эталону (любой проверке): скилл получает отчёт, возвращается на нарушенную фазу, повторяет.
Вынесено из дерева 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 — только удобный ярлык, не обязательная зависимость.
| Скилл/роль | Когда | Граница |
|---|---|---|
/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.
В конце каждой сессии скилла:
.iwe-runtime/state/spf/{pack_id_slug}.yaml (spf_checkpoint, last_session, notes).PACK_CREATOR_ACTIVE (через unset в обёртке или закрытие сессии Claude)./verify OK → предложить commit + push PACK-X.