2026-06-04 19:02:37 +07:00
parent de7373210c
commit 81a7b024ee
6 changed files with 135 additions and 3 deletions
							
							
							
						
@@ -0,0 +1,95 @@
# Global AI Agent Rules
Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
## 1. Think Before Coding
**Don't assume. Don't hide confusion. Surface tradeoffs.**
Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
## 2. Simplicity First
**Minimum code that solves the problem. Nothing speculative.**
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
## 3. Surgical Changes
**Touch only what you must. Clean up only your own mess.**
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
## 4. Goal-Driven Execution
**Define success criteria. Loop until verified.**
Transform tasks into verifiable goals:
- "Add validation" -> "Write tests for invalid inputs, then make them pass"
- "Fix the bug" -> "Write a test that reproduces it, then make it pass"
- "Refactor X" -> "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
```
1. [Step] -> verify: [check]
2. [Step] -> verify: [check]
3. [Step] -> verify: [check]
```
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
---
**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.
# Global Rules for All AI Agents
The rules below are mandatory for every interaction and task. They are intentionally placed after the general coding guidelines above, but they have higher priority when a conflict exists.
1. **Communication style:**
   Always reply in Russian, in a friendly peer-to-peer tone, using informal "ты". Appropriate swearing, humor, sarcasm, and irony are allowed and welcome. Communicate like a live programmer teammate, not like a dry robot.
2. **No commits without an explicit request:**
   Never run `git commit` unless the user has directly and unambiguously asked for it. The final commit always remains with the user, or is made strictly by the user's command.
3. **Plain git diff visibility:**
   All changes must remain visible to the user through the standard `git diff` command. Leave modified files in the working directory unstaged. Do not add files to the Git index with `git add` unless the user explicitly asks for staging, committing, or another action that requires staging, because staging hides changes from plain `git diff`.
4. **Typography:**
   Always use the regular hyphen-minus (`-`) instead of long dash characters.
5. **Project context:**
   At the start of work, pay close attention to all provided project `.md` files, because they are provided automatically and contain the current repository's context and specifics.
6. **Reusable skills:**
   When the user repeats the same instruction, output format, correction, or workflow, treat it as a candidate for a reusable skill.
   Do not interrupt active work just to create a skill. Finish the current task first, then briefly propose the skill name, trigger description, and what files or tools it should contain.
   Do not create or edit skill files silently. Create or update a skill only after explicit user approval.
   Keep skills focused: prefer several small skills over one broad skill. A useful skill should have a precise description for when to use it, short instructions for how to act, and reusable tools, templates, references, or examples when they make the result more stable.
   If skill files are outside the current git repository, clearly state the exact paths changed and how the user can inspect them, because those changes are not visible in the project `git diff`.
							
							
							
						
@@ -0,0 +1,48 @@
---
name: el-review-heavy
description: Use when пользователь запрашивает тяжелое code-review между двумя Git-ветками с диффом в стиле GitLab (от merge-base)
---
# Eltex Review Heavy
## Overview
Тяжелое ревью диффа между двумя Git-ветками в стиле GitLab Merge Request (от merge-base). Запускает полный `/code-review` с кучей агентов.
## When to Use
- Пользователь просит "поревьюй ветку feature относительно master" тщательно
- Нужен дифф как на GitLab (без лишних изменений из целевой ветки)
- Формат вызова: `/el-review-heavy <наша-ветка-с-изменениями> <целевая-ветка>`
## Workflow
1. Определи аргументы:
   - `source` — первая ветка (наша, с изменениями, которую ревьюим)
   - `target` — вторая ветка (целевая, в которую мерж-реквест)
2. Выполни `git fetch origin` — обнови remote refs
3. Если текущая checkout-ветка == `source`, выполни `git pull --ff-only origin source` — обнови локальную ветку
4. Построй дифф от merge-base: `git diff origin/target...origin/source > /tmp/el-review-heavy.diff` (три точки!)
5. Прочитай файл `/tmp/el-review-heavy.diff`
6. Запусти скилл `code-review` с этим файлом как аргумент
7. Полученные findings переформатируй:
   - Пронумеруй проблемы
   - Оставь только критические замечания
   - Для каждой предложи готовый дифф с исправлением
   - Объясни простым языком
## Формат вывода
```
## Проблема N: [краткое название]
**Где:** `file.kt:123`
**Что не так:** простым языком, зачем это плохо
**Исправление:**
```diff
- старая строка
+ новая строка
```
```
							
							
							
						
@@ -0,0 +1,48 @@
---
name: el-review
description: Use when пользователь запрашивает легкое code-review между двумя Git-ветками с диффом в стиле GitLab (от merge-base)
---
# Eltex Review
## Overview
Легкое ревью диффа между двумя Git-ветками в стиле GitLab Merge Request (от merge-base). Запускает быстрый `/review` вместо тяжелого `/code-review`.
## When to Use
- Пользователь просит "поревьюй ветку feature относительно master" быстро
- Нужен дифф как на GitLab (без лишних изменений из целевой ветки)
- Формат вызова: `/el-review <наша-ветка-с-изменениями> <целевая-ветка>`
## Workflow
1. Определи аргументы:
   - `source` — первая ветка (наша, с изменениями, которую ревьюим)
   - `target` — вторая ветка (целевая, в которую мерж-реквест)
2. Выполни `git fetch origin` — обнови remote refs
3. Если текущая checkout-ветка == `source`, выполни `git pull --ff-only origin source` — обнови локальную ветку
4. Построй дифф от merge-base: `git diff origin/target...origin/source > /tmp/el-review.diff` (три точки!)
5. Прочитай файл `/tmp/el-review.diff`
6. Запусти скилл `review` с этим файлом как аргумент
7. Полученные findings переформатируй:
   - Пронумеруй проблемы
   - Оставь только критические замечания
   - Для каждой предложи готовый дифф с исправлением
   - Объясни простым языком
## Формат вывода
```
## Проблема N: [краткое название]
**Где:** `file.kt:123`
**Что не так:** простым языком, зачем это плохо
**Исправление:**
```diff
- старая строка
+ новая строка
```
```