make-research

Files (2)

• SKILL.md
• template.md · references/

SKILL.md (first lines)

# Make Research (Исследование и выбор подхода)

Создать `research.md` — документ принятия решения, который сравнивает технические альтернативы и рекомендует один конкретный подход с обоснованием, точками интеграции и рисками.

Документ отвечает на вопросы:

1. **Что выбираем и почему?** — однозначная рекомендация с обоснованием
2. **Что будет затронуто?** — укрупнённые точки интеграции (какие модули/сервисы затрагиваются)
3. **Что может пойти не так?** — ключевые риски и способы их снижения

## Роли

- **AI-агент** — проводит сравнение, формирует рекомендацию, записывает файл
- **Человек** — утверждает выбор или направляет на доработку до начала реализации

## Процесс

### Шаг 1 — Собрать контекст

Прочитать все доступные спецификации перед исследованием:
- `feature-spec.md` — что должна делать фича (требования со стороны пользователя)
- `functional-spec.md` — как она устроена (модули, потоки данных, контракты)
- `ui-spec.md` — как выглядит интерфейс (экраны, состояния)
- База знаний, если есть (`.docs/knowledge/README.md`)
- Записи об архитектурных решениях (`.docs/knowledge/adr/`)

Если спецификации отсутствуют — попросить пользователя описать задачу перед продолжением.

### Шаг 2 — Определить пространство решений

Выяснить, что именно нужно выбрать: библиотека, архитектурный паттерн, протокол, API-стратегия и т.д. Один документ research охватывает один кластер решений. Если нужно принять несколько несвязанных решений — явно перечислить их, чтобы пользователь расставил приоритеты.

### Шаг 3 — Исследовать альтернативы (если есть в спецификациях)

Для каждой альтернативы:
- Одним предложением описать, что это такое
- Перечислить **плюсы** применительно к ограничениям проекта
- Перечислить **минусы** применительно к ограничениям проекта
- Для сторонних библиотек: указать зрелость, лицензию, активность сообщества и дату последнего релиза
- Использовать context7 MCP для получения актуальной документации по оцениваемым библиотекам и фреймворкам

Ограничение: 2–4 альтернативы на одно решение. Не включать заведомо неподходящие варианты.

### Шаг 4 — Сформировать рекомендацию

Назвать выбранный вариант однозначно. Объяснить, почему он предпочтительнее каждого из отклонённых — одним-двумя предложениями на каждый. Рекомендация должна быть actionable: читатель должен чётко понимать, что установить, принять или настроить.

### Шаг 5 — Определить точки интеграции

Перечислить, какие существующие модули, сервисы или подсистемы придётся изменить при внедрении выбранного подхода. Использовать те же названия модулей, что и в `functional-spec.md`, если этот документ существует. Это укрупнённая карта, а не список задач.

### Шаг 6 — Определить ключевые риски

Перечислить 3–6 рисков. Для каждого:
- Одно предложение с описанием риска
- Вероятность: Low / Medium / High
- Митигация: одно конкретное действие, снижающее риск

### Шаг 7 — Представить на утверждение

До записи файла представить пользователю краткое резюме:
- Выбранный вариант (одна строка)
- Две главные причины выбора
- Наибольший риск

Спросить: «Подтверждаете выбор? Или есть правки перед записью файла?»

Записывать файл только после подтверждения пользователя.

### Шаг 8 — Записать файл

Записать `research.md` в корень проекта (или по пути, указанному пользователем). Использовать шаблон из `references/template.md`.

После записи вывести путь к файлу и одно предложение с описанием принятого решения.

## Язык

Общаться с пользователем на русском. Документ писать на русском. Технические термины, идентификаторы, названия библиотек и код внутри блоков кода — в оригинальном виде (английский).

## Правила оформления

- Везде в прозе — настоящее время
- Таблицы сравнения должны иметь одинаковые колонки для всех альтернатив
- Раздел рекомендации начинается с названия выбранного варианта жирным шрифтом
- Объём документа — не более 300 строк; если пространство решений шире — разбить на отдельные research-документы по кластерам и дать ссылки из общего
- Никакого кода реализации — только названия, ключи конфигурации и примеры команд

## Ограничения

- Не коммитить изменения
- Не выводить commit message
- Не начинать реализацию — результат только документ принятия решения
- Не редактировать `feature-spec.md`, `functional-spec.md`, `ui-spec.md`

## Дополнительные ресурсы

- **`references/template.md`** — пустой шаблон документа для заполнения

From YamiHilik/SDLCRoom, Apache-2.0.

More from YamiHilik/SDLCRoom