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

name, description

name

description

meeting-room-promote-brainstorm

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 », «выкати в вики», «promote ».
• Пользователь явно ссылается на .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:

     ---
     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. Архивация:

   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 — теряется история.