OpeItcLoc03/skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(skills): repatriate workshop-promote-brainstorm source (was orphan, only in ~/.agents/skills); session-health v0.1.1 — handoff is mappa entity, not .tasks/NEXT_SESSION.md (#983)

Browse Source
This commit is contained in:
vitya
2026-08-24 17:19:28 +03:00
parent afca818a05
commit c53ed66ba5
4 changed files with 436 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
dist/session-health.skill vendored
View File

Binary file not shown.

BIN
dist/workshop-promote-brainstorm.skill vendored Normal file
View File

Binary file not shown.

8
skills/session-health/SKILL.md
View File

@@ -1,7 +1,7 @@
---
name: session-health
author: ours
version: 0.1.0
version: 0.1.1
description: >
Реагировать на предупреждения session-health поллера pi (сообщение
«[session-health warn/propose/refuse] ...» с цифрами контекста) ИЛИ на
@@ -44,7 +44,7 @@ description: >
| Уровень | % эффективного окна | Действие |
|---|---|---|
| `warn` | 70% | Планируй сворачивание: завершай текущую единицу работы, не начинай новых крупных. |
| `propose` | 85% | **Предложи closing ritual** (скил session-handoff): handoff-write в `.tasks/NEXT_SESSION.md` + сводка; рекомендация, не обязаловка. |
| `propose` | 85% | **Предложи closing ritual** (скил session-handoff): handoff-write (mappa handoff-сущность) + сводка; рекомендация, не обязаловка. |
| `refuse` | 100% | **Отказ от новой работы.** Только завершение: closing ritual и сворачивание. |
Числа по умолчанию (deepseek-v4-flash, эффективное 400K): warn 280K / propose
@@ -62,7 +62,7 @@ description: >
4. **propose** — предложи closing ritual:
- Это **предложение** оператору, не принуждение: «рекомендую завершить, контекст 85%+; закругляемся?» Оператор может продолжить — тогда работай дальше, но помни что контекст некомфортный (будь короче, не тяни лишние чтения).
- Handoff-write в `.tasks/NEXT_SESSION.md` (скил `session-handoff`) — **только после явного согласия оператора** на сворачивание. Без согласия — не пиши.
- Handoff-write через скил `session-handoff` (mappa handoff-сущность) — **только после явного согласия оператора** на сворачивание. Без согласия — не пиши.
- Опционально (если оператор согласен и есть кандидаты): предложи wiki-ingest сессионного знания и закрытия тасок с доски — тоже как предложения, не мутации.
5. **refuse** — жёсткий отказ:
@@ -80,7 +80,7 @@ description: >
## Side effects
- При propose/refuse — пишется `.tasks/NEXT_SESSION.md` (handoff) и предлагаются wiki-ingest / закрытие тасок.
- При propose/refuse — пишется handoff-сущность mappa (скил session-handoff) и предлагаются wiki-ingest / закрытие тасок.
- Отказ от новой работы (refuse) может расстроить оператора — объясни почему, предложи альтернативу (новая сессия).
## What NOT to do

432
skills/workshop-promote-brainstorm/SKILL.md Normal file
View File

@@ -0,0 +1,432 @@
---
name: workshop-promote-brainstorm
author: ours
version: 1.1.0
description: >
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 <topic>», «выкати в вики», «promote <topic>».
- Пользователь явно ссылается на `.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:
```yaml
---
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`:
```markdown
---
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:
```yaml
---
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. **Архивация:**
```bash
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` — действие выходит за пределы мастерской, изменяет соседний репозиторий.