--- name: pack-new description: "Create a new Pack — guided flow through SPF: choose domain, name Pack, scaffold structure, fill roadmap." argument-hint: "[область знания или домен]" --- # Pack New — создание нового Pack Создаём Pack для домена: $ARGUMENTS ## Что делает этот скилл - Проверяет наличие Base-репо (FPF, SPF) и клонирует при отсутствии - Проводит через SPF §01 (выбор домена) и §02 (bounded context) - Предлагает имя Pack по критериям SPF - Создаёт структуру директорий и стартовые файлы из SPF/pack-template - Показывает дорожную карту наполнения с оценками времени ## Что НЕ делает - Не заполняет Pack содержанием — это `/ke` + ручная работа по SPF §03-11 - GitHub-репо предлагает создать командой, не делает автоматически --- ## Шаг 0. Проверка Base-репо (FPF + SPF) Проверить существование `SPF/` и `FPF/` в рабочей директории IWE. Если отсутствуют — сообщить пользователю и предложить команды: ```bash cd ~/IWE gh repo clone TserenTserenov/SPF SPF -- --depth=1 # если нет SPF/ gh repo clone ailev/FPF FPF -- --depth=1 # если нет FPF/ ``` Если репо есть — зафиксировать путь к `SPF/pack-template/` для шага 4. --- ## Шаг 1. Домен ≠ Тема (SPF §01) > Задать пользователю **не более 3 вопросов** (все сразу, одним сообщением): 1. **Кто практикует этот домен?** (специальность, профессия, конкретная роль) 2. **Что они производят?** (артефакты, рабочие продукты — конкретные документы, системы, решения) 3. **Как типично ошибаются?** (3-5 failure modes — что идёт не так в этой практике) **Если ответ — «интересуюсь темой X»**, объяснить различение: > Тема = область интереса (нет собственных методов и артефактов). > Домен = практика с методами, рабочими продуктами и failure modes. > > Тест: «Есть ли люди, которые ДЕЛАЮТ это профессионально? Что они производят?» > > Примеры: «машинное обучение» — тема. «Разработка ML-систем» — домен (есть: ML-инженеры, модели, метрики качества, failure modes). «Системное мышление» — тема. «Системный анализ» — домен. Если пользователь затрудняется — помочь найти практиков и артефакты через уточняющие вопросы (до 2 дополнительных). --- ## Шаг 2. Имя Pack (SPF §01 §4) Имя Pack = **существительное, узнаваемое практикам** домена. **Критерии (все обязательны):** - Специфично: исключает соседние домены (не «управление», а «управление продуктом») - Широко: включает ядро методов, не только один инструмент - Узнаваемо: практик домена сразу понимает, о чём это - Slug: латиница, kebab-case, ≤30 символов **Предложить 2-3 варианта** с пояснением, затем дать выбор пользователю. Формат: `PACK-{slug}` (например: `PACK-product-management`, `PACK-system-analysis`, `PACK-digital-marketing`). Эталоны из IWE: `PACK-digital-platform`, `PACK-education`, `PACK-personal`, `PACK-verification`. **Антипримеры:** - `PACK-everything` — слишком широко - `PACK-jira` — инструмент, а не домен - `PACK-notes` — нет практики и артефактов --- ## Шаг 3. Bounded Context (SPF §02) Заполнить три поля вместе с пользователем: | Поле | Содержание | |------|-----------| | Что входит | 3-5 ключевых методов и практик домена | | Что не входит | Соседние домены (граница) | | Ключевые термины | 5-7 терминов, специфичных для домена (UL) | Итог → запишется в `01-domain-contract/01A-bounded-context.md` --- ## Шаг 4. Scaffold структуры Создать `~/IWE/PACK-{slug}/` со следующей структурой: ``` PACK-{slug}/ ├── README.md ← название + одно предложение о домене ├── REPO-TYPE.md ← тип: Pack, upstream: FPF + SPF ├── CLAUDE.md ← инструкции для агента в этом Pack ├── 00-pack-manifest.md ← метаданные + entity index ├── ontology.md ← термины домена (UL) ├── 01-domain-contract/ │ ├── 01A-bounded-context.md ← из Шага 3 │ └── 01B-distinctions.md ← ключевые различения (заготовка) ├── 02-domain-entities/ ← сущности: роли, методы, WP ├── 03-methods/ ← методы практики ├── 04-work-products/ ← рабочие продукты ├── 05-failure-modes/ ← типичные ошибки ├── 06-sota/ ← состояние области └── 07-map/ ← карта домена ``` **Заполнить стартовые файлы:** `README.md` — одна строка описания домена. `REPO-TYPE.md`: ```markdown # Тип репозитория **Тип**: `Pack` **Source-of-truth**: yes ## Область {название домена и что покрывает} ## Upstream dependencies - [TserenTserenov/SPF](https://github.com/TserenTserenov/SPF) — Second Principles Framework - [ailev/FPF](https://github.com/ailev/FPF) — First Principles Framework ## Non-goals - НЕ содержит кода и конфигураций (→ DS) - НЕ содержит планов и реестров (→ DS/governance) ``` `CLAUDE.md` — минимальный, содержит: ```markdown # PACK-{slug} Source-of-truth для домена: {название}. Структура: SPF/pack-template. Upstream: FPF, SPF. При работе с этим Pack: читать 00-pack-manifest.md для навигации. ``` `01-domain-contract/01A-bounded-context.md` — из Шага 3. `01-domain-contract/01B-distinctions.md` — шаблон: ```markdown # Ключевые различения {домена} > Источник: FPF A.7 (Strict Distinction) > Критерий: если два термина часто путают — это различение. | Различение | Определение A | Определение B | Тест | |-----------|--------------|--------------|------| | X ≠ Y | ... | ... | ... | ``` `00-pack-manifest.md` — взять шаблон из `SPF/pack-template/00-pack-manifest.md`, заполнить `pack_id` и `pack_name`. Затем инициализировать репо и установить CI guard: ```bash cd ~/IWE/PACK-{slug} git init # Установить CI guard (ID collision detector) IWE_TEMPLATE="${IWE_TEMPLATE:-$HOME/IWE/FMT-exocortex-template}" if [ -d "$IWE_TEMPLATE/pack-templates/.github" ]; then cp -r "$IWE_TEMPLATE/pack-templates/.github" . fi git add -A git commit -m "feat: initial scaffold PACK-{slug} (SPF/pack-template) + CI guard R4" ``` CI guard — GitHub Action, который при каждом push/PR проверяет уникальность ID (DP.M.NNN, AR.NNN и т.д.) и блокирует слияние при коллизии. Опционально — создать на GitHub: ```bash gh repo create {GITHUB_USER}/PACK-{slug} --private --source=. --push ``` --- ## Шаг 5. Дорожная карта наполнения Показать пользователю план — что делать дальше: ``` ═══════════════════════════════════════════════════════ PACK-{slug} — дорожная карта наполнения ═══════════════════════════════════════════════════════ Сейчас: scaffold готов. Pack пустой — ценность появится после Ф1. [ ] Ф1. РАЗЛИЧЕНИЯ (SPF §03) ← начать здесь Файл: 01-domain-contract/01B-distinctions.md Цель: 7-10 ключевых различений домена Время: ~1-2ч Как: перечислить что часто путают; проверить каждое на FPF A.7 Инструмент: /ke — фиксировать различения в процессе работы с доменом [ ] Ф2. СУЩНОСТИ (SPF §04) Файл: 02-domain-entities/ Цель: перечислить роли, WP, методы — без детального описания Время: ~1-2ч Как: ответить на вопрос «кто делает, что производит, как проверяет?» [ ] Ф3. МЕТОДЫ (SPF §07) Файл: 03-methods/ Цель: описать ключевые методы практики Время: ~2-4ч Шаблон: для каждого метода — входы, выходы, критерии качества [ ] Ф4. РАБОЧИЕ ПРОДУКТЫ (SPF §07) Файл: 04-work-products/ Цель: описать артефакты практики Время: ~1-2ч Шаблон: название, описание, критерии готовности (Definition of Done) [ ] Ф5. FAILURE MODES (SPF §08) ← высокая ценность Файл: 05-failure-modes/ Цель: 5-10 типичных ошибок домена Время: ~1ч Формат: FM.NNN — причина, сигнал, как избежать [ ] Ф6. SOTA (SPF §09) — опционально, в последнюю очередь Файл: 06-sota/ Цель: ключевые источники, версия знания Время: ~1-2ч ═══════════════════════════════════════════════════════ Инструменты для наполнения: /ke — захват знания в Pack в процессе работы /fpf — проверить корректность сущностей по FPF A.* SPF/process/03-distinctions-work.md — детальный процесс для Ф1 SPF/process/08-failure-modes-extraction.md — процесс для Ф5 ═══════════════════════════════════════════════════════ Принцип: Pack не заполняется за один присест. Первая ценность — 7-10 различений (Ф1, 1-2ч). Дальше Pack растёт в процессе работы с доменом через /ke. ```