code-ai-installer 2.1.0 → 2.3.0

package/domains/product/.agents/skills/user-story/SKILL.md

@@ -0,0 +1,385 @@
+---
+name: user-story
+description: Написание user stories по INVEST — As a / I want / So that, разделение buyer/end-user
+---
+# User Story
+
+> **Категория:** Specification  ·  **Slug:** `user-story`
+
+## Когда использовать
+
+- В PRD — каждая user-facing функциональность.
+- В backlog grooming — преобразование идей в work items.
+- При epic breakdown — story-уровень.
+- В B2B — разделение buyer / end-user / admin stories.
+
+## Вход
+
+| Поле | Обязательно | Описание |
+|------|:-----------:|----------|
+| User role | ✅ | Buyer / end-user / admin / champion |
+| JTBD / problem | ✅ | Что решаем |
+| Context | ✅ | Когда возникает |
+
+## Источники данных
+
+1. `$jtbd-canvas` — jobs как отправная точка.
+2. `$problem-statement` — проблема как «so that».
+3. Customer interviews — язык пользователя.
+
+### Связь с другими скилами
+
+| Скил | Что берём | Когда вызывать |
+|------|-----------|----------------|
+| `jtbd-canvas` | Jobs → «I want» | Перед stories |
+| `problem-statement` | Боль → «so that» | Для обоснования |
+| `acceptance-criteria` | Контракт | На каждую story |
+| `epic-breakdown` | Grouping | После stories |
+
+## INVEST Criteria
+
+Хорошая user story:
+- **I**ndependent — можно разработать независимо
+- **N**egotiable — детали открыты для обсуждения, не зафиксированы
+- **V**aluable — несёт ценность для клиента
+- **E**stimable — команда может оценить effort
+- **S**mall — умещается в 1-2 спринта (< 8 points)
+- **T**estable — чёткие критерии прохождения/непрохождения
+
+## Формат
+
+**Canonical:**
+> **As a** [role]  
+> **I want to** [action / capability]  
+> **So that** [benefit / outcome]
+
+Пример:
+> **As a** DevOps engineer at mid-market SaaS  
+> **I want to** set team-level role templates в 2-3 clicks  
+> **So that** onboarding new teammates takes 10 min, не 2 hours
+
+## Протокол
+
+### Шаг 0 — Ясность ролей (критично для B2B)
+
+**Разные stories для разных roles** — не смешивать в одной:
+- **End-user story** — повседневный опыт использования
+- **Buyer story** — решение о покупке / оценке
+- **Admin story** — конфигурация / governance
+- **Champion story** — продвижение / отчётность
+
+В B2B отдельные stories на роль — разные AC, разные flows.
+
+### Шаг 1 — «So That» First
+
+Писать в обратном порядке — сначала benefit, потом action.
+
+Захватить customer outcome:
+- ❌ «Чтобы пользователи могли использовать новую функцию» (цикличность)
+- ✅ «Чтобы я мог закрыть ежеквартальный compliance-аудит за 2 часа вместо 2 дней»
+
+Benefit — **конкретный, измеримый**, связан с JTBD.
+
+### Шаг 2 — «I Want»
+
+Действие или возможность — что конкретно делает пользователь.
+
+- Атомарное (одно действие)
+- Технологически нейтральное («view team activity» не «click button on dashboard»)
+- Язык пользователя, не инженерный
+
+### Шаг 3 — «As A»
+
+Конкретная роль, не generic «user»:
+- «DevOps-инженер в mid-market SaaS» > «user»
+- «Customer Success Manager с >100 аккаунтами» > «user»
+
+Привязать роль к сегменту (если фича специфична для сегмента).
+
+### Шаг 4 — INVEST Check
+
+Проверить каждую story:
+- **I** — Можно разработать независимо? Если нужны другие stories сначала → split.
+- **N** — Детали открыты для обсуждения? (не переспецифицировано)
+- **V** — Клиент получает value? Если только техническое улучшение → переформулировать через user outcome.
+- **E** — Команда может оценить? Если нет — неизвестное требует spike.
+- **S** — Меньше 2 sprints? Если нет — split.
+- **T** — Можно написать чёткие pass/fail AC?
+
+### Шаг 5 — Разбивка крупных stories
+
+Техники разбивки:
+- **Workflow:** «create → update → delete» → 3 stories
+- **Data:** разные типы сущностей (user → team → organization)
+- **Happy path + edges:** основной flow → error states отдельными stories
+- **Acceptance criteria:** вытащить один scenario за другим из AC
+
+### Шаг 6 — Оценка размера story
+
+T-shirt или Story Points:
+- **S** (1-2 pts): < 1 дня
+- **M** (3-5 pts): 1-3 дня
+- **L** (8 pts): 4-7 дней
+- **XL** (13+ pts): **split**
+
+### Шаг 7 — Заметки по переговорам
+
+Добавить поле «Notes» для:
+- Открытых вопросов
+- Предположений
+- Предложенных границ scope
+
+Это сигналы инженерам: где есть пространство для переговоров.
+
+### Шаг 8 — Добавить AC
+
+Каждая story требует AC через `$acceptance-criteria`.
+
+Без AC story — не готова к спринту.
+
+## Валидация (Quality Gate)
+
+- [ ] Формат: As a / I want / So that
+- [ ] Роль — конкретная, не generic «user»
+- [ ] B2B: разделено по роли (если multi-role flow)
+- [ ] «So that» — конкретная, измеримая польза
+- [ ] INVEST пройден (все 6)
+- [ ] Размер ≤ 8 pts (или split)
+- [ ] AC прикреплены
+- [ ] Notes / предположения явны
+
+## Handoff
+
+Результат является входом для:
+- **`acceptance-criteria`** — каждая story
+- **`epic-breakdown`** — grouping
+- **Engineering** → implementation
+- **QA** → test cases
+
+Формат: story card (заголовок + as-I-so-that + notes + ссылка на AC). Через `$handoff`.
+
+## Anti-patterns
+
+| Ошибка | Почему плохо | Как правильно |
+|--------|-------------|---------------|
+| Роль «User» | Потеря контекста | Конкретная роль/сегмент |
+| Расплывчатое «so that» | Потеря ценности | Измеримая польза |
+| Реализация в story | Переспецификация | Действие, не UI |
+| Смешение ролей в одной story | Запутанные AC | Разделять по роли |
+| Большие (>13 pt) | Невозможно оценить | Разбить техниками |
+| Нет AC | Нет контракта | Обязательно иметь AC |
+| «As developer I want refactor» | Не ценность клиента | Перевести в user outcome |
+
+## Шаблон
+
+```markdown
+## Story: [Краткое название]
+
+**As a** [конкретная роль]
+**I want to** [действие]
+**So that** [измеримая польза]
+
+### Notes
+- Предположение: [X]
+- Открытый вопрос: [Y]
+
+### Acceptance Criteria
+[через $acceptance-criteria]
+
+### Размер
+M (3-5 points)
+
+### Зависимости
+- Story [#123] (предпосылка)
+```
+
+## Worked Example — TeamFlow User Stories for AI Summarization
+
+**Контекст:** 14 user stories в PRD всего. Ниже — 7 ключевых stories с правильным INVEST + разделением ролей B2B. Демонстрируют технику разбивки: end-user vs admin vs buyer.
+
+### Stories сгруппированы по роли
+
+---
+
+#### Роль: People Manager (end-user) — Основная
+
+**Story S1: Включить AI Summarization для предстоящего 1:1**
+
+**As a** People manager с 5+ прямыми подчинёнными в mid-market B2B SaaS компании на Team Tier  
+**I want to** переключить «AI assist» для предстоящего 1:1 одним кликом  
+**So that** я могу полностью сосредоточиться на разговоре, не беспокоясь о заметках
+
+**Notes:**
+- Состояние по умолчанию: выключено (opt-in уважает приватность), пользователь активирует на каждую встречу
+- Admin может установить включено по умолчанию для всех новых 1:1 (настройка организации, S7)
+- Предположение: менеджеры предпочитают контроль на каждую встречу. Валидировано в Discovery E2-E4.
+- Открытый вопрос: применяется ли переключатель ко всей встрече или до/после событий переключения? → уточнить в AC
+
+**AC:** [см. `$acceptance-criteria` сценарии S1 — всего 4]
+
+**Размер:** S (2 points) — UI переключатель, проверка feature flag, settings API  
+**Зависимости:** T1 (инфраструктура feature flag)  
+**Валидация роли:** INVEST пройден (independent, negotiable, valuable, estimable, small, testable)
+
+---
+
+**Story S2: Получить AI-сводку в течение 60 секунд после окончания встречи**
+
+**As a** People manager, завершивший AI-enabled 1:1  
+**I want to** получить структурированную сводку (темы, решения, action items) в течение 60 секунд после окончания встречи  
+**So that** я могу проверить и подтвердить её перед переходом к следующей задаче
+
+**Notes:**
+- Streaming UX приемлем — сводка заполняется постепенно в течение 60s
+- Порог качества: ≥70% сводок приемлемы без существенных правок (измеряется через S3)
+- Предположение: 60s ощущается мгновенно; 90s ощущается медленно. Валидировано через beta-обратную связь в Wizard-of-Oz тесте.
+
+**AC:** [4 сценария: happy path, streaming fallback, LLM timeout, встреча <5 мин — пропускается]
+
+**Размер:** L (8 points) — ядро AI-пайплайна  
+**Зависимости:** S1 (должен быть включён), T2 (LLM API интеграция)
+
+---
+
+**Story S3: Проверять и редактировать AI-сводку inline**
+
+**As a** менеджер, просматривающий AI-сводку  
+**I want to** редактировать контент inline (добавлять, удалять, изменять) и помечать как подтверждённое  
+**So that** правки становятся авторитетной записью, и будущий AI учится моему стилю
+
+**Notes:**
+- Правки отслеживаются отдельно от оригинальной AI-версии (оба сохраняются для аудита + обучения)
+- Состояние подтверждения: «draft (AI)», «edited», «approved» (подтверждено менеджером)
+- Открытый вопрос: авто-подтверждение через 7 дней без правок? → по умолчанию: нет, статус остаётся «awaiting review»
+
+**AC:** [3 сценария: базовое редактирование, отмена редактирования, approved → только чтение]
+
+**Размер:** M (5 points) — интеграция rich-text редактора + конечный автомат  
+**Зависимости:** S2 (должна быть сводка)
+
+---
+
+**Story S4: Автоматически отслеживать Action Items из сводки**
+
+**As a** менеджер с подтверждённой AI-сводкой  
+**I want** извлечённые action items автоматически добавлялись в мою очередь follow-up с владельцем + датой (если LLM вывел)  
+**So that** я не теряю обязательства между встречами
+
+**Notes:**
+- Порог достоверности извлечения: >70% — элементы с низкой достоверностью показываются отдельно для проверки менеджером
+- Владелец по умолчанию: выводится из контекста (если «Sarah, please review» → Sarah), иначе менеджер
+- Дата по умолчанию: «к следующему 1:1» (7 дней), менеджер может переопределить
+
+**AC:** [4 сценария: стандартное извлечение, проверка низкой достоверности, вывод владельца, кастомная дата]
+
+**Размер:** M (5 points)  
+**Зависимости:** S2
+
+---
+
+**Story S5: Видеть напоминание об Action Items перед следующим 1:1**
+
+**As a** менеджер с открытыми action items из предыдущего 1:1 с подчинённым  
+**I want** эти элементы всплывали за 30 мин до предстоящего 1:1 через in-product уведомление + email  
+**So that** follow-through остаётся в фокусе и разговор развивается естественно
+
+**Notes:**
+- Окно 30 мин настраивается (15 / 30 / 60 / отключено) — пользовательская настройка
+- Элементы, отмеченные выполненными в UI напоминания, синхронизируются как с видом менеджера, так и подчинённого
+
+**AC:** [3 сценария: напоминание срабатывает, кастомное окно, напоминание отключено по настройке пользователя]
+
+**Размер:** S (3 points) — на правилах, использует существующий стек уведомлений  
+**Зависимости:** S4 (нужны существующие action items)
+
+---
+
+#### Роль: Admin / HR Business Partner
+
+**Story S6: Настроить общеорганизационную политику AI Summarization**
+
+**As an** admin (HR Business Partner или People Ops lead) для аккаунта TeamFlow на Team или Enterprise tier  
+**I want to** установить общеорганизационную политику AI (enabled / disabled / default-on для новых менеджеров)  
+**So that** я могу согласовать использование AI в TeamFlow с решениями компании по data governance
+
+**Notes:**
+- 3 состояния: «disabled org-wide» (AI недоступен для всех), «enabled — per-manager opt-in» (по умолчанию), «enabled — default on для новых менеджеров»
+- Изменение политики уведомляет всех менеджеров
+- Настройка политики записывается в audit log
+
+**AC:** [4 сценария: 3 перехода состояний + проверка audit log]
+
+**Размер:** S (3 points)  
+**Зависимости:** S1 (per-meeting переключатель должен существовать)
+
+---
+
+**Story S7: Экспорт Audit Log операций AI**
+
+**As an** admin, ответственный за compliance (SOC 2, GDPR)  
+**I want to** экспортировать audit log всех AI-операций (сводки сгенерированные, отредактированные, подтверждённые) за заданный период  
+**So that** я могу продемонстрировать соответствие требованиям во время аудита + расследовать инциденты
+
+**Notes:**
+- Запись лога: временна́я метка, актор (ID менеджера), действие (generate/edit/approve/delete), meeting ID, summary ID  
+- Форматы экспорта: CSV, JSON
+- Хранение: минимум 365 дней (юридический базовый уровень)
+
+**AC:** [3 сценария: экспорт happy path, фильтр по диапазону дат, пустой диапазон]
+
+**Размер:** S (3 points) — использует существующую инфраструктуру audit log  
+**Зависимости:** S1, S2, S3 (все AI-операции логируются)
+
+---
+
+#### Роль: Buyer (VP HR / CPO) — проходит через admin опыт
+
+**Story S8 (перенесена в Приложение PRD — scope dashboard Темы 2):**
+
+Stories видимости VP HR / aggregate dashboard — перенесены в отдельный PRD (aggregate-dashboard-v1), но связаны:
+- «Как VP HR, я хочу видеть adoption AI-суммаризации по командам, чтобы распределять обучение»  
+- «Как CPO, я хочу видеть velocity action items как leading indicator здоровья команды»
+
+*Эти stories живут в Aggregate Dashboard PRD — перекрёстная ссылка здесь.*
+
+---
+
+### Сводка по размерам stories
+
+| Story | Размер | Итого |
+|-------|:------:|------|
+| S1 Включить переключатель | S (2) | Маленькая, быстрая |
+| S2 Генерировать сводку | L (8) | ГЛАВНАЯ — ядро AI |
+| S3 Редактировать inline | M (5) | Rich-редактор |
+| S4 Извлечь action items | M (5) | Постобработка |
+| S5 Напоминание | S (3) | На правилах |
+| S6 Политика организации | S (3) | Admin UI |
+| S7 Экспорт аудита | S (3) | Функция экспорта |
+| **Итого (основной flow):** | | **29 points** |
+
+Распределение размеров (1 L + 2 M + 4 S) — здоровая форма MVP. Нет XL = нет неоцененных рисков.
+
+### Применённые техники разбивки
+
+- **По роли:** S1-S5 end-user (менеджер), S6-S7 admin, S8 отложена в отдельный PRD (buyer dashboard)
+- **По шагу workflow:** Подготовка (отложить — Q3), Во время встречи (S1-S2), Проверка (S3), Follow-through (S4-S5)
+- **Простое → Сложное:** S2 запускает «basic summary»; в будущем «summary + themes» отдельно
+- **Happy path → Граничные случаи:** S2 happy path — основное, обработка error-state через AC (не отдельные stories)
+
+### DAG зависимостей stories
+
+```
+T1 (инфраструктура feature flag)
+    └─→ S1 (переключатель)
+           └─→ S2 (генерировать сводку) ← зависит от T2 (LLM API)
+                  ├─→ S3 (редактировать inline)
+                  └─→ S4 (извлечь action items)
+                         └─→ S5 (напоминание)
+
+S6 (политика организации) ← зависит от S1 (per-meeting должен существовать сначала)
+S7 (экспорт аудита) ← зависит от S1, S2, S3 (нужны операции для логирования)
+```
+
+**Критический путь (для MVP):** T1 → S1 → S2 → S3 → S4 → S5 = ~26 points ≈ 6 недель при темпе 4 points/неделю.
+
+> **Урок user-story:** B2B **всегда** имеет несколько ролей. Разделение менеджера (end-user) от admin (HR Business Partner) от buyer (VP HR) — 3 отдельных набора AC, 3 отдельных формулировки «so that». Без разделения «As a user» = расплывчато. Stories S6-S7 ориентированы на admin — критичны для компаний с governance requirements. Наши начальные 14 stories включали только менеджера — Discovery B3 interview выявило потребность admin governance; S6-S7 были добавлены позже, что предотвратило жалобы после запуска «admin не имеет контроля».

package/domains/product/.agents/skills/user-story/agents/claude.json

@@ -0,0 +1,17 @@
+{
+  "name": "user-story",
+  "display_name": "User Story",
+  "description": "Написание user stories по INVEST — As a / I want / So that, разделение buyer/end-user",
+  "default_prompt": "Используй $user-story, когда задача относится к навыку \"User Story\".",
+  "triggers": [
+    "user-story",
+    "user story",
+    "пользовательская история",
+    "INVEST"
+  ],
+  "capabilities": [
+    "user-story"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/product/.agents/skills/user-story/agents/copilot.json

@@ -0,0 +1,17 @@
+{
+  "name": "user-story",
+  "display_name": "User Story",
+  "description": "Написание user stories по INVEST — As a / I want / So that, разделение buyer/end-user",
+  "default_prompt": "Используй $user-story, когда задача относится к навыку \"User Story\".",
+  "triggers": [
+    "user-story",
+    "user story",
+    "пользовательская история",
+    "INVEST"
+  ],
+  "capabilities": [
+    "user-story"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/product/.agents/skills/user-story/agents/gemini.json

@@ -0,0 +1,17 @@
+{
+  "name": "user-story",
+  "display_name": "User Story",
+  "description": "Написание user stories по INVEST — As a / I want / So that, разделение buyer/end-user",
+  "default_prompt": "Используй $user-story, когда задача относится к навыку \"User Story\".",
+  "triggers": [
+    "user-story",
+    "user story",
+    "пользовательская история",
+    "INVEST"
+  ],
+  "capabilities": [
+    "user-story"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/product/.agents/skills/user-story/agents/openai.yaml

@@ -0,0 +1,8 @@
+interface:
+  display_name: "User Story"
+  short_description: "Написание user stories по INVEST — As a / I want / So that, разделение buyer/end"
+  default_prompt: "Используй $user-story, когда задача относится к навыку \"User Story\"."
+dependencies:
+  tools: []
+policy:
+  allow_implicit_invocation: true

package/domains/product/.agents/skills/user-story/agents/qwen.json

@@ -0,0 +1,17 @@
+{
+  "name": "user-story",
+  "display_name": "User Story",
+  "description": "Написание user stories по INVEST — As a / I want / So that, разделение buyer/end-user",
+  "default_prompt": "Используй $user-story, когда задача относится к навыку \"User Story\".",
+  "triggers": [
+    "user-story",
+    "user story",
+    "пользовательская история",
+    "INVEST"
+  ],
+  "capabilities": [
+    "user-story"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/product/.agents/skills/user-story/agents/skill.yaml

@@ -0,0 +1,20 @@
+version: 1
+name: "user-story"
+display_name: "User Story"
+description: "Написание user stories по INVEST — As a / I want / So that, разделение buyer/end-user"
+default_prompt: "Используй $user-story, когда задача относится к навыку \"User Story\"."
+triggers:
+  - "user-story"
+  - "user story"
+  - "пользовательская история"
+  - "INVEST"
+capabilities:
+  - "user-story"
+tools: []
+invocation:
+  explicit: true
+  implicit: true
+localization:
+  default_locale: "ru"
+  available_locales:
+    - "ru"