AgentSkillsCN

project-brief

在撰写项目简报、明确项目创意或进一步厘清项目范围时加以应用——对问题、用户、解决方案以及 MVP 的边界进行系统性研究。

SKILL.md
--- frontmatter
name: project-brief
description: Используй при создании Project Brief, определении идеи проекта или уточнении scope. Структурированное исследование проблемы, пользователя, решения и границ MVP.

Project Brief: мозговой штурм

Цель

Превратить размытую идею проекта в сфокусированный Project Brief на 2-3 страницы через структурированный диалог.

Процесс

Фаза 1: Исследование проблемы

Задавай вопросы ПО ОДНОМУ. Жди ответа перед следующим вопросом.

  1. •"Опиши ситуацию: кто сейчас сталкивается с этой проблемой и как справляется без твоего решения?"
  2. •"Что в этом плохого? Почему текущий способ не устраивает?"
  3. •"Как часто это происходит? Насколько это больно по шкале от 1 до 10?"

Если пользователь не может сформулировать проблему, спроси: "Забудь про решение. Расскажи историю конкретного человека, у которого что-то не получается."

Фаза 2: Уточнение пользователя

  1. •"Кто конкретно твой пользователь? Не 'все фермеры', а какой именно фермер?"
  2. •"В каком контексте он столкнётся с твоим продуктом? Где, когда, с какого устройства?"
  3. •"Что этот человек уже пробовал? Почему не сработало?"

Фаза 3: Определение решения

  1. •"Теперь расскажи своё решение. Что система ДЕЛАЕТ (не как устроена внутри)?"
  2. •"Пользователь открыл приложение. Что он делает первым? Что вторым? Что видит в результате?"
  3. •"Чем это лучше того, как он справляется сейчас?"

Фаза 4: Границы MVP

  1. •"У тебя 2 недели на первую версию. Какие 2-3 функции обязательны, чтобы решить главную проблему?"
  2. •"Что хочется добавить, но можно отложить на потом?"
  3. •"Есть ли внешние зависимости или интеграции, без которых MVP не работает?"

Фаза 5: Критерии успеха

  1. •"Представь: продукт готов. Как ты покажешь, что он работает? Опиши один конкретный сценарий от начала до конца."
  2. •"Как поймёшь, что пользователь доволен? Что он скажет или сделает?"

Фаза 6: Формирование документа

Когда все ответы собраны — представь Project Brief блоками по 200-300 слов. После каждого блока спрашивай: "Эта часть выглядит верно?" Будь готов вернуться и уточнить, если что-то не сходится.

Результат

После валидации всех блоков создай файл docs/PROJECT_BRIEF.md:

markdown
# Project Brief: [Название]

## Проблема

[Описание текущей ситуации: кто, что делает, почему это плохо. 
Конкретная история или пример. 4-5 предложений]

## Пользователь

[Кто именно, в каком контексте, какой опыт. 
Что уже пробовал, почему не подошло. 4-5 предложений]

## Решение

[Что продукт делает для пользователя. Основной сценарий использования.
Ключевое отличие от существующих альтернатив. 5-6 предложений, без технических деталей]

## Границы MVP

**Входит:**
- [функция 1 — краткое описание]
- [функция 2 — краткое описание]
- [функция 3 — краткое описание]

**Не входит (на потом):**
- [отложенное 1]
- [отложенное 2]

**Зависимости и интеграции:**
- [если есть внешние API, сервисы, данные]

## Критерии успеха

[Конкретный сценарий: пользователь X делает Y, получает Z.
Как понять, что цель достигнута. 3-4 предложения]

Ключевые принципы

  • •Один вопрос за раз — не перегружай собеседника множеством вопросов
  • •Варианты ответов предпочтительнее — предлагай 2-3 варианта, на них проще отвечать
  • •Конкретика вместо абстракций — требуй примеры, имена, цифры
  • •Челлендж размытых ответов — "все пользователи" → "кто конкретно?"
  • •Сначала проблема, потом решение — не давай перескакивать к фичам, пока проблема не ясна
  • •YAGNI без компромиссов — безжалостно убирай лишнее из MVP
  • •Инкрементальная валидация — представляй документ блоками, проверяй каждый
  • •Будь гибким — возвращайся и уточняй ранние решения, если что-то не сходится