$npx -y skills add TserenTserenov/FMT-exocortex-template --skill pack-newCreate a new Pack — guided flow through SPF: choose domain, name Pack, scaffold structure, fill roadmap.
| 1 | # Pack New — создание нового Pack |
| 2 | |
| 3 | Создаём Pack для домена: $ARGUMENTS |
| 4 | |
| 5 | ## Что делает этот скилл |
| 6 | |
| 7 | - Проверяет наличие Base-репо (FPF, SPF) и клонирует при отсутствии |
| 8 | - Проводит через SPF §01 (выбор домена) |
| 9 | - Проверяет узнаваемость домена/имени на одном внешнем источнике (SoTA-Sheet-lite) |
| 10 | - Предлагает provisional-имя Pack по критериям SPF, фиксирует отклонённые варианты (PFAD-lite) и финализирует имя после первых различений |
| 11 | - Уточняет bounded context (SPF §02) |
| 12 | - Создаёт структуру директорий и стартовые файлы из SPF/pack-template |
| 13 | - Показывает дорожную карту наполнения с оценками времени |
| 14 | |
| 15 | ## Что НЕ делает |
| 16 | |
| 17 | - Не заполняет Pack содержанием, кроме стартового SoTA Sheet из Шага 1.5 (см. Шаг 4) — остальное это `/ke` + ручная работа по SPF §03-11 |
| 18 | - GitHub-репо предлагает создать командой, не делает автоматически |
| 19 | |
| 20 | --- |
| 21 | |
| 22 | ## Шаг 0. Проверка Base-репо (FPF + SPF) |
| 23 | |
| 24 | Проверить существование `SPF/` и `FPF/` в рабочей директории IWE. |
| 25 | |
| 26 | Если отсутствуют — сообщить пользователю и предложить команды: |
| 27 | |
| 28 | ```bash |
| 29 | cd ~/IWE |
| 30 | gh repo clone TserenTserenov/SPF SPF -- --depth=1 # если нет SPF/ |
| 31 | gh repo clone ailev/FPF FPF -- --depth=1 # если нет FPF/ |
| 32 | ``` |
| 33 | |
| 34 | Если репо есть — зафиксировать путь к `SPF/pack-template/` для шага 4. |
| 35 | |
| 36 | Зафиксировать также РП, в контексте которого запущен `/pack-new` (из активной сессии — WP Gate уже должен быть пройден до вызова этого скилла per Pack Creation Gate). Если Pack создаётся вне контекста РП — зафиксировать `wp: —`. Нужно для `wp:` в frontmatter `.pfad-decision.md` на Шаге 4. |
| 37 | |
| 38 | --- |
| 39 | |
| 40 | ## Шаг 1. Домен ≠ Тема (SPF §01) |
| 41 | |
| 42 | > Задать пользователю **не более 3 вопросов** (все сразу, одним сообщением): |
| 43 | |
| 44 | 1. **Кто практикует этот домен?** (специальность, профессия, конкретная роль) |
| 45 | 2. **Что они производят?** (артефакты, рабочие продукты — конкретные документы, системы, решения) |
| 46 | 3. **Как типично ошибаются?** (3-5 failure modes — что идёт не так в этой практике) |
| 47 | |
| 48 | **Если ответ — «интересуюсь темой X»**, объяснить различение: |
| 49 | > Тема = область интереса (нет собственных методов и артефактов). |
| 50 | > Домен = практика с методами, рабочими продуктами и failure modes. |
| 51 | > |
| 52 | > Тест: «Есть ли люди, которые ДЕЛАЮТ это профессионально? Что они производят?» |
| 53 | > |
| 54 | > Примеры: «машинное обучение» — тема. «Разработка ML-систем» — домен (есть: ML-инженеры, модели, метрики качества, failure modes). «Системное мышление» — тема. «Системный анализ» — домен. |
| 55 | |
| 56 | Если пользователь затрудняется — помочь найти практиков и артефакты через уточняющие вопросы (до 2 дополнительных). |
| 57 | |
| 58 | --- |
| 59 | |
| 60 | ## Шаг 1.5. Источники домена (SoTA-Sheet-lite) |
| 61 | |
| 62 | > Источник принципа: FPF `E.4.DPF` (source pack — шаг 2 из 11, до драфта паттернов) + `G.2` облегчённый вариант («1-page SoTA Sheet», informative). Полный `G.2` (CorpusLedger/ClaimSheets/BridgeMatrix) избыточен для личного Pack. |
| 63 | |
| 64 | Прежде чем выбирать имя (Шаг 2), быстро проверить: как эту практику называют и описывают сами практики — не по памяти агента, а по одному внешнему источнику. |
| 65 | |
| 66 | Задать пользователю (или найти самостоятельно, если пользователь не эксперт): |
| 67 | 1. **Один авторитетный источник этой практики** — книга, метод, школа, стандарт (не блог) |
| 68 | 2. **2-4 тезиса оттуда**, которые стоит унести в Pack |
| 69 | 3. **Чем подтверждено** — цитата/страница/раздел |
| 70 | |
| 71 | Это не полноценный research pass — цель узкая: проверить, что домен и будущее имя (Шаг 2) не оторваны от реальной практики. Опционально, если время есть: границы применимости источника (validity region), что явно отклонено, когда источник устареет (freshness). |
| 72 | |
| 73 | Если пользователь говорит «источника под рукой нет» — не блокировать, идти дальше. Зафиксировать это явно на Шаге 4 (`sota_sources: none` в манифесте), не молчать. |
| 74 | |
| 75 | **Точка сверки:** после Шага 3 (bounded context) — проверить, не изменилась ли граница домена настолько, что источник и тезисы нужно дополнить. |
| 76 | |
| 77 | --- |
| 78 | |
| 79 | ## Шаг 2. Provisional-имя Pack (SPF §01 §4) |
| 80 | |
| 81 | Имя Pack = **существительное, узнаваемое практикам** домена. |
| 82 | |
| 83 | **Критерии (все обязательны):** |
| 84 | - Специфично: исключает соседние домены (не «управление», а «управление продуктом») |
| 85 | - Широко: включает ядро методов, не только один инструмент |
| 86 | - Узнаваемо: практик домена сразу понимает, о чём это |
| 87 | - Slug: латиница, kebab-case, ≤30 символов |
| 88 | |
| 89 | **Предложить 2-3 варианта** с пояснением, затем дать выбор пользователю. |
| 90 | |
| 91 | Формат: `PACK-{pack_id_slug}` (например: `PACK-product-management`, `PACK-system-analysis`, `PACK-digital-marketing`). |
| 92 | |
| 93 | Эталоны из IWE: `PACK-digital-platform`, `PACK-education`, `PACK-personal`, `PACK-verification`. |
| 94 | |
| 95 | **Антипримеры:** |
| 96 | - `PACK-everything` — слишком широко |
| 97 | - `PACK-jira` — инструмент, а не домен |
| 98 | - `PACK-notes` — нет практики и артефактов |
| 99 | |
| 100 | **Короткий код (`pack_id_code`, WP-474 Ф3-фикс).** Отдельно от `pack_id_slug` (kebab-case, для имени директории) — короткий мнемо-код из 2-4 заглавных латинских букв, используемый как префикс в кодах сущн |