---
name: problem-framing
description: Мета-фреймворк структурированного решения любых задач. Определяет область знаний, находит существующие фреймворки через web research, валидирует подходы, выявляет типичные ошибки и constraints. ОБЯЗАТЕЛЬНО использует sequential thinking и web research на каждом запуске. Активировать только при явном запросе пользователя на "problem-framing", "фрейминг задачи" или "структурированный анализ задачи".
---

# Problem Framing

Мета-фреймворк для структурированного подхода к решению задач. Основан на принципе Эйнштейна: понимание проблемы — это 50% её решения.

## Обязательные инструменты

При каждом запуске скилла ОБЯЗАТЕЛЬНО использовать:
- **Sequential thinking** — для глубокого анализа на каждом шаге
- **Web research** (perplexity + web_search) — для поиска существующих решений и типичных ошибок

## Процесс (7 шагов)

1. Problem Definition — переформулировать задачу, определить критерии успеха
2. Domain Mapping — определить primary и supporting области знаний
3. Existing Solutions Research — найти фреймворки через web research
4. Framework Validation — проверить найденные подходы по 4 критериям
5. Failure Mode Analysis — инверсия, типичные ошибки, constraints
6. Solution Synthesis — объединить подход с защитой от ошибок
7. Automation Decision — решить об автоматизации

---

## Шаг 1: Problem Definition

**1.1. Извлечь из input всё ценное:**
- Основная задача (явная или между строк)
- Контекст и предыстория
- Уже рассмотренные варианты решений
- Сомнения и страхи
- Известные ограничения
- Неявные критерии успеха

**1.2. Если несколько задач** — выделить и сформулировать главную, остальные отложить.

**1.3. Задать clarifying questions (обязательно):**
- Что осталось неясным после извлечения?
- Какие предположения нужно проверить?
- Какой контекст не хватает?

**1.4. Сформулировать финальную задачу:**
- Что именно нужно решить? (конкретно)
- Какой результат = успех? (измеримые критерии)

Использовать sequential thinking для глубокого понимания.

## Шаг 2: Domain Mapping

Определить области знаний:

**Primary domain** — основная область, к которой относится задача (разработка, наука, маркетинг, творчество, образование, инженерия, личное развитие, и т.д.)

**Supporting domains** — смежные области, БЕЗ которых решение будет неполным. Для каждой указать конкретный аспект:
- Пример бизнес: для задачи "определить ЦА" primary = маркетинг, supporting = психология (только модели мотивации)
- Пример технический: для задачи "спроектировать API" primary = software architecture, supporting = security (только аутентификация)
- Пример творческий: для задачи "написать роман" primary = литературное мастерство, supporting = психология (только мотивация персонажей)

Не добавлять supporting domains "на всякий случай" — только если без них решение ошибочно.

## Шаг 3: Existing Solutions Research

ОБЯЗАТЕЛЬНО провести глубокий web research. Принцип: большинство задач уже решены тысячу раз, об этом написаны книги и статьи — нужно это найти.

**Что искать:**
- Фреймворки и методологии
- Best practices и стандарты
- Академические исследования (если применимо)
- Case studies и примеры применения
- Критика и ограничения подходов

**Глубина исследования:**
- Не останавливаться на первых результатах
- Искать разные точки зрения и подходы
- Понять историю и контекст возникновения фреймворков
- Найти минимум 3-5 разных подходов для сравнения

**Запросы:** "[domain] frameworks", "[task type] best practices", "[task type] methodology", "[domain] common approaches", "[framework name] criticism"

## Шаг 4: Framework Validation

Проверить каждый найденный фреймворк по 4 критериям:

| Критерий | Вопрос |
|----------|--------|
| Source credibility | Откуда фреймворк? Академия, проверенная практика, авторитетные эксперты — или гуру-булшит? |
| Context match | Для какого контекста создан? Совпадает ли с контекстом задачи по масштабу, ресурсам, уровню неопределённости? |
| Complexity fit | Соответствует ли сложность фреймворка сложности задачи? Не избыточен ли? Не слишком ли примитивен? |
| Track record | Есть ли документированные примеры успешного применения в похожем контексте? |

**Фреймворк проходит валидацию если соответствует 3+ критериям из 4.**

При равенстве кандидатов — выбирать по context match как tiebreaker.

## Шаг 5: Failure Mode Analysis

Применить инверсию — спросить: "Что нужно сделать, чтобы ТОЧНО провалиться?"

Через web research найти:
- Типичные ошибки при решении задач этого типа
- Constraints и ограничения домена
- Антипаттерны

Запросы: "[task type] common mistakes", "[domain] pitfalls", "[framework name] criticism"

## Шаг 6: Solution Synthesis

Объединить результаты:
- Выбранный фреймворк (прошедший валидацию)
- Адаптация под конкретный контекст задачи
- Встроенная защита от типичных ошибок из шага 5
- Конкретные следующие шаги (actionable)

## Шаг 7: Automation Decision

Оценить повторяемость задачи по формуле:

```
автоматизировать если: время_на_автоматизацию < (время_ручного × количество_повторений × коэффициент_вариативности)
```

Где коэффициент_вариативности:
- 1.0 — задача идентична каждый раз
- 0.7 — небольшие вариации
- 0.5 — существенные вариации
- 0.3 — каждый раз сильно разная

**Если задача повторяемая** → добавить документ 06-automation.md с draft skill structure

**Если задача уникальная** → это БОЛЕЕ важная задача:
- Определяет долгосрочную перспективу
- Требует максимального когнитивного ресурса
- Все документы output должны быть максимально глубокими и развёрнутыми
- Не экономить на анализе — это фундаментальное решение

---

## Output

После завершения всех шагов создать набор документов. Каждый документ — полноценный аналитический материал, НЕ checklist.

**Обязательные документы (5 штук):**
1. `01-problem-definition.md` — Формулировка задачи
2. `02-domain-analysis.md` — Анализ области знаний
3. `03-solutions-research.md` — Исследование решений
4. `04-failure-analysis.md` — Анализ рисков
5. `05-action-plan.md` — План действий

**Опциональный документ (для повторяемых задач):**
6. `06-automation.md` — Draft skill structure

Структура и содержание каждого документа описаны в [references/output-template.md](references/output-template.md).

---

## Примеры использования

### Пример 1: Бизнес-задача
**Запрос:** "problem-framing: как определить ценообразование для SaaS"
**Процесс:** Domain = pricing strategy → Research: Value-based, Van Westendorp, Conjoint → Validation: Value-based проходит → Failure: cost-plus ошибка для SaaS → Output: 5 документов

### Пример 2: Техническая задача
**Запрос:** "problem-framing: как спроектировать архитектуру для высоконагруженного API"
**Процесс:** Domain = distributed systems → Research: microservices, event-driven, CQRS → Validation: event-driven подходит по контексту → Failure: premature optimization, single point of failure → Output: 5 документов

### Пример 3: Творческая задача
**Запрос:** "problem-framing: как написать первый роман"
**Процесс:** Domain = литературное мастерство → Research: Snowflake method, Save the Cat, три акта → Validation: Snowflake для новичков → Failure: начать без плана, редактировать во время письма → Output: 5 документов

### Пример 4: Научная задача
**Запрос:** "problem-framing: как провести исследование пользовательского поведения"
**Процесс:** Domain = UX research → Research: ethnography, surveys, A/B testing, interviews → Validation: mixed methods → Failure: leading questions, confirmation bias → Output: 5 документов