Перейти к основному содержанию
Пользовательские команды позволяют создавать повторно используемые рабочие процессы, которые можно запускать с помощью простого префикса / в поле ввода чата. Эти команды помогают стандартизировать процессы в твоей команде и ускоряют выполнение типичных задач.
Пример ввода команд
Команды сейчас в бета-версии. По мере улучшения функциональности их возможности и синтаксис могут меняться.

​
Как работают команды

Команды — это обычные Markdown‑файлы, которые можно хранить в двух местах:
  1. Команды проекта: в каталоге .cursor/commands твоего проекта
  2. Глобальные команды: в каталоге ~/.cursor/commands в твоём домашнем каталоге
Когда ты вводишь / в поле ввода чата, Cursor автоматически находит и показывает доступные команды из обоих каталогов — они сразу становятся доступны в твоём рабочем процессе.

​
Создание команд

  1. Создай директорию .cursor/commands в корне проекта
  2. Добавь .md-файлы с понятными названиями (например, review-code.md, write-tests.md)
  3. Напиши простой текст в Markdown, описывающий, что должна делать команда
  4. Команды автоматически появятся в чате, когда ты введёшь /
Вот пример того, как может выглядеть структура директории с командами: 
.cursor/
└── commands/
    ├── обработать-комментарии-github-pr.md
    ├── чеклист-код-ревью.md
    ├── создать-pr.md
    ├── быстрый-обзор-существующих-диффов.md
    ├── онбординг-нового-разработчика.md
    ├── запустить-все-тесты-и-исправить.md
    ├── аудит-безопасности.md
    └── настроить-новую-фичу.md

​
Примеры

Попробуй эти команды в своих проектах, чтобы почувствовать, как они работают. 
# Чек-лист код-ревью

## Обзор
Подробный чек-лист для проведения тщательных код-ревью, чтобы обеспечить качество, безопасность и поддерживаемость.

## Категории проверки

### Функциональность
- [ ] Код делает то, что должен
- [ ] Обработаны крайние случаи
- [ ] Корректная обработка ошибок
- [ ] Нет очевидных багов или логических ошибок

### Качество кода
- [ ] Код читаемый и хорошо структурирован
- [ ] Функции небольшие и узконаправленные
- [ ] Имена переменных информативные
- [ ] Нет дублирования кода
- [ ] Соблюдаются соглашения проекта

### Безопасность
- [ ] Нет очевидных уязвимостей безопасности
- [ ] Есть проверка/валидация входных данных
- [ ] Конфиденциальные данные обрабатываются корректно
- [ ] Нет захардкоженных секретов

# Аудит безопасности

## Обзор
Всесторонняя проверка безопасности для выявления и исправления уязвимостей в кодовой базе.

## Шаги
1. **Аудит зависимостей**
   - Проверить известные уязвимости
   - Обновить устаревшие пакеты
   - Проверить сторонние зависимости

2. **Ревью безопасности кода**
   - Проверить распространённые уязвимости
   - Проверить аутентификацию/авторизацию
   - Аудит практик обработки данных

3. **Безопасность инфраструктуры**
   - Проверить переменные окружения
   - Проверить управление доступом
   - Аудит сетевой безопасности

## Контрольный список по безопасности
- [ ] Зависимости обновлены и безопасны
- [ ] Нет хардкодно прописанных секретов
- [ ] Реализована проверка входных данных
- [ ] Аутентификация защищена
- [ ] Авторизация корректно настроена

# Настройка новой фичи

## Обзор
Системно подготовь новую фичу — от первичного планирования до структуры реализации.

## Шаги
1. **Определи требования**
   - Проясни границы и цели фичи
   - Определи пользовательские истории и критерии приемки
   - Спланируй технический подход

2. **Создай ветку для фичи**
   - Ответвись от main/develop
   - Настрой локальное окружение разработки
   - Настрой любые новые зависимости

3. **Спланируй архитектуру**
   - Спроектируй модели данных и API
   - Спланируй UI‑компоненты и пользовательские потоки
   - Продумай стратегию тестирования

## Чек-лист настройки фичи
- [ ] Требования задокументированы
- [ ] Пользовательские истории написаны
- [ ] Технический подход спланирован
- [ ] Ветка для фичи создана
- [ ] Окружение разработки готово

# Создать PR

## Обзор
Создай хорошо структурированный pull request с понятным описанием, метками и ревьюерами.

## Шаги
1. **Подготовить ветку**
   - Убедись, что все изменения закоммичены
   - Запушь ветку в удалённый репозиторий
   - Проверь, что ветка актуальна относительно main

2. **Написать описание PR**
   - Чётко опиши изменения
   - Добавь контекст и мотивацию
   - Перечисли любые breaking changes
   - Добавь скриншоты, если есть изменения в UI

3. **Оформить PR**
   - Создай PR с информативным заголовком
   - Добавь соответствующие метки
   - Назначь ревьюеров
   - Привяжи связанные issues

## Шаблон PR
- [ ] Фича A
- [ ] Фикс бага B
- [ ] Unit-тесты проходят
- [ ] Ручное тестирование завершено

# Запусти все тесты и исправь ошибки

## Обзор
Выполни полный набор тестов и последовательно исправляй любые ошибки, поддерживая качество и работоспособность кода.

## Шаги
1. **Запусти тестовый набор**
   - Выполни все тесты в проекте
   - Сохрани вывод и найди ошибки
   - Проверь и модульные, и интеграционные тесты

2. **Проанализируй ошибки**
   - Разбей по типам: нестабильные (flaky), сломанные, новые
   - Расставь приоритеты исправлений по влиянию
   - Проверь, связаны ли ошибки с недавними изменениями

3. **Исправляй проблемы системно**
   - Начни с самых критичных ошибок
   - Исправляй по одной задаче за раз
   - Перезапускай тесты после каждого исправления

# Онбординг нового разработчика

## Обзор
Подробный процесс онбординга, чтобы новый разработчик быстро включился в работу.

## Шаги
1. **Настройка окружения**
   - Установить необходимые инструменты
   - Настроить среду разработки
   - Настроить IDE и расширения
   - Настроить Git и SSH‑ключи

2. **Знакомство с проектом**
   - Изучить структуру проекта
   - Разобраться с архитектурой
   - Прочитать ключевую документацию
   - Настроить локальную базу данных

## Чек‑лист онбординга
- [ ] Среда разработки готова
- [ ] Все тесты проходят
- [ ] Приложение запускается локально
- [ ] База данных настроена и работает
- [ ] Отправлен первый PR
⌘I