chore: update agent rules, skills and workflows

.agent/skills/git-commit-formatter/SKILL.md

@@ -1,30 +1,30 @@
 ---
 name: git-commit-formatter
-description: Formats git commit messages according to Conventional Commits specification. Use this when the user asks to commit changes or write a commit message.
+description: Форматирует сообщения коммитов git в соответствии со спецификацией Conventional Commits. Используйте этот навык, когда пользователь просит закоммитить изменения или написать сообщение к коммиту.
 ---
 
-# Git Commit Formatter Skill
+# Навык форматирования коммитов Git
 
-When writing a git commit message, you MUST follow the Conventional Commits specification.
+При написании сообщения коммита вы ДОЛЖНЫ следовать спецификации Conventional Commits.
 
-## Format
+## Формат
 `<type>[optional scope]: <description>`
 
-## Allowed Types
-- **feat**: A new feature
-- **fix**: A bug fix
-- **docs**: Documentation only changes
-- **style**: Changes that do not affect the meaning of the code (white-space, formatting, etc)
-- **refactor**: A code change that neither fixes a bug nor adds a feature
-- **perf**: A code change that improves performance
-- **test**: Adding missing tests or correcting existing tests
-- **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation
+## Допустимые типы
+- **feat**: Новая функциональность
+- **fix**: Исправление ошибки
+- **docs**: Изменения только в документации
+- **style**: Изменения, не влияющие на смысл кода (пробелы, форматирование и т.д.)
+- **refactor**: Изменение кода, которое не исправляет ошибку и не добавляет функциональность
+- **perf**: Изменение кода, повышающее производительность
+- **test**: Добавление недостающих тестов или исправление существующих
+- **chore**: Изменения в процессе сборки или вспомогательных инструментах и библиотеках
 
-## Instructions
-1. Analyze the changes to determine the primary `type`.
-2. Identify the `scope` if applicable (e.g., specific component or file).
-3. Write a concise `description` in imperative mood (e.g., "add feature" not "added feature").
-4. If there are breaking changes, add a footer starting with `BREAKING CHANGE:`.
+## Инструкции
+1. Проанализируйте изменения, чтобы определить основной тип (`type`).
+2. Определите область (`scope`), если это применимо (например, конкретный компонент или файл).
+3. Напишите краткое описание (`description`) в повелительном наклонении (например, "add feature", а не "added feature").
+4. Если есть критические изменения, добавьте подвал, начинающийся с `BREAKING CHANGE:`.
 
-## Example
+## Пример
 `feat(auth): implement login with google`