skills/skills/workshop-promote-brainstorm/SKILL.md

name, author, version, description

name	author	version	description
workshop-promote-brainstorm	ours	1.1.0	Finalize a matured brainstorm buffer on the boss's desk (~/projects/.workshop/.brainstorm/): ask routing (workshop-meta → local .wiki/concepts/, domain → target project wiki via knowledge_ingest, skill → claude-skills skeleton), extract action-items into target .tasks, create pointers + review umbrella for impl tasks, archive the buffer. Location-agnostic: fires from ANY folder; all paths resolve to ~/projects/.workshop/ regardless of CWD. Triggers (user): «промоутни брейнсторм», «finalize <topic>», «выкати в вики», «promote <topic>».

workshop-promote-brainstorm

Финализирует созревший брейнсторм-буфер на столе босса (~/projects/.workshop/). Три ветки маршрутизации:

Location-agnostic. Скил триггерится из любой папки — босс-штормы происходят где угодно, запись живёт на столе. Все относительные пути ниже (.brainstorm/, .archive/, .wiki/, index.md) разрешаются относительно ~/projects/.workshop/ независимо от CWD; git-команды явно указывают -C ~/projects/.workshop.

• workshop-meta → локальный .wiki/concepts/ (методология самой зоны).
• domain → глобал через mcp__projects-meta__knowledge_ingest в ~/projects/<proj>/.wiki/.
• skill → ~/projects/claude-skills/skills/<name>/SKILL.md (только шапка + пустой каркас тела, локальный коммит без push/install/build-hermes).

Буфер уезжает в .archive/. Action-items уходят тасками в target-проект. Всегда, при любом маршруте, в воркшоп-вики остаётся summary-страница.

When to use

• «промоутни брейнсторм», «finalize », «выкати в вики», «promote ».
• Пользователь явно ссылается на .workshop/.brainstorm/<topic>.md как на готовый к промоушену.

Inputs

• Путь .brainstorm/<topic>.md или просто <topic>.
• Для skill-ветки дополнительно: <name> нового скила (если не указан — спросить, предложить производное от topic).

Decision flow

.brainstorm/<topic>.md
        │
        ▼
   read + summarize (1–2 paragraphs)
        │
        ▼
   ask: workshop-meta or domain or skill?
   │              │              │
   │              ▼              ▼
   │        ask: target proj  ask: <name> + check
   │              │           ~/projects/claude-skills/
   │              ▼           skills/<name>/ NOT exists
   │       knowledge_ingest         │
   │              │              ▼
   │              │        dialog: description (trigger contract)
   │              │              │
   │              │              ▼
   │              │        preview + confirm
   │              │              │
   │              │              ▼
   ▼              │        mkdir + Write SKILL.md
write to          │        (header + empty 6-section skeleton)
.wiki/concepts    │              │
   │              │              ▼
   │              │        git add + commit in claude-skills/
   │              │        (local, no push, no install.sh, no build-hermes)
   │              │              │
   └──────────────┴──────────────┘
                        │
                        ▼
        parse action-items + (for skill: prepend 3 baselines)
                        │
                        ▼
        for each: mcp__projects-meta__tasks_create
                        │
                        ▼
   if domain && N≥1: tasks_create [<topic>-review] (blocked-by impl)
   if skill:         tasks_create [<name>-review]  (blocked-by impl, behavioral smoke-test)
                        │
                        ▼
        Write .wiki/concepts/<topic>.md  ← ВСЕГДА, любой маршрут
        (summary: решения, куда промочено, задачи, ссылки)
                        │
                        ▼
        git -C ~/projects/.workshop mv .brainstorm/<topic>.md .archive/<date>-<topic>.md
                        │
                        ▼
        append to .wiki/log.md

Steps

1. Прочитать .brainstorm/<topic>.md. Показать summary (≤2 абзаца).

2. Спросить тип:

   • workshop-meta — методология самой workshop-зоны: ретро дистилляции, паттерны, апгрейды скилов зоны.
   • domain — доменное содержимое для какого-то целевого проекта.
   • skill — методология общего назначения, оформляется как скил в ~/projects/claude-skills/.

3. Если domain:

   • Спросить целевой проект (имя папки в ~/projects/).
   • Валидация: вызвать mcp__projects-meta__meta_status, убедиться что проект известен; иначе — abort с сообщением «зарегистрируй проект через setup-projects-meta».

4. Если skill:

   • Спросить <name> нового скила (если не указан) — валидный slug ([a-z0-9-]+).
   • Валидация: ~/projects/claude-skills/skills/<name>/ НЕ должна существовать. Если существует — abort с сообщением «скил <name> уже существует, обновляйся обычным маршрутом в claude-skills/, этот скил не для апдейтов».
   • Валидация: ~/projects/claude-skills/ сам репозиторий существует. Если нет — abort с сообщением «клонируй claude-skills/ через update-claude-skills или вручную».

5. Парсинг action-items:

   • regex по строкам вида - [ ] ..., - [ ], секции после ## Следующие шаги/## TODO/## Next steps/## Action items.
   • Показать список, дать редактировать/удалять/добавлять.
   • Если 0 action-items — продолжить, не блокировать.

6. Промоушен контента:

   • workshop-meta: Write → .wiki/concepts/<topic>.md с frontmatter:

     ---
     date: <YYYY-MM-DD>
     source: .brainstorm/<topic>.md
     status: promoted
     type: workshop-meta
     ---
     

     Тело — содержимое буфера (можно слегка причесать заголовки, секции типа TODO убрать — они уже сепарированы в action-items).

   • domain: mcp__projects-meta__knowledge_ingest с параметрами:

     • project: <target>
     • path: concepts/<topic>.md (внутри target wiki)
     • content: <тело буфера с frontmatter>

     Если knowledge_ingest падает → abort до tasks_create и до git mv. Сообщить пользователю.

   • skill: двухпроходной.

     Проход первый (этот скил):

     1. Диалог по description — поведенческий контракт активации скила. Показать пользователю summary буфера и спросить:

        • На каких триггер-фразах скил должен активироваться? (минимум 2-3, лучше — пары русский/английский)
        • Что скил делает в одном предложении?
        • Когда скил не должен активироваться (антипаттерны)?

        Из ответов собрать description строкой ~200-400 символов в стиле существующих скилов (см. ~/projects/claude-skills/skills/*/SKILL.md для примеров).

     2. Preview + confirm (обязательно):

        Писать в:    ~/projects/claude-skills/skills/<name>/SKILL.md
        Frontmatter: name=<name>, version=0.1.0, description=<...>
        Body:        пустой каркас с заголовками
                     When to use / Inputs / Steps / Failure modes / Side effects / What NOT to do
        Коммит:      feat(skills): add <name> v0.1.0 (promoted from .workshop/.brainstorm/<topic>.md)
        Без:         install.sh, push, build-hermes (это в созданных тасках)
        ОК?
        

     3. После confirm:

        • mkdir -p ~/projects/claude-skills/skills/<name>/

        • Write файла ~/projects/claude-skills/skills/<name>/SKILL.md:

          ---
          name: <name>
          version: 0.1.0
          description: <вписанный пользователем триггер-контракт>
          ---
          
          # <name>
          
          <одно-два предложения что скил делает — из диалога>
          
          ## When to use
          
          <пусто, дописывается во втором проходе>
          
          ## Inputs
          
          <пусто>
          
          ## Steps
          
          <пусто>
          
          ## Failure modes
          
          <пусто>
          
           ## Side effects
          
          <пусто>
          
          ## What NOT to do
          
          <пусто>
          

        • В ~/projects/claude-skills/: git -C ~/projects/claude-skills add skills/<name>/SKILL.md && git -C ~/projects/claude-skills commit -m "feat(skills): add <name> v0.1.0 (promoted from ~/projects/.workshop/.brainstorm/<topic>.md)".

        • STOP. Не запускать install.sh. Не делать git push. Не править hermes/mapping.yaml. Это всё уйдёт тасками на шаге 7.

     Проход второй — пользователь явно зовёт «доведём <name>» в этой же или следующей сессии. Источник лежит в .archive/<date>-<topic>.md, тело каркаса дописывается глазами. Вне scope этого скила.

7. Создание тасок:

   • domain (mandatory pre-impl) — [<topic>-pointers]: первой создать таску, заполняющую .wiki/CLAUDE.md Domain conventions у target-проекта пойнтерами на спецификацию. Без неё импл-таски будут подняты со stub'ом в Domain conventions, и следующий агент попадёт в дыру: dense where_stopped one-liner + пустой stub = угадывание порогов / таксономий / pipeline-этапов. Параметры:

     • target_project: <target>
     • slug: <topic>-pointers
     • status: ready
     • description: шаблон ниже
     • next_action: готовый блок текста для копирования в .wiki/CLAUDE.md (шаблон ниже)

     Description-шаблон:

     Bootstrap-pointers для design <topic>. Pre-fills target's `.wiki/CLAUDE.md`
     Domain conventions ссылками на спецификацию. Дизайн не лежит в этом репо —
     только pointer-stub. Без этой таски следующий агент попадёт в дыру:
     where_stopped one-liner + пустой Domain conventions stub = угадывание
     порогов / таксономий / pipeline-этапов вместо чтения готовых решений.
     
     **Кто делает:** любой следующий агент в этом проекте. Это первая по
     приоритету таска промоушена — все остальные импл-таски ссылаются на
     pointers через .wiki/CLAUDE.md.
     

     Next-action шаблон (pre-filled, копировать дословно — подменив <topic> и <YYYY-MM-DD>):

     В `.wiki/CLAUDE.md` секции "Domain conventions" вставить блок (или заменить
     дефолтный setup-wiki stub):
     
     ### Mandatory: read design context before implementation
     
     Before picking up any task in `.tasks/`, load the full design context. It
     does **not** live in this repo — only pointers do. Sources, in order:
     
     1. **Global wiki design (canonical):** `mcp__projects-meta__knowledge_get`
        с `slug = "concepts/<topic>"`. Architecture decisions, contracts, scope.
     2. **Brainstorm process trace (rationale):**
        `~/projects/.workshop/.archive/<YYYY-MM-DD>-<topic>.md`.
        Why each decision was made, what was rejected and why, anti-patterns.
     3. **Local `overview.md`** — thin summary of (1), used as quick orientation
        only — never as the source of truth.
     
     Do **not** invent thresholds, taxonomies, container topology, or pipeline
     stages from task `where_stopped` lines alone — those are pointers, not
     specifications.
     
     ---
     
     Закоммитить: `wiki(claude): add design-context pointers for <topic>`.
     

     Конкретные значения, которые промоутер должен подставить заранее в текст next_action перед tasks_create:

     • <topic> — тема промоушена (тот же slug, что используется в concepts/<topic>.md и в .archive/<YYYY-MM-DD>-<topic>.md).
     • <YYYY-MM-DD> — сегодняшняя дата (та же, что в шаге 9 архивации).

     Если tasks_create для <topic>-pointers упала → abort до content-тасок и до review. Без pointers оставшиеся таски бесполезны: импл-агент будет угадывать. Сообщить пользователю, буфер оставить на месте.

   • workshop-meta / domain (content): для каждого action-item:

     • mcp__projects-meta__tasks_create с project: <target> (для domain) или с project: <inferred> (для workshop-meta — спросить пользователя если неоднозначно).
     • Title — первая строка action-item; description — остальное.

   • skill: всегда добавляются три baseline-таски в project: claude-skills:

     • [<name>-install] — запустить install.sh в ~/projects/claude-skills/, проверить что скил активируется в новой сессии, сделать /reload-plugins.
     • [<name>-hermes-mapping] — добавить запись в ~/projects/claude-skills/hermes/mapping.yaml. Режим: auto если скил чисто стилевой / response-style, pending если скил трогает инструменты или окружение (требует отдельного аудита).
     • [<name>-test-trigger] — прогнать триггер-фразы из description на тестовом буфере: убедиться что активируется на своих фразах И не активируется на 2-3 близких чужих (false-positive check).

     Плюс content-таски из самого буфера (если были) — также в project: claude-skills, slug-prefix <name>-.

   • Если N-я таска упала — продолжить остальные, в конце сообщить какие созданы / какие нет.

   • Запомнить slug'и созданных импл-тасок для шага 8.

8. Review-чекпоинт. Создаётся всегда для skill-промоушена; для domain-промоушена — только если N≥1 импл-тасок; для workshop-meta или N=0 (domain) — skip с пометкой в логе.

   • domain (N≥1):

     • mcp__projects-meta__tasks_create:
       • target_project: <target>
       • slug: <topic>-review
       • status: blocked
       • blocker: «bootstrap: <topic>-pointers; impl-tasks: <номера #n через запятую>» — блокеры по номерам (номер = машинный ключ; слаги оставить в скобках для читаемости).
       • description: шаблон ниже.
       • next_action: «Дождаться 🟢 у всех blocker-тасок (включая <topic>-pointers — без него pointers в .wiki/CLAUDE.md не залиты, и review будет читать stub). Прочитать спецификацию (см. путь в description). Для каждой импл-таски: git show <commit>, прогнать тесты в её scope'е, сверить с acceptance criteria. Findings → новые follow-up tasks через mcp__projects-meta__tasks_create.»

     Description-шаблон (domain):

     Code-review checkpoint для брейнсторма <topic> (промоушен <YYYY-MM-DD>).
     
     **Спецификация:** <путь к промоушенному design-документу — concepts/<topic>.md в target-wiki>.
     **Pre-impl bootstrap:** `<topic>-pointers` (заполнил `.wiki/CLAUDE.md` Domain conventions — без него review бы читал stub).
     **Импл-таски (review против их acceptance criteria):** <номера #n из шага 7, слаги в скобках>.
     
     **Кто делает:** **не имплементер.** Следующая сессия в этом проекте (другая модель / другой день / другой агент) поднимает таску с чистым контекстом. «Я только что это написал» bias = главный риск.
     
     **Чек-лист ревью:**
     - Прочитать спецификацию (acceptance criteria каждой импл-таски).
     - `git log --oneline` shipped-коммитов (по slug или scope в commit-message).
     - Для каждой импл-таски: прогнать соответствующие тесты, реально проверить что они доходят до своих веток (не coverage-illusion).
     - Сверить дизайн-decisions со shipped-кодом (signature, params, error-paths, безопасность).
     - Findings — отдельные follow-up tasks (`<topic>-<gap>-fix` или подобное) через `tasks_create`.
     
     **Закрытие:** только когда все findings зафайлены ИЛИ ревьюер подтвердил «нет findings» в close-note.
     

   • skill:

     • mcp__projects-meta__tasks_create:
       • target_project: claude-skills
       • slug: <name>-review
       • status: blocked
       • blocker: «impl-tasks: <name>-install, <name>-hermes-mapping, <name>-test-trigger[, content-impls если были]» — номера #n из шага 7 (слаги в скобках для читаемости).
       • description: шаблон ниже.
       • next_action: «Дождаться 🟢 у baseline-тасок. Прогнать поведенческий smoke-test (см. чек-лист в description). Findings → follow-up tasks через tasks_create.»

     Description-шаблон (skill):

     Skill-review checkpoint для <name> (промоушен <YYYY-MM-DD>).
     
     **Источник дизайна:** .workshop/.archive/<YYYY-MM-DD>-<topic>.md.
     **Импл-таски:** <name>-install, <name>-hermes-mapping, <name>-test-trigger[, content-impls] — номера #n из шага 7.
     
     **Кто делает:** **не имплементер.** Другая сессия / другой день / другой агент. Identity-not-location: ревьюер работает в любой папке, где есть доступ к файлам (см. `.workshop/.wiki/concepts/workshop-architecture.md` §5.1).
     
     **Поведенческий smoke-test (это и есть acceptance):**
     - Скил активируется в чистой сессии на каждой триггер-фразе из `description` (русский И английский варианты).
     - Скил **не** активируется на 2-3 близких но не своих фразах из соседних доменов (false-positive check).
     - Каждый шаг секции `Steps` отрабатывает на тестовом буфере без ошибок.
     - `Failure modes` уводят в abort, не в частичный успех с грязным состоянием.
     - `What NOT to do` соответствует реальности — нет дыры между правилом и реализацией.
     
     Findings — обычные follow-up tasks (`<name>-<gap>-fix` или подобное) через `tasks_create` в `claude-skills`.
     
     **Закрытие:** только когда все findings зафайлены ИЛИ ревьюер подтвердил «нет findings» в close-note.
     
     **NB по семверу:** `version: 0.1.0` записан промоутером. Дальнейшие инкременты — ответственность владельца `claude-skills/`, **не** этого скила и не ревьюера. Если ревью требует правок — правит владелец, бампит он же.
     

   • Если tasks_create review-таски упала — сообщить пользователю, продолжить к шагу 9 (архивация буфера). Review-таску можно создать вручную позже из .archive/<date>-<topic>.md.

9. Workshop-wiki summary (обязательно для всех маршрутов):

   Write → .wiki/concepts/<topic>.md с frontmatter:

   ---
   date: <YYYY-MM-DD>
   source: .brainstorm/<topic>.md → .archive/<YYYY-MM-DD>-<topic>.md
   status: promoted
   type: workshop-meta
   ---
   

   Содержание (≤60 строк):

   • Что решили — ключевые решения раундов (не пересказ, а outcomes).
   • Куда промочено — полный путь: target-wiki / claude-skills / local concepts.
   • Задачи — перечень slug'ов, созданных в шаге 7.
   • Ссылки — архив буфера + связанные концепты в workshop-вики + глобальная вики.

   Для workshop-meta: summary — сокращение полного контента (который уже в .wiki/concepts/<topic>.md шага 6); если шаг 6 уже записал туда полный файл — шаг 9 его дополняет секцией «Куда промочено / Задачи» или пропускается (не дублировать).

   Затем обновить index.md — добавить строку в нужную секцию.

   Если Write упал → сообщить, не блокировать архивацию (summary менее критична чем content-промоушен).

10. Архивация:

    git -C ~/projects/.workshop mv .brainstorm/<topic>.md .archive/<YYYY-MM-DD>-<topic>.md
    

    Только если шаги 6 и 7 прошли (или прошли с допустимым partial — пользователь подтвердил). Иначе — оставить буфер на месте, чтобы можно было ретраиить.

11. Лог: дописать в .wiki/log.md:

    <date> promoted <topic> → <destination> [created N tasks in <proj>]
    

    Для skill — <destination> = claude-skills/skills/<name>/SKILL.md (skeleton).

12. Финальный отчёт пользователю:

    • Куда промочено (полный путь).
    • Какие таски созданы (id, title, проект).
    • Куда уехал исходник.
    • Для skill: напомнить что нужен второй проход «доведём <name>» для дописывания тела каркаса.

Failure modes

• .brainstorm/<topic>.md отсутствует → abort.
• mcp__projects-meta недоступен → abort до записей.
• Целевой проект (для domain) не найден в meta_status → abort.
• knowledge_ingest упал → abort до tasks_create и git mv. Буфер остаётся.
• domain: tasks_create для [<topic>-pointers] упал → abort до content-тасок и до review-таски. Без pointers оставшиеся таски бесполезны (агент будет угадывать). Сообщить пользователю; буфер оставить на месте для retry.
• tasks_create упал на N-й content-таске → продолжить остальные. Сообщить partial. Не делать git mv без подтверждения пользователя.
• tasks_create упал на review-таске (шаг 8) → не блокировать; перейти к архивации, сообщить пользователю чтобы создал вручную из .archive/.
• Skill: ~/projects/claude-skills/ не существует → abort с сообщением «клонируй через update-claude-skills или вручную».
• Skill: ~/projects/claude-skills/skills/<name>/ уже существует → abort с сообщением «скил уже существует, обновляйся обычным маршрутом в claude-skills/».
• Skill: пользователь не подтвердил preview перед записью → abort, состояние не меняется.
• Skill: локальный git commit в claude-skills/ упал (например, не настроен user.email) → файл остаётся, сообщить пользователю что коммит нужно сделать руками; не делать git mv буфера до подтверждения.

Side effects

• Всегда (любой маршрут): создаёт summary-страницу .wiki/concepts/<topic>.md в .workshop/ + добавляет строку в index.md.
• workshop-meta: summary IS контент (шаг 6 записывает полное тело; шаг 9 дополняет секцию «задачи/ссылки» или пропускается если уже полный).
• domain: создаёт запись в target-wiki через MCP (mcp__projects-meta__knowledge_ingest).
• domain: создаёт также mandatory pre-impl таску [<topic>-pointers] в target — pre-filled блок текста для .wiki/CLAUDE.md Domain conventions (ссылки на global wiki slug + workshop archive trace + local overview.md). Без неё последующий импл-агент попадает в дыру: where_stopped one-liner + пустой Domain conventions stub.
• skill: создаёт ~/projects/claude-skills/skills/<name>/SKILL.md — только шапка + пустой каркас. Локальный коммит в claude-skills/. Без установки, push, или build-hermes — это всё в созданных baseline-тасках.
• Создаёт N тасок в target .tasks/ через MCP.
• Для domain (N≥1) или skill: создаёт зонтичную review-таску (status=blocked, blocker=impl-slugs; для domain — также включает <topic>-pointers) в том же target.
• Перемещает .brainstorm/<topic>.md → .archive/<date>-<topic>.md.
• Аппендит строку в .wiki/log.md.
• Семвер скилов: при target=skill промоутер записывает version: 0.1.0 в шапку. Дальнейшие инкременты — ответственность владельца claude-skills/, не этого скила. При попытке промоушена в существующий скил — abort (см. Failure modes).

What NOT to do

• Не писать доменное содержимое в локальный .wiki/concepts/ (правило #1 из .workshop/CLAUDE.md). Summary-страница шага 9 — это trace/навигация, не domain-контент.
• Не пропускать шаг 9 (workshop-wiki summary) — именно так следующая сессия узнаёт что буфер был и куда ушёл.
• Не делать git mv буфера до успеха promotion+tasks.
• Не удалять буфер вместо git mv — теряется история.
• Skill: не пытаться автоматически переформатировать тело буфера в каркас Steps/Failure modes/etc. — это поведенческий контракт, не косметика. Каркас остаётся пустым; тело дописывается во втором проходе глазами.
• Skill: не запускать install.sh. Не делать git push в claude-skills/. Не править hermes/mapping.yaml. Не запускать build-hermes.py. Это работа baseline-тасок, не промоутера.
• Skill: не бампить version после первой записи (это работа владельца claude-skills/).
• Skill: не промоутить в существующий скил (см. Failure modes — abort).
• Skill: не пропускать обязательный preview + confirm перед Write — действие выходит за пределы мастерской, изменяет соседний репозиторий.