fix(install): gate confluence for every profile and dedup PROFILE selection

- Add 'confluence' (always-enabled, per README) to COMMON_BUNDLED so a default install (no PI_KIT_PROFILE / no tty) no longer silently strips it from settings.json. The allowlist now covers every skill under skills/. - Deduplicate PROFILES in profiles_from_text: skip a canonical name already present, so 'frontend,1' or 'backend backend' no longer causes a redundant 'npx skills add' call or a misleading 'Профили: frontend frontend'. - Ship the multi-profile refactor it builds on: merged profile sets, profile_skills()/add_word() helpers, README updates, and the pm-task-spec bundled skill. Validated: bash -n; functional checks for dedup and allowlist coverage.
2026-08-10 12:11:53 +03:00
parent 0c6e590273
commit 3c44853cde
3 changed files with 244 additions and 80 deletions
@@ -0,0 +1,100 @@
+---
+name: pm-task-spec
+description: Используй, когда продакт-менеджер приносит сжатую/неполную постановку задачи и нужно её довести до ясной, непротиворечивой формулировки, пригодной для передачи в разработку. Скилл дополнительно подходит для профиля продукт-менеджера (pm): он опрашивает по ключевым доменам постановки, находит слабые места и выдаёт готовую структурированную постановку задачи.
+---
+
+# Постановка задачи (для продакт-менеджера)
+
+Скилл помогает продакт-менеджеру (ПМ) превратить сжатую или неполную постановку задачи в
+**готовую структурированную постановку**, в которой нет противоречий и все ключевые моменты
+понятны и ясны перед передачей в разработку.
+
+## Принцип работы
+
+1. Принимаешь исходный текст постановки от ПМ (он может быть очень коротким).
+2. Анализируешь её **адаптивно** — без жёсткого зачитывания фиксированного чек-листа:
+   определяешь, каких из ключевых доменов не хватает или где есть неоднозначность/противоречие.
+3. Задаёшь **точечные уточняющие вопросы** только по найденным слабым местам, простым языком,
+   объясняя термины (ПМ может быть не техническим).
+4. **Не завершаешь опрос, пока каждый ключевой домен постановки не прояснён до однозначного
+   текста.** Непрояснённые/спорные пункты не замалчиваешь — выносишь в раздел «Открытые вопросы».
+5. В конце выдаёшь **готовую постановку** готовым markdown-шаблоном, который ПМ копирует
+   в нужное место (Jira-тикет, wiki, описание в MR). Никакого автосоздания карточек.
+
+## Ключевые домены постановки
+
+Проходишь по ним, но вопрос задаёшь, только если домен пуст, неоднозначен или противоречит
+другим уже данным ответам:
+
+- **Суть / заголовок** — одна фраза, что делаем и зачем.
+- **Контекст и бизнес-цель** — какую проблему/метрику закрываем, почему сейчас.
+- **Пользователи / аудитория** — для кого, сегменты.
+- **Сценарии и шаги** — основной сценарий + ключевые вариации (happy path и отступления).
+- **Границы scope** — что входит, что явно НЕ входит.
+- **Критерии приёмки** — как понять, что задача сделана и работает.
+- **Риски и зависимости** — от чего зависит, что может пойти не так.
+- **Открытые вопросы** — то, что осталось неопределённым на момент выдачи.
+
+## Правила ведения опроса
+
+- Говори просто и по делу. Если используешь термин, сразу объясни его другим словом.
+- Один вопрос за раз, маленькими порциями. Не заваливай ПМ списком из десятка пунктов.
+- Если ответ противоречит уже сказанному — укажи на противоречие и попроси подсказать,
+  какой вариант верный (не решай за ПМ).
+- Если ПМ не знает техническую деталь — не додумывай, а отметь это в открытых вопросах
+  (техрешения по реализации оставь разработчикам — это вне scope скилла).
+- Будь настойчивым, но доброжелательным: цель — закрыть пробелы, а не выпустить сырой текст.
+
+## Шаблон итоговой постановки
+
+В конце выдай маркдаун-шаблон. Для каждого раздела проставляй значение из ответов ПМ;
+если что-то осталось неопределённым — честно помечай `не определено` и добавляй в «Открытые
+вопросы» с пояснением, что стоит уточнить.
+
+```markdown
+## Постановка задачи
+
+### 1. Суть / заголовок
+<одна фраза: что делаем и для чего>
+
+### 2. Контекст и бизнес-цель
+- Проблема: <что не так сегодня>
+- Цель/метрика: <что должно измениться, на чём меряем успех>
+- Почему сейчас: <предпосылки/драйвер>
+
+### 3. Пользователи / аудитория
+<кто, сегменты>
+
+### 4. Сценарии и шаги
+- Основной сценарий: <шаг за шагом>
+- Вариации / отступления: <ключевые edge-случаи>
+
+### 5. Границы scope
+- Входит: <...>
+- Не входит: <явные исключения>
+
+### 6. Критерии приёмки
+<как понять, что задача решена; желательно проверяемо>
+
+### 7. Риски и зависимости
+<от чего зависит, что может пойти не так>
+
+### 8. Открытые вопросы
+<пункты, которые осталось уточнить; пометь, кому адресован>
+```
+
+## Non-goals
+
+Этот скилл — **организатор постановки**, а не техконсультант-исполнитель. Он:
+
+- **не** консультирует по архитектуре/реализации в Go и других языках;
+- **не** оценивает трудозатраты и сроки;
+- **не** создаёт/обновляет/таскает Jira-тикеты автоматически;
+- **не** заменяет прямое обсуждение ПМ с разработчиками — наоборот, готовит материал
+  для такого обсуждения.
+
+## Интеграция
+
+Контекст — наша компания: трекер **Jira** (см. скилл `jira-workflow`), git-хост
+**gitlab.tech.mvideo.ru** (см. `repo-map`), документация **wiki.mvideo.ru** (см. `docs-map`).
+Скилл автономен: выдаёт готовый текст постановки, ПМ сам переносит его в нужное место.