// Use when working with massCode issues, branches, commits, pull requests, or merge preparation in GitHub.
| name | github-workflow |
| description | Use when working with massCode issues, branches, commits, pull requests, or merge preparation in GitHub. |
Если работа идёт по issue, читать его через gh:
gh issue view <number> -R massCodeIO/massCode
Если issue описывает bug, не считай его автоматически подтверждённым.
Сначала:
Если bug не воспроизводится или issue описан неясно:
Создавай ветку от main с префиксом по типу изменения (feat/, fix/, chore/, refactor/) и коротким описанием. Если работа идёт по issue — уместно добавить номер в конец.
git checkout main && git pull
git checkout -b feat/<short-description> main
Заголовок PR — conventional commits:
type: description
Перед созданием PR предложи заголовок пользователю на подтверждение.
Если PR закрывает существующий issue, в описании добавляй:
closes #123
Перед PR убедись, что релевантные проверки и тесты для затронутой области действительно прогнаны.
Создание:
gh pr create \
--base main \
--head <branch-name> \
--title "type: description" \
--body "closes #<issue_number>" \
--assignee @me
Если issue нет — в --body кратко опиши суть изменений без служебного AI-хвоста.
После создания PR предложи пользователю смерджить его в main:
gh pr merge <pr_number> -R massCodeIO/massCode --squash --delete-branch
После merge синхронизируй локальную ветку:
git checkout main && git pull
git branch -d <branch-name>
feat(notes):, 'fix(math):).Co-Authored-By.
Use when working in massCode and you need repo-wide architecture rules, naming conventions, decomposition boundaries, or guidance on which massCode skill to load next.
Use when adding or updating massCode documentation, documenting a new feature, changing docs website pages, adding docs assets, updating the VitePress sidebar, or adding README feature mentions.
Use when defining or reviewing massCode renderer types that come from generated API clients or DTOs, especially when deciding whether to reuse existing API shapes, derive narrower local types, or introduce a UI-only model.
Use when following massCode repo workflow rules, especially for scoped lint and test commands, or when changes require required follow-up commands like code generation or locale sync.
Use when changing massCode API routes, DTOs, IPC handlers, Electron bridges, or any renderer-to-main communication and storage-access boundaries.
Use when changing massCode localization, adding user-facing strings, creating locale keys, or wiring text through the project's translation system.