Skip to content

Instantly share code, notes, and snippets.

@stgmt
Created January 16, 2026 03:37
Show Gist options
  • Select an option

  • Save stgmt/0ead32b063ea5d8d030e791031e2177a to your computer and use it in GitHub Desktop.

Select an option

Save stgmt/0ead32b063ea5d8d030e791031e2177a to your computer and use it in GitHub Desktop.
description allowed-tools argument-hint
Анализ сессии и предложение Claude rules на основе выявленных паттернов
Read, Write, Glob, Grep
[all|global|project|verbose]

Suggest Claude Rules

Mission

Проведи ретроспективный анализ текущей сессии и предложи Claude rules для сохранения ценного контекста и паттернов.


Phase 0: Изучение структуры rules

Сначала изучи существующие rules в проекте:

Glob(".claude/rules/**/*.md") → список файлов

Извлеки:

  • Категории (папки): core/, development/, testing/...
  • Количество rules в каждой
  • Примеры naming convention

Выведи:

## Структура rules в проекте

Найдено N rules в K категориях:
- category1/ (X файлов)
- category2/ (Y файлов)
...

(или: Папка .claude/rules/ не найдена — будет создана)

Phase 1: Session Analysis

Проанализируй каждый turn разговора от начала до этой команды:

Что искать:

  • 🟢 Успехи: Какие паттерны привели к правильному решению?
  • 🔴 Ошибки и исправления: Где подход провалился? Что исправил пользователь?
  • 📁 Файлы: Какие файлы обсуждались? Какие паттерны в них?
  • 🔧 Решения: Какие архитектурные решения были приняты?
  • 📚 Domain knowledge: Какие специфические знания о проекте раскрыты?

Phase 2: Quality Filter (AI Pre-Check)

Для каждого потенциального правила выполни проверку:

Check Критерий Вопрос
A1 Universal Применимо к разным проектам/задачам?
A2 Abstracted Общий принцип, не привязан к конкретному багу?
A3 High-Impact Предотвращает реальные проблемы?

Формат проверки:

Кандидат: "fail-fast-principle"
├── A1 Universal:    ✅ применимо к любому backend
├── A2 Abstracted:   ✅ общий принцип
├── A3 High-Impact:  ✅ предотвращает silent failures
└── RESULT: ✅ PASS

Кандидат: "fix-specific-jwt-bug"
├── A1 Universal:    ❌ специфично для этой задачи
├── A2 Abstracted:   ❌ привязано к конкретному багу
├── A3 High-Impact:  ⚠️ средний
└── RESULT: ❌ REJECT

Выводи ТОЛЬКО правила с PASS.


Phase 3: Index Output

Выведи детальный индекс с обоснованием:

## Найдено N правил

### 🌍 Global (M) — для ~/.claude/rules/

**1. rule-name-kebab-case**
- 📝 Суть: Краткое описание принципа
- 🎯 Зачем: Какую проблему предотвращает
- 📍 Откуда: [момент сессии где проявилось]

### 📁 Project (K) — для .claude/rules/<категория>/

**2. another-rule-name**
- 📝 Суть: ...
- 🎯 Зачем: ...
- 📍 Рекомендуемая категория: [на основе анализа существующих]

---
Продолжить? `y` — все, `1` — Global, `2` — Project, `n` — отмена

Ожидай ответ пользователя перед Phase 4.


Phase 4: Rule Proposals

Для каждого выбранного правила выведи полное содержимое:

### N. rule-name-kebab-case

**Тип**: 🌍 Global | 📁 Project
**Pre-Check**: ✅ A1 ✅ A2 ✅ A3
**Путь**: `.claude/rules/<категория>/rule-name.md`

**Причина:**
- Почему важно?
- Какую проблему предотвращает?

**Содержимое файла:**

# Rule Title

[Описание принципа]

## Правильно

```language
// пример правильного кода

Неправильно

// пример неправильного кода

Чеклист

  • Пункт 1
  • Пункт 2


---

## Phase 5: User Selection

После вывода предложений:

Выбор

Ответь в формате: 1✅, 2❌, 3✏️ сделай короче

  • ✅ — создать как есть
  • ❌ — отклонить
  • ✏️ — модифицировать (укажи что изменить)

Или: all для всех, 0 для отмены.


---

## Phase 6: File Creation

**При создании:**

1. Проверь что файл не существует: `Glob(".claude/rules/**/<name>.md")`
2. Создай файл: `.claude/rules/<категория>/<name>.md`
3. Подтверди: `✅ Создано: .claude/rules/<категория>/<name>.md`

**Если категория новая:**
- Создай папку
- Сообщи: `📁 Создана новая категория: <name>/`

**Если файл существует:**
- Спроси: `⚠️ Файл существует. Перезаписать? (y/n/merge)`

---

## Критические правила

1. **НЕ создавай автоматически** — только после явного выбора пользователя
2. **НЕ предлагай тривиальные** — Quality Filter обязателен
3. **< 500 строк** — большие разбивай на несколько
4. **Self-contained** — понятно без контекста сессии
5. **Actionable** — конкретные инструкции, не советы
6. **БЕЗ frontmatter** — Claude Code rules это чистый Markdown

---

## Категоризация

| Тип | Когда использовать | Путь |
|-----|-------------------|------|
| 🌍 **Global** | Принцип для ЛЮБОГО проекта | `~/.claude/rules/` |
| 📁 **Project** | Специфика текущего проекта/стека | `.claude/rules/<категория>/` |

**Рекомендации по категориям:**
- Изучи существующие категории в проекте
- Предложи наиболее подходящую
- Или предложи новую с обоснованием

---

## Аргументы команды

- Без аргументов: полный workflow
- `$ARGUMENTS` = `global`: только 🌍 Global правила
- `$ARGUMENTS` = `project`: только 📁 Project правила
- `$ARGUMENTS` = `verbose`: показать также REJECT кандидатов

---

## Примеры качественных правил

| Тип | Примеры |
|-----|---------|
| **Архитектура** | Модули, слои, naming conventions |
| **Workflow** | TDD, code review, git workflow |
| **Интеграции** | API retry, error handling, env config |
| **Debug** | Формат логов, трейсинг |
| **Domain** | Бизнес-логика, термины, связи |

---

## Начни

Phase 0 (структура) → Phase 1 (анализ) → Phase 2 (фильтр) → Phase 3 (индекс) → ответ → Phase 4-6

Suggest Cursor Rules

Mission Briefing

Проведи ретроспективный анализ текущей сессии и предложи Cursor Rules для сохранения ценного контекста и паттернов. Это не просто список — нто процесс дистилляции знаний.


Phase -1: Context Gathering (Обязательно первым)

Перед анализом сессии ОБЯЗАТЕЛЬНО изучи существующий контекст проекта:

1. Существующие правила

Прочитай все файлы .cursor/rules/*/RULE.md:

  • Какие правила уже определены?
  • Какой стиль и формат используется?
  • Какие области уже покрыты?

2. Существующие команды

Прочитай все файлы .cursor/commands/*.md:

  • Какие команды уже есть?
  • Какой стиль форматирования?

Зачем это нужно

  • Не предлагать дубликаты существующих правил
  • Понимать контекст и стиль проекта
  • Расширять существующие правила вместо создания новых (если уместно)

Phase 0: Session Analysis (Внутренняя рефлексия)

Проанализируй каждый turn разговора от начала до этой команды:

Что искать:

  • ბпехи: Какие паттерны привели к правильному решению?
  • Ошибки и исправления: Где подход провалился? Что исправил пользователь?
  • Открытые файлы: Какие файлы обсуждались? Какие паттерны в них?
  • Изменения кода: Какие архитектурные решения были приняты?
  • Domain knowledge: Какие специфические знания о проекте были раскрыты?

Сравни с существующими правилами (из Phase -1):

  • Какие инсайты уже покрыты существующими правилами?
  • Какие паттерны действительно новые?

Выведи краткий bullet-list инсайтов (для себя, не финальный отчёт).


Phase 1: Lesson Distillation & AI Pre-Check

Quality Filter

Для каждого потенциального правила выполни проверку:

Check Критерий Вопрос
A0 Not Duplicate Правило уже существует в .cursor/rules/?
A1 Universal Применимо к разным проектам/задачам?
A2 Abstracted Общий принцип, не привязан к этой сессии?
A3 High-Impact Предотвращает реальные проблемы?

AI Pre-Check Results

Для каждого кандидата выведи внутреннюю проверку:

Кандидат: "fail-fast-principle"
├── A0 Not Duplicate: нет в существующих правилах
├── A1 Universal:     применимо к любому backend
├── A2 Abstracted:    общий принцип, не про конкретный баг
├── A3 High-Impact:   предотвращает silent failures
└── RESULT: PASS -- включить в предложения
Кандидат: "tdd-workflow"
├── A0 Not Duplicate: уже есть .cursor/rules/tdd-workflow/RULE.md
└── RESULT: REJECT -- правило уже существует
Кандидат: "fix-jwt-token-issue"
├── A0 Not Duplicate: нет в существующих правилах
├── A1 Universal:     специфично для этой задачи
├── A2 Abstracted:    привязано к конкретному багу
├── A3 High-Impact:   средний импакт
└── RESULT: REJECT -- не предлагать

Выводи ТОЛЬКО правила с результатом PASS.

Категоризация

Категория Когда использовать
Global Принцип для ЛЮБОГО проекта
Project Специфика текущего проекта/стека

Phase 1.5: Index Output (Preview с подробностями)

После AI Pre-Check выведи детальный индекс с обоснованием каждого правила:

Формат индекса

## Найдено N правил

### Global (M)

**1. fail-fast-principle**
- Суть: Exceptions вместо ruurn null/empty, без fallbacks
- Зачем: Баги видны сразу, не прячутся в silent failures  
- Откуда: [момент сессии где это проявилось]

**2. github-research-proofs**
- Суть: При исследовании -- ссылки, цитаты, таблицы с пруфами
- Зачем: Ответы проверяемы, не "я так думаю"
- Откуда: [момент сессии]

### Project (K)

**3. tdd-workflow**
- Суть: Red -> Green -> Refactor с остановками на каждой фазе
- Зачем: Контроль над процессом, нет спешки
- Откуда: [момент сессии]

---
Продолжить? `y` -- все, `1` -- Global, `2` -- Project, `n` -- отмена

После ответа пользователя

Ответ Действие
y / Enter Phase 2 -- все предложения полностью
1 Phase 2 -- только Global группа
2 Phase 2 -- только Project группа
1,2 Phase 2 -- обе группы
n Завершить без предложений

Phase 2: Rule Proposals

Для каждого выжившего правила выведи:

### N. [название-в-kebab-case]

**Категория**: Global | Project
**Pre-Check**: A0 A1 A2 A3

**Причина**:
- Почему важно?
- Какую проблему предотвращает?

**Триггер**:
- `alwaysApply: true` -- всегда
- `globs: ["**/*.ts"]` -- для файлов
- Manual -- через @upominanie

**RULE.md**:

---
description: "Краткое описание (1 строка)"
globs:
  - "puth/**"
alwaysApply: false
---

[Содержимое правила]

---

Phase 3: User Selection

После вывода предложений выведи:

## Выбор

Ответь в формате: `1+, 2-, 3~ sdelaj koroche`

- + -- sozdat kak est
- - -- otklonit  
- ~ -- modificirovat (ukazhi chto izmenit)

Ili: `all` dlya vseh, `0` dlya otmeny.

Pri sozdanii:

  1. Sozdaj .cursor/rules/[nazvanie]/RULE.md
  2. Podtverdi: Sozdano: .cursor/rules/nazvanie/RULE.md

Primery kachestvennyh pravil

Tip Primery
Arkhitektura Moduli, sloi, naming conventions
Workflow TDD, fixtures, git workflow
Integracii API retry, error handling, env config
Debug Format logov, trejsing
Domain Biznes-logika, terminy, svyazi

Kriticheskie pravila

  1. NE sozdavaj avtomaticheski -- tolko posle vybora polzhovatelya
  2. NE predlagaj trivialnye -- Quality Filter obyazatelen
  3. < 500 strok -- bolshie razbivaj
  4. Self-contained -- ponyatno bez konteksta
  5. Actionable -- konkretnye instrukcii, ne sovety

Nachni

Phase -1 (Context) -> Phase 0 -> Phase 1 (Pre-Check) -> Phase 1.5 (Index) -> otvet polzhovatelya -> Phase 2 -> Phase 3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment