discussions/.claude/skills/meeting-room-promote-brainstorm/SKILL.md

---
name: meeting-room-promote-brainstorm
description: Use when user says "промоутни брейнсторм", "finalize <topic>", "выкати в вики", "promote <topic>", or wants to finalize a .brainstorm/<topic>.md buffer. Asks routing (room-meta vs domain), writes to local .wiki/concepts/ OR ingests into target project's wiki via mcp__projects-meta__knowledge_ingest, extracts action-items into target project's .tasks via mcp__projects-meta__tasks_create, creates a [<topic>-review] umbrella task in the target project blocked by impl-tasks for cross-project review handoff, archives buffer to .archive/<date>-<topic>.md.
---

# meeting-room-promote-brainstorm

Финализирует созревший брейнсторм-буфер. По правилу C+ii из spec'а: room-meta → локальный `.wiki/concepts/`, domain → глобал через `projects-meta`; буфер уезжает в `.archive/`.

## When to use

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

## Inputs

- Путь `.brainstorm/<topic>.md` или просто `<topic>`.

## Decision flow

```
.brainstorm/<topic>.md
        │
        ▼
   read + summarize (1–2 paragraphs)
        │
        ▼
ask: room-meta or domain?
   │              │
   │              ▼
   │       ask: target project (validate ~/projects/<proj>/ exists)
   │              │
   ▼              ▼
write to       ingest via
.wiki/concepts mcp__projects-meta__knowledge_ingest
   │              │
   └──────┬───────┘
          ▼
   parse action-items, show, allow edit
          │
          ▼
   for each: mcp__projects-meta__tasks_create
          │
          ▼
   if domain && N≥1: tasks_create [<topic>-review] (blocked-by impl)
          │
          ▼
   git mv .brainstorm/<topic>.md .archive/<date>-<topic>.md
          │
          ▼
   append to .wiki/log.md
```

## Steps

1. **Прочитать `.brainstorm/<topic>.md`.** Показать summary (≤2 абзаца).
2. **Спросить тип:** room-meta (методология самой комнаты) или domain (доменное содержимое для какого-то целевого проекта)?
3. **Если domain:**
   - Спросить целевой проект (имя папки в `~/projects/`).
   - Валидация: вызвать `mcp__projects-meta__meta_status`, убедиться что проект известен; иначе — abort с сообщением «зарегистрируй проект через setup-projects-meta».
4. **Парсинг action-items:**
   - regex по строкам вида `- [ ] ...`, `- [ ]`, секции после `## Следующие шаги`/`## TODO`/`## Next steps`/`## Action items`.
   - Показать список, дать редактировать/удалять/добавлять.
   - Если 0 action-items — продолжить, не блокировать.
5. **Промоушен контента:**
   - **room-meta:** `Write` → `.wiki/concepts/<topic>.md` с frontmatter:

     ```yaml
     ---
     date: <YYYY-MM-DD>
     source: .brainstorm/<topic>.md
     status: promoted
     type: room-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`. Сообщить пользователю.

6. **Создание тасок:** для каждого action-item:
   - `mcp__projects-meta__tasks_create` с `project: <target>` (для domain) или с `project: <inferred-from-buffer>` (для room-meta это может быть `meeting-room` или конкретный проект упомянутый в action-item — спросить пользователя если неоднозначно).
   - Title — первая строка action-item; description — остальное.
   - Если N-я таска упала — продолжить остальные, в конце сообщить какие созданы / какие нет.
   - Запомнить slug'и созданных импл-тасок для шага 6.5.

6.5. **Review-чекпоинт** (только для domain-промоушена с N≥1 импл-тасок; для room-meta или N=0 — skip с пометкой в логе):
   - `mcp__projects-meta__tasks_create`:
     - `target_project: <target>`
     - `slug: <topic>-review`
     - `status: blocked`
     - `blocker:` `«impl-tasks: <comma-separated slugs из шага 6>»`
     - `description:` шаблон ниже.
     - `next_action:` «Дождаться 🟢 у всех blocker-тасок. Прочитать спецификацию (см. путь в description). Для каждой импл-таски: `git show <commit>`, прогнать тесты в её scope'е, сверить с acceptance criteria. Findings → новые follow-up tasks через `mcp__projects-meta__tasks_create`.»
   - Description шаблон:

     ```
     Code-review checkpoint для брейнсторма <topic> (промоушен <YYYY-MM-DD>).

     **Спецификация:** <путь к промоушенному design-документу — concepts/<topic>.md в target-wiki или claude-skills/.wiki/concepts/<topic>-design.md, в зависимости от того куда ушёл ingest>.
     **Импл-таски (review против их acceptance criteria):** <list slug'ов из шага 6>.

     **Кто делает:** **не имплементер.** Следующая сессия в этом проекте (другая модель / другой день / другой агент) поднимает таску с чистым контекстом. «Я только что это написал» 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.
     ```

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

7. **Архивация:**

   ```bash
   git mv .brainstorm/<topic>.md .archive/<YYYY-MM-DD>-<topic>.md
   ```

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

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

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

9. **Финальный отчёт пользователю:**
   - Куда промочено (полный путь).
   - Какие таски созданы (id, title, проект).
   - Куда уехал исходник.

## Failure modes

- `.brainstorm/<topic>.md` отсутствует → abort.
- `mcp__projects-meta` недоступен → abort до записей.
- Целевой проект (для domain) не найден в `meta_status` → abort.
- `knowledge_ingest` упал → abort до `tasks_create` и `git mv`. Буфер остаётся.
- `tasks_create` упал на N-й таске → продолжить остальные. Сообщить partial. **Не делать** `git mv` без подтверждения пользователя.
- `tasks_create` упал на review-таске (шаг 6.5) → не блокировать; перейти к архивации, сообщить пользователю чтобы создал вручную из `.archive/`.

## Side effects

- room-meta: создаёт `.wiki/concepts/<topic>.md`.
- domain: создаёт запись в target wiki через MCP.
- Создаёт N тасок в target `.tasks/` через MCP.
- Для domain с N≥1: создаёт зонтичную `<topic>-review` таску (status=blocked, blocker=impl-slugs) в том же target.
- Перемещает `.brainstorm/<topic>.md` → `.archive/<date>-<topic>.md`.
- Аппендит строку в `.wiki/log.md`.

## What NOT to do

- Не писать доменное содержимое в локальный `.wiki/concepts/` (правило #1 из root `CLAUDE.md`).
- Не создавать локальный `.tasks/` (правило #3).
- Не делать `git mv` буфера до успеха ingest+tasks.
- Не удалять буфер вместо `git mv` — теряется история.