research

name	research
description	Deep codebase research and exploration. Use when user asks to "проведи research", "изучи кодовую базу", "исследуй проект", "conduct research", "explore codebase", "understand architecture", or when task requires thorough investigation of code structure, patterns, dependencies, or understanding how something works.

Research Skill — глубокое исследование кодовой базы

Методология систематического исследования кода для понимания архитектуры, паттернов и зависимостей.

Когда использовать

• Нужно понять как устроен незнакомый проект
• Изучить архитектуру или технический стек
• Найти где и как реализована функция
• Понять flow данных через систему
• Исследовать паттерны и best practices в кодовой базе

Методология Research

Фаза 1: Обзор (Overview)

Цель: Получить общее представление о проекте

1. Структура проекта

   # Найти основные конфигурационные файлы
   ls -la | grep -E "package.json|requirements.txt|Cargo.toml|go.mod|pom.xml"
   
   # Посмотреть структуру папок
   tree -L 2 -d
   

2. Технологический стек

   • Прочитать package.json, requirements.txt или аналог
   • Определить фреймворки и библиотеки
   • Версии языков и runtime

3. Entry points

   • Где точка входа? (main.py, index.js, main.go)
   • Есть ли README с инструкциями?
   • Какие команды для запуска?

Вывод фазы 1:

## Обзор проекта

**Технологии:**
- [Язык]: [версия]
- [Фреймворк]: [версия]
- [Основные зависимости]

**Структура:**
- `src/` — основной код
- `tests/` — тесты
- ...

**Entry points:**
- Запуск: `npm run dev`
- Тесты: `npm test`

Фаза 2: Архитектура (Architecture)

Цель: Понять как организован код

1. Паттерны организации

   • MVC, MVP, MVVM?
   • Feature-based или layer-based?
   • Monorepo или single app?

2. Ключевые модули

   • Найти основные папки/модули
   • Определить их назначение
   • Понять связи между ними

3. Граф зависимостей

   • Какие модули от чего зависят
   • Есть ли циклические зависимости
   • Core vs peripheral модули

Инструменты:

# Поиск импортов/зависимостей
rg "^import.*from" --type js
rg "^from.*import" --type py

# Найти все файлы с определёнными паттернами
fd -e js -e ts | head -20

Вывод фазы 2:

## Архитектура

**Паттерн:** [MVC / Feature-based / ...]

**Основные модули:**
1. **auth/** — аутентификация
   - Зависит от: database, utils
   - Используется в: api, web

2. **database/** — работа с БД
   - Зависит от: config
   - Используется в: везде

Фаза 3: Глубокое погружение (Deep Dive)

Цель: Детально понять интересующую область

1. Выбрать фокус

   • Конкретная функция/feature
   • Проблемная область
   • То что нужно модифицировать

2. Trace execution flow

   • От entry point до результата
   • Какие функции вызываются
   • Какие данные передаются

3. Найти примеры

   • Найти тесты для этой области
   • Найти похожие реализации
   • Документация или комментарии

Техники:

# Найти все вызовы функции
rg "functionName\(" --type js

# Найти определение
rg "function functionName|const functionName|class functionName"

# Найти тесты
rg "describe.*functionName|test.*functionName|it.*functionName"

Вывод фазы 3:

## Детали: [Feature/Function]

**Как работает:**
1. Пользователь вызывает X
2. Система делает Y
3. Результат Z

**Ключевые файлы:**
- `src/auth/login.ts:42` — основная логика
- `src/auth/utils.ts:15` — вспомогательные функции
- `tests/auth/login.test.ts:10` — тесты

**Зависимости:**
- bcrypt для хеширования
- jwt для токенов

Фаза 4: Паттерны и практики (Patterns)

Цель: Выявить паттерны для следования

1. Code style

   • Naming conventions
   • Структура файлов
   • Комментарии и документация

2. Паттерны проектирования

   • Singleton, Factory, Repository?
   • Middleware, Decorators?
   • Custom patterns?

3. Best practices

   • Обработка ошибок
   • Логирование
   • Тестирование

Вывод фазы 4:

## Паттерны в проекте

**Naming:**
- Функции: camelCase
- Классы: PascalCase
- Константы: UPPER_SNAKE_CASE

**Архитектурные паттерны:**
- Repository pattern для доступа к данным
- Service layer для бизнес-логики

**Error handling:**
- try/catch с custom error classes
- Centralized error handler

Итоговый отчёт Research

После прохождения всех фаз, создай структурированный отчёт:

# Research: [Название проекта/области]

## Executive Summary
[Краткое резюме — 3-5 предложений о проекте]

## Технологический стек
- [Список технологий]

## Архитектура
[Описание архитектуры + диаграмма если нужно]

## Ключевые модули
1. **[Модуль]** — [назначение]
2. ...

## [Исследуемая область] — детали
[Глубокое погружение в нужную область]

## Паттерны и практики
[Выявленные паттерны]

## Рекомендации
- [Что учесть при работе с этим кодом]
- [На что обратить внимание]
- [Потенциальные проблемы]

## Полезные ссылки
- [Файлы для начала работы]
- [Ключевая документация]

Инструменты Research

Поиск файлов (Glob)

# Найти все файлы определённого типа
**/*.ts
**/models/*.py

# Исключить node_modules, dist
**/*.js !node_modules/** !dist/**

Поиск по содержимому (Grep)

# Найти паттерн в коде
rg "class.*Controller" --type ts

# С контекстом (5 строк до и после)
rg "function login" -C 5

# Найти TODO/FIXME
rg "TODO|FIXME|HACK" -i

Чтение файлов (Read)

• Читай ключевые файлы полностью
• Обращай внимание на imports и exports
• Ищи комментарии с объяснениями

Лучшие практики Research

DO ✅

• Начинай с обзора, не погружайся сразу в детали
• Документируй находки по ходу
• Ищи паттерны и следуй им
• Читай тесты — они объясняют как код должен работать
• Используй Context7 для актуальной документации библиотек

DON'T ❌

• Не делай предположения без проверки
• Не пропускай конфигурационные файлы
• Не игнорируй тесты
• Не пытайся понять всё сразу — двигайся слоями
• Не забывай про зависимости и их версии

Шаблоны запросов

Общий research:

Проведи research проекта и создай обзор архитектуры

Фокусированный research:

Исследуй как работает аутентификация в этом проекте

Поиск паттернов:

Изучи как обрабатываются ошибки в этой кодовой базе

Понимание flow:

Trace как данные проходят от API запроса до БД

Интеграция с другими skills

• После research → используй code-review для оценки качества
• После research → используй refactoring для улучшений
• Во время research → используй debugging если нашёл баги
• Результаты research → сохрани в документацию через /doc