problem-framing

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.

---

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

Пример 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 документов