| name | rarus-echo-maintainer |
| description | Используй, когда работаешь с GitHub issues, процессом сопровождения, OpenSpec, ветками, pull requests или CI для mesilov/rarus-echo-php-sdk. |
| user-invocable | true |
Сопровождение RARUS Echo
Репозиторий: mesilov/rarus-echo-php-sdk
Используй этот скилл для сопровождения репозитория через GitHub issue: чтение задачи, планирование реализации, решение о необходимости OpenSpec, создание ветки, запуск проверок, открытие pull request и контроль CI.
Начало работы
- Перед реализацией загрузи GitHub issue. Прочитай заголовок, описание, labels, milestone, assignees, комментарии и связанные pull requests.
- Из корня репозитория проверь текущее состояние:
pwd
git status --short --branch
openspec list
openspec list --specs
- Сохраняй несвязанные локальные изменения. Не сбрасывай, не удаляй, не добавляй в индекс и не форматируй файлы вне области issue.
- Используй
dev как базовую ветку для работы по issue, если пользователь явно не указал другое.
- Создай ветку с именем:
feature/<issue-number>-<short-slug>
bugfix/<issue-number>-<short-slug>
docs/<issue-number>-<short-slug>
Политика OpenSpec
Создавай или обновляй OpenSpec change для:
- изменений публичного SDK API;
- поведения, видимого пользователям SDK;
- изменений архитектуры или сервисного слоя;
- изменений CI, процесса поддержки или процесса сопровождения.
OpenSpec можно пропустить для исправления опечаток, обновления зависимостей, механического форматирования и тривиальных правок документации в одном файле.
Когда OpenSpec обязателен:
- Проверь пересекающиеся активные изменения через
openspec list.
- Создай или продолжи
openspec/changes/<change-id>/.
- Синхронизируй
proposal.md, design.md при необходимости, tasks.md и дельты спецификаций с реализацией.
- Проверь:
make lint-openspec
- Архивируй завершенные изменения только после merge соответствующего pull request:
openspec archive <change-id> --yes
Правила реализации
- Следуй существующей структуре SDK:
Services, Core, Infrastructure, Contracts, immutable result/configuration objects, strict types и PSR-compatible dependencies.
- Держи изменения в рамках issue.
- Добавляй или обновляй тесты, когда меняется runtime-поведение PHP-кода.
- Обновляй
README.md, CONTRIBUTING.md или артефакты OpenSpec, когда меняется процесс или публичное использование.
- Не добавляй правила, специфичные для Bitrix24, generated result-item contracts, OpenAPI refresh steps или выбор веток v1/v3. Это относится к другим SDK, не к этому репозиторию.
Проверка
Для OpenSpec или изменений только процесса запускай:
make lint-openspec
git diff --check
make test-unit
make lint-all
Для изменений PHP-поведения дополнительно запускай точечные unit-тесты, покрывающие измененный код. Integration tests запускай только когда issue затрагивает поведение реального API и доступны учетные данные:
make test-integration
Если обязательную проверку нельзя запустить из-за отсутствующей инфраструктуры или учетных данных, укажи точный блокер и не описывай issue как завершенную.
Pull Request
Открывай pull request только после зеленой локальной проверки или после явно задокументированного внешнего блокера.
Правила:
- Отправь issue branch в
origin.
- Открой pull request в
dev.
- Добавь
Closes #<issue-number> в тело PR как обычный текст.
- Укажи команды проверки, которые прошли.
- Проверь PR CI после открытия или обновления PR.
- Проверь inline review threads и top-level comments от agent reviewers: Codex, Claude и других review bots.
- Для каждого agent comment проверь обратную связь по текущему коду, внеси корректную правку или ответь технической причиной, если комментарий устарел или неприменим.
- Резолвь review thread только после правки, устаревания комментария или ответа с причиной, почему изменение не требуется.
- Не сообщай, что issue завершена, пока обязательные CI checks не стали зелеными и agent review threads не обработаны.
