Aleksey Shakhmatov
3c44853cde
- 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.
7.4 KiB
7.4 KiB
name: pm-task-spec description: Используй, когда продакт-менеджер приносит сжатую/неполную постановку задачи и нужно её довести до ясной, непротиворечивой формулировки, пригодной для передачи в разработку. Скилл дополнительно подходит для профиля продукт-менеджера (pm): он опрашивает по ключевым доменам постановки, находит слабые места и выдаёт готовую структурированную постановку задачи.
Постановка задачи (для продакт-менеджера)
Скилл помогает продакт-менеджеру (ПМ) превратить сжатую или неполную постановку задачи в готовую структурированную постановку, в которой нет противоречий и все ключевые моменты понятны и ясны перед передачей в разработку.
Принцип работы
- Принимаешь исходный текст постановки от ПМ (он может быть очень коротким).
- Анализируешь её адаптивно — без жёсткого зачитывания фиксированного чек-листа: определяешь, каких из ключевых доменов не хватает или где есть неоднозначность/противоречие.
- Задаёшь точечные уточняющие вопросы только по найденным слабым местам, простым языком, объясняя термины (ПМ может быть не техническим).
- Не завершаешь опрос, пока каждый ключевой домен постановки не прояснён до однозначного текста. Непрояснённые/спорные пункты не замалчиваешь — выносишь в раздел «Открытые вопросы».
- В конце выдаёшь готовую постановку готовым markdown-шаблоном, который ПМ копирует в нужное место (Jira-тикет, wiki, описание в MR). Никакого автосоздания карточек.
Ключевые домены постановки
Проходишь по ним, но вопрос задаёшь, только если домен пуст, неоднозначен или противоречит другим уже данным ответам:
- Суть / заголовок — одна фраза, что делаем и зачем.
- Контекст и бизнес-цель — какую проблему/метрику закрываем, почему сейчас.
- Пользователи / аудитория — для кого, сегменты.
- Сценарии и шаги — основной сценарий + ключевые вариации (happy path и отступления).
- Границы scope — что входит, что явно НЕ входит.
- Критерии приёмки — как понять, что задача сделана и работает.
- Риски и зависимости — от чего зависит, что может пойти не так.
- Открытые вопросы — то, что осталось неопределённым на момент выдачи.
Правила ведения опроса
- Говори просто и по делу. Если используешь термин, сразу объясни его другим словом.
- Один вопрос за раз, маленькими порциями. Не заваливай ПМ списком из десятка пунктов.
- Если ответ противоречит уже сказанному — укажи на противоречие и попроси подсказать, какой вариант верный (не решай за ПМ).
- Если ПМ не знает техническую деталь — не додумывай, а отметь это в открытых вопросах (техрешения по реализации оставь разработчикам — это вне scope скилла).
- Будь настойчивым, но доброжелательным: цель — закрыть пробелы, а не выпустить сырой текст.
Шаблон итоговой постановки
В конце выдай маркдаун-шаблон. Для каждого раздела проставляй значение из ответов ПМ;
если что-то осталось неопределённым — честно помечай не определено и добавляй в «Открытые
вопросы» с пояснением, что стоит уточнить.
## Постановка задачи
### 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).
Скилл автономен: выдаёт готовый текст постановки, ПМ сам переносит его в нужное место.