# User vs project rules

← [Раздел](README.md) · [Главная](../README.md)

## Цель

Выбрать **правильное место** для правила: личные предпочтения vs политики репозитория, и понять, как они сочетаются.

## Предварительно

- [Что такое rules](chto-takoe-rules.md)

## Время

**40–55 минут**

---

## Два уровня

| Уровень | Путь | Кто видит | Пример |
|---------|------|-----------|--------|
| **User (global)** | `~/.cursor/rules/` | Вы во всех проектах | «Пиши комментарии на русском» |
| **Project** | `.cursor/rules/` в репо | Вся команда через git | «Conventional commits» |

Project rules **версионируются** — это часть кодовой базы, как `.editorconfig`.

---

## Что куда класть

### User rules — хорошо для:

- языка общения с агентом;
- личных shortcut-предпочтений (длина ответа);
- модели по умолчанию (если поддерживается rule-ом);
- экспериментов до переноса в project.

### Project rules — обязательно для:

- стиля кода команды;
- security и compliance;
- git/PR workflow;
- архитектурных границ (слои, запрещённые импорты);
- стека (React patterns, Django ORM).

---

## Конфликты и приоритет

Если user rule говорит «всегда используй Vue», а project — «этот репо на React» — победит **контекст задачи + project**, но возможен шум.

**Рекомендация:** в user rules не диктуйте стек; в project — не дублируйте личное.

При противоречии явно укажите в project rule:

```markdown
This repository uses React 19. Ignore conflicting global preferences.
```

---

## ECC: user vs project install

Skill `configure-ecc` может ставить компоненты:

- в home directory (`~/.cursor/`, `~/.claude/`) — личный набор;
- в project `.cursor/` — shared с командой.

Для open-source pet-project достаточно project install. Для «карманного» набора навыков на все репо — user.

---

## Командная работа

1. **Code review** на `.cursor/rules/` как на код.
2. README проекта — ссылка «как мы используем AI».
3. Не коммитьте **личные** эксперименты в main.
4. Согласуйте `alwaysApply` rules — они влияют на всех.

---

## .gitignore для rules

Обычно project rules **коммитятся**. Исключение — локальные override:

```
# опционально в .gitignore (осторожно)
.cursor/rules/local-*.mdc
```

Документируйте, если используете local overrides.

---

## Миграция: промпт → rule

| Если в промпте повторяется… | Действие |
|-----------------------------|----------|
| «Не коммить без запроса» | project rule + git workflow |
| «Immutable updates» | project coding-style |
| «Ответ на русском» | user или project rule |
| «Запусти tests перед finish» | project testing rule |

---

## Практика

1. Создайте **user** rule: один личный preference.
2. Создайте **project** rule: одна политика репо (например, секреты).
3. Откройте Agent **без** упоминания правил — проверьте соблюдение.

---

## Связь с skills

Rule = **что всегда/часто true**. Skill = **как выполнить задачу типа X**. Не дублируйте весь TDD workflow в rule — используйте skill `tdd-workflow`.

---

## Самопроверка

1. Где хранятся project rules?
2. Почему стиль коммитов — project, а не user?
3. Что делать при конфликте user и project?
4. Коммитятся ли project rules в git?

## Дальше

→ [Примеры rules](primery-rules.md)