Docs Sync
microsoft/apm
A skill your agent uses whenever a pull request is opened, reopened, or synchronized in microsoft/apm to assess whether and how the documentation corpus must change to stay truthful with the…
Review a Pull Request or diff in the @alfalab/core-components UI library — correctness bugs, public API/breaking changes, accessibility, keyboard/focus/pointer interaction, component states…
Install Core Components Code Review
$ npx skills add core-ds/core-components --skill core-components-code-review -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install core-ds/core-components core-components-code-review --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/core-ds/core-components.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/core-components-code-review .claude/skills/core-components-code-review && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "core-components-code-review" agent skill from https://github.com/core-ds/core-components/tree/master/.agents/skills/core-components-code-review into .claude/skills/core-components-code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "core-components-code-review", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/core-ds/core-components/tree/master/.agents/skills/core-components-code-reviewType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add core-ds/core-components --skill core-components-code-review -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install core-ds/core-components core-components-code-review --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/core-ds/core-components.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.agents/skills/core-components-code-review .agents/skills/core-components-code-review && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "core-components-code-review" agent skill from https://github.com/core-ds/core-components/tree/master/.agents/skills/core-components-code-review into .agents/skills/core-components-code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "core-components-code-review", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add core-ds/core-components --skill core-components-code-review -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install core-ds/core-components core-components-code-review --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/core-ds/core-components.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.agents/skills/core-components-code-review .cursor/skills/core-components-code-review && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "core-components-code-review" agent skill from https://github.com/core-ds/core-components/tree/master/.agents/skills/core-components-code-review into .cursor/skills/core-components-code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "core-components-code-review", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/core-ds/core-components.git --path .agents/skills/core-components-code-review--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add core-ds/core-components --skill core-components-code-review -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install core-ds/core-components core-components-code-review --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/core-ds/core-components.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.agents/skills/core-components-code-review .gemini/skills/core-components-code-review && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "core-components-code-review" agent skill from https://github.com/core-ds/core-components/tree/master/.agents/skills/core-components-code-review into .gemini/skills/core-components-code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "core-components-code-review", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install core-ds/core-components core-components-code-reviewInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add core-ds/core-components --skill core-components-code-review -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/core-ds/core-components.git skills-src && mkdir -p .github/skills && cp -r skills-src/.agents/skills/core-components-code-review .github/skills/core-components-code-review && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "core-components-code-review" agent skill from https://github.com/core-ds/core-components/tree/master/.agents/skills/core-components-code-review into .github/skills/core-components-code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "core-components-code-review", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add core-ds/core-components --skill core-components-code-review -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install core-ds/core-components core-components-code-review --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/core-ds/core-components.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.agents/skills/core-components-code-review .opencode/skills/core-components-code-review && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "core-components-code-review" agent skill from https://github.com/core-ds/core-components/tree/master/.agents/skills/core-components-code-review into .opencode/skills/core-components-code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "core-components-code-review", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
core-components-code-review- GitHub stars
- 137
- Token cost
- ~5.4k tokens
- SKILL.md length
- 2,264 words
- Files
- 7 (incl. references)
- Skills in repo
- 2
- Repo updated
- First seen
- Licence
- MIT
At a glance
Review a Pull Request or diff in the @alfalab/core-components UI library — correctness bugs, public API/breaking changes, accessibility, keyboard/focus/pointer interaction, component states…
- Works in 10 steps: Понять intent PR → Изучить diff → Изучить окружающий код → …
- Asked to review a PR
- SKILL.md covers Назначение, Главный принцип, Контекст: компонент как… and Входные данные, plus 13 more sections
- Calls git
What it does
Core Components Code Review is an agent skill from core-ds/core-components. Review a Pull Request or diff in the @alfalab/core-components UI library — correctness bugs, public API/breaking changes, accessibility, keyboard/focus/pointer interaction, component states, visual/layout regressions, SSR/browser compatibility, performance, and test coverage. Use when asked to review a PR, review changes to a component under packages/, or check a diff before merge.
Its SKILL.md is about 5.4k tokens, which your agent loads only when the skill is triggered. The skill folder holds 7 other files, including reference files (for example `references/accessibility-interaction.md`, `references/code-conventions.md` and `references/platform-and-performance.md`).
It sits in Development, covering Pull requests, Code review and Test coverage. The licence is MIT.
When your agent uses it
- Asked to review a PR
- Review changes to a component under packages/
- Check a diff before merge
Example prompts
- “/core-components-code-review”
Workflow steps
10 steps, taken from the step headings in SKILL.md.
- Понять intent PR
- Изучить diff
- Изучить окружающий код
- Проверить публичный API и совместимость
- Проверить accessibility и interaction
- Проверить состояния компонента и visual/layout
- Проверить SSR, browser compatibility и performance
- Проверить tests и соответствие project conventions
- Проверить каждый potential finding перед публикацией
- Сформировать итог
What it can do on your machine
Read from SKILL.md and the folder at commit 4c64730. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
git
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Core Components Code Review loads about 5.4k tokens when it runs, and up to ~31k if it reads all its reference files. Until then it costs about 103 tokens; SKILL.md has 2,264 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from core-ds/core-components at commit 4c64730, republished under its MIT licence (© core-ds). 2,264 words, ~5,429 tokens.
Download SKILL.mdSave it as
.claude/skills/core-components-code-review/SKILL.md (or your agent's skills folder). This skill also uses 6 other files; get the full folder from GitHub.- name
- core-components-code-review
- description
- Review a Pull Request or diff in the @alfalab/core-components UI library — correctness bugs, public API/breaking changes, accessibility, keyboard/focus/pointer interaction, component states, visual/layout regressions, SSR/browser compatibility, performance, and test coverage. Use when asked to review a PR, review changes to a component under packages/*, or check a diff before merge.
- license
- MIT
Core Components Code Review Skill
Назначение
Этот skill помогает провести ревью Pull Request или diff в библиотеке UI-компонентов @alfalab/core-components. Он предназначен именно для ревью изменений компонентов: корректность поведения, публичный API, accessibility, состояния, визуальные регрессии, платформенная совместимость, тесты — а не для общей проверки code style или вкусовых предпочтений.
Главный принцип
Лучше пропустить сомнительное низкоприоритетное замечание, чем создать ложное или необоснованное замечание.
False positive хуже, чем пропущенный низкоприоритетный issue. Каждое существенное замечание должно быть доказуемо кодом или доступным контекстом, а не предположением.
Контекст: компонент как публичный API
В отличие от ревью обычного приложения, изменения в core-components затрагивают множество потребителей библиотеки: продуктовые команды, интеграции, десятки использований одного и того же компонента. Небольшое изменение в публичном компоненте может повлиять на props, TypeScript-типы, accessibility, визуал, SSR, разные браузеры и design system conventions одновременно.
Поэтому любое изменение в packages/<component> нужно оценивать не только как локальный код, а как изменение публичного контракта. Успешная компиляция и прохождение тестов не являются доказательством того, что поведение компонента корректно.
Входные данные
Собери максимум доступного контекста PR, прежде чем делать выводы:
- diff PR и список изменённых файлов;
- описание PR и связанную задачу;
- тип изменения по conventional commit префиксу (
fix/feat/hotfix/chore/ci/test) — подсказка о характере правки; - затронутые пакеты в
packages/<component-name>/— это единица публичного API; typings.tsкомпонента — публичные props и их типы;- окружающий код:
Component.responsive.tsx,desktop//mobile/варианты, вложенныеcomponents/,utils.ts; - тесты:
*.test.tsx(unit) и*.screenshots.test.tsx(визуальные, Playwright + jest-image-snapshot); - Storybook:
docs/*.stories.tsx,*.docs.mdx,description.mdx; - changeset-файл (
.changeset/*.md) — обязателен для PR, меняющих публикуемый код пакета (влияет на semver); не требуется, если PR затрагивает только Storybook (*.stories.tsx/*.mdx) или служебные скрипты/тулинг репозитория, не влияющие на опубликованные пакеты; - обсуждение PR: замечания людей, ответы автора и статусы CI-джобов для последнего коммита PR (см. «Повторное ревью» и «Проверка запуском»);
- существующие project conventions —
docs/code-review.stories.mdx(чек-лист ревью проекта) и.github/pull_request_template.md(чек-лист автора PR). Эти доки могли устареть (давно не обновлялись) — используй их как отправную точку, но не доверяй им безоговорочно: конкретные утверждения (авточеки, правила) перепроверяй по актуальному состоянию репозитория (реальные workflow в.github/workflows/, реальный код).
Если для подтверждения проблемы не хватает контекста — сначала попытайся его получить (прочитать соседний файл, типы, тесты), а не делать предположение.
Процесс ревью
Проходи по этапам последовательно. Каждый этап, отсылающий к файлу в references/, требует прочитать этот файл целиком через Read перед тем, как делать выводы по соответствующей области — это не необязательная ссылка "см. также", а обязательный шаг.
1. Понять intent PR
Определи по описанию PR, связанной задаче и conventional-commit префиксу: это bugfix, feature, refactoring, чисто визуальное обновление или breaking change. Не начинай искать проблемы, пока не понял, что автор хотел изменить — иначе легко перепутать intentional change с регрессией.
2. Изучить diff
Определи: какие пакеты (packages/<name>) затронуты, какие props/types изменены, какие public exports изменены, какие стили изменены, какие tests/stories/changeset изменены вместе с кодом.
Для каждого затронутого пакета сразу, на этом же этапе (не откладывая до этапа 4) прочитай оба его публичных index.ts: packages/<name>/src/index.ts и packages/<name>/src/shared/index.ts, если он существует. Не делай вывод "компонент не экспортируется, значит изменение внутреннее" на основании одного только корневого index.ts — shared/index.ts есть у большинства пакетов библиотеки (это установленная, широко используемая конвенция проекта, не редкое исключение) и реэкспортирует часть вложенных components/* как равноправную вторую точку входа (подтверждается тем, что сборка через preserveModules компилирует каждый файл src/**/*.ts(x) в отдельный модуль, включая shared/index.ts — так что @alfalab/core-components-<name>/shared реально импортируем потребителями). Если по итогам diff'а у тебя есть промежуточный вывод о том, что какой-то изменённый компонент/тип "не публичный", считай его черновым до тех пор, пока не прочитал shared/index.ts этого пакета — прочитанное на этапе 4 общее правило нужно применить повторно к уже сделанным на этом этапе выводам, а не оставлять их как есть.
3. Изучить окружающий код
Не ограничивайся diff. При необходимости прочитай: сам компонент целиком, consumer-код (кто ещё в монорепе использует изменённый компонент/утилиту), hooks, typings.ts, стили, тесты, stories, changeset.
4. Проверить публичный API и совместимость
Прочитай references/public-api.md и следуй чек-листу оттуда. Проверь: не удаляются/переименовываются ли props, не меняются ли типы, default values, обязательность, callback signatures, поведение существующих props; соответствует ли наличие и severity changeset'а характеру изменения (breaking change требует major bump и инструкции миграции).
Если на этапе 2 ты уже решил, что изменённый компонент/проп "внутренний" (не экспортируется), и это решение опиралось только на корневой index.ts — прежде чем продолжать, подтверди его явной проверкой shared/index.ts пакета (см. этап 2). Вывод о том, что что-то не является публичным API, недействителен без этой проверки.
5. Проверить accessibility и interaction
Прочитай references/accessibility-interaction.md и следуй чек-листу оттуда. Проверь semantic HTML, ARIA, keyboard navigation, focus management, pointer interaction для затронутых сценариев.
6. Проверить состояния компонента и visual/layout
Прочитай references/states-and-visual.md и следуй чек-листу оттуда. Проверь релевантные состояния компонента и отличи intentional visual change от unintended regression; проверь controlled/uncontrolled behavior, если применимо.
7. Проверить SSR, browser compatibility и performance
Прочитай references/platform-and-performance.md и следуй чек-листу оттуда. Проверь использование browser-only API в рендере, соответствие поддерживаемым браузерам, потенциальные performance-регрессии в часто используемых компонентах.
8. Проверить tests и соответствие project conventions
Прочитай references/tests-and-conventions.md и следуй чек-листу оттуда. Проверь покрытие тестами изменённого поведения, обновление скриншотов при визуальных изменениях, соответствие "неочевидным правилам" проекта.
Затем прочитай references/code-conventions.md — соглашения кода, CSS и токенов, собранные из замечаний ревьюеров.
9. Проверить каждый potential finding перед публикацией
Для каждого кандидата в findings ответь на 6 вопросов (см. «Принцип доказательности» ниже) и определи: вызвана ли проблема именно этим PR, можно ли её доказать кодом, не является ли она субъективной.
10. Сформировать итог
Включи в результат только подтверждённые и actionable замечания, в формате из раздела «Формат итогового review» ниже. Если существенных проблем нет — прямо так и напиши, не занимайся генерацией замечаний ради количества.
Приоритеты ревью
По убыванию важности:
- Корректность поведения компонента.
- Breaking changes и совместимость публичного API.
- Accessibility.
- Корректность состояний компонента.
- Keyboard, focus и pointer interaction.
- Visual/layout regressions.
- Controlled/uncontrolled behavior.
- SSR/hydration и browser/runtime compatibility.
- Performance.
- Tests.
- Maintainability и readability.
Severity и blocking policy
| Severity | Означает | Blocking |
|---|---|---|
| P0 | Критическая проблема: security vulnerability, массовая поломка компонентов, потеря/повреждение данных, критический a11y-блокер основного сценария | да |
| P1 | Серьёзная проблема: breaking change публичного API без соответствующего changeset, поломка основного сценария компонента, серьёзная accessibility/keyboard regression, SSR/hydration ломается, runtime error в поддерживаемом сценарии, серьёзная visual regression | да |
| P2 | Потенциальная проблема: edge case, проблема отдельного состояния, ограниченная interaction/visual regression, неполное тестирование важного сценария | нет |
| P3 | Улучшение: maintainability, readability, дополнительные тесты, документация — использовать умеренно | нет |
Не блокируй PR только из-за визуального отличия, если оно явно является целью PR или соответствует обновлению design system — сам факт визуального изменения не является доказательством ошибки.
Принцип доказательности
Для каждого существенного finding нужно уметь ответить:
- Где находится проблема (файл, строка/диапазон)?
- Что именно происходит?
- Почему это является проблемой?
- При каких условиях она возникает?
- Каково потенциальное влияние?
- Какая часть кода подтверждает вывод?
Недостаточно написать "здесь может возникнуть race condition" — нужно объяснить механизм и показать подтверждающий код. Если вывод зависит от неизвестного поведения библиотеки/браузера/framework — явно обозначь неопределённость (confidence: low) либо не создавай finding вовсе.
Воспроизведение, которое автор может запустить
Для finding'а, подтверждённого запуском, приложи воспроизведение, которое автор выполнит у себя: тест или команду, которые падают на последнем коммите PR (а после исправления должны проходить). Публикуй воспроизведение в том виде, в каком сам его запускал: незапущенное воспроизведение — это предположение.
Имена компонентов, props, токенов и файлов переписывай из репозитория буква в букву: по имени из замечания автор ищет, что править.
Причинная связь с PR
Приоритет — проблемы, вызванные текущим PR.
Была ли проблема до PR
Прежде чем ставить severity, проверь, вносит ли проблему именно этот PR: посмотри тот же код в базовой ветке (git show <base>:<путь>), а если проблема воспроизводится тестом или командой — запусти то же воспроизведение на базовой ветке.
- До PR работало, после — сломано, или проблема в коде, которого до PR не было, — это предмет ревью, severity по последствиям.
- Существующий код делает новое изменение некорректным — тоже предмет ревью.
- Проблема была и до PR в том же виде — это не P0/P1: PR её не вносит, и блокировать его из-за неё нельзя. Такую проблему либо не выносят вовсе, либо дают finding'ом не выше P2 с пометкой «появилась не в этом PR, не блокирует».
Если PR заявлен как исправление именно этой проблемы, она — предмет ревью. «Было и до PR» — тоже утверждение: без проверки на базовой ветке оно ничего не доказывает.
Show full SKILL.md (947 more words)Show less
Все места с той же проблемой
Почти любая проблема встречается в коде не в одном месте: одна величина подставлена в несколько расчётов, один prop проброшен через несколько компонентов, одна проверка повторена в desktop- и mobile-версии. Если ревью называет только одно место, автор исправит его, а соседнее всплывёт в следующем ревью — понадобится ещё один круг правок.
Нашёл проблему в одном месте — поиском по репозиторию найди остальные места с тем же условием, значением или вызовом и проверь каждое. В finding'е:
- перечисли все найденные места и отдельно назови те, где всё в порядке;
- оформи это одним finding'ом со списком мест; severity — по самому серьёзному из них;
- что считать исправлением, формулируй через суть («во всех расчётах верхнего отступа используется одна величина»), а не через номера строк; тест проси один на все места, а не по тесту на каждое.
Не проси большего, чем проверил: если проверено три места из десяти — так и напиши, не требуй правки «везде».
Проверка запуском
Описание PR и отмеченные пункты чек-листа — заявление автора, а не факт. Если окружение позволяет запускать команды, проверяй точечно — по затронутым пакетам, а не по всему репозиторию: пакетов больше сотни, полная сборка и линт идут долго и уже выполняются в CI.
- Итог долгих проверок (
build,screenshot-test,search-vars,demo) бери из статусов CI для последнего коммита PR. Упавшая джоба — факт для ревью, но сама по себе ещё не finding: сначала посмотри, что именно упало. - Заявление автора, которое запуск опроверг, — отдельный finding.
- В итоге скажи, что проверено запуском и с каким результатом, и отдельно — что проверить не удалось и почему. Если об этом промолчать, читатель решит, что проверено всё.
Повторное ревью
Если по этому PR уже было ревью (агента или человека) и автор ответил — сначала прочитай ответы и исходи из того, что в возражении может быть факт, которого у тебя не было.
| Что стало с замечанием | Что делать |
|---|---|
| Автор принял и поправил | проверь, что правка действительно сделана, и скажи об этом одной строкой; повторно finding'ом не выноси |
| Отклонено аргументированно (автором или мейнтейнером) | тема закрыта: не повторяй ни тем же finding'ом, ни переформулированным, ни как P3 |
| Обсуждается или осталось без ответа | вернуться можно, но только с новым аргументом, отвечающим на возражение по существу. Повтор прошлого текста выглядит так, будто ревьюер не читает ответы |
Не повторяй замечание, которое человек уже высказал в этом же PR. Правки, сделанные после прошлого ревью, разбирай как новый код: исправления сами нередко вносят новые ошибки.
Формат finding
Finding
├── severity (P0 / P1 / P2 / P3)
├── location (файл:строка)
├── problem (краткое описание)
├── evidence (объяснение на основе кода/контекста)
├── impact (что произойдёт при возникновении проблемы)
├── suggested_fix (практическое направление исправления)
└── confidence (high / medium / low)confidence: low обычно не публикуется как finding.
Формат итогового review
## Summary
REQUEST_CHANGES
Found 2 issues:
- 1 P1
- 1 P2
## Findings
### P1 — Компонент теряет keyboard focus после открытия
`packages/select/src/Component.tsx:142`
Описание проблемы.
**Почему это проблема:** причинно-следственное объяснение.
**Влияние:** пользователь клавиатуры не может продолжить навигацию.
**Рекомендация:** восстановить ожидаемый focus management.
## Positive observations
- Хорошо покрыт keyboard interaction.
- Добавлены тесты для нового состояния.Если проблем нет:
## Summary
APPROVE
Существенных проблем в изменениях не найдено.False positives и лимит findings
- Не спекулируй, не выдавай предположения за факты.
- Не придирайся к стилю и вкусовым архитектурным предпочтениям. Исключение — соглашения из
references/code-conventions.md: их нарушение в новом коде даёт finding P3. - Не создавай несколько findings для одной и той же проблемы.
- Не комментируй код без actionable причины.
- Не комментируй построчно сгенерированные файлы (
CHANGELOG.md,yarn.lock). Если такой файл меняется без соответствующего изменения вpackage.jsonили changeset — это повод для вопроса, а не для разбора содержимого. - Не блокируй PR из-за несущественных улучшений.
- Отличай намеренное visual изменение от visual regression.
- Проверь каждую находку (этап 9) перед тем, как включить её в итог.
- Не заполняй review искусственно: если найдено 2 реальные проблемы — покажи 2, а не генерируй дополнительные ради количества. По умолчанию ограничивай вывод
max_findings: 10; при превышении — приоритет по severity → confidence → impact.
Доменные чек-листы
Детальные, привязанные к конкретному стеку и конвенциям этого проекта чек-листы вынесены в отдельные файлы — читай их на соответствующем этапе процесса (см. выше), не пропускай этот шаг:
| Файл | Тема | Когда читать |
|---|---|---|
references/public-api.md | Публичный API, breaking changes, changesets | Этап 4 |
references/accessibility-interaction.md | Accessibility, keyboard/focus/pointer | Этап 5 |
references/states-and-visual.md | Состояния компонента, controlled/uncontrolled, visual/layout regression | Этап 6 |
references/platform-and-performance.md | SSR/hydration, browser compatibility, performance | Этап 7 |
references/tests-and-conventions.md | Tests, CI-авточеки, project-specific "неочевидные правила" | Этап 8 |
references/code-conventions.md | Соглашения кода, CSS и токены — из замечаний ревьюеров | Этап 8 |
В каждом из этих файлов есть таблица severity для своей области. Там же могут быть реальные примеры из истории проекта — коммиты, diff'ы, цитаты из ревью. Используй их как основной источник конкретики, а не только общие принципы этого файла.
Если пользователь явно просит сузить ревью (например, "проверь только accessibility" или "не смотри на performance") — следуй этому вместо прохождения всех этапов 4–8; иначе ревью по умолчанию покрывает все этапы и все severity, с лимитом max_findings: 10.
Примеры хороших и плохих findings
Ниже — иллюстративные примеры формулировок (не привязаны к конкретному коммиту, в отличие от примеров в references/*.md), показывающие разницу между поверхностным и обоснованным finding'ом.
Плохо — вкусовщина, не проблема:
Логику пересчёта
activeIndexвTabsстоит вынести в отдельный хук, так читать компонент будет проще.
Это архитектурное предпочтение без демонстрации, что текущий код что-то ломает — не finding (см. «False positives»).
Плохо — visual diff без доказательства:
В скриншоте
Sliderизменился отступ подписи на несколько пикселей — похоже на регрессию.
Сам факт изменённого скриншота ничего не доказывает (см. references/states-and-visual.md, «Отличие intentional visual change от regression») — нужно показать, что это не соответствует цели PR, или что в diff нет объясняющего это CSS-изменения.
Хорошо — конкретный keyboard/focus finding (гипотетический, для иллюстрации формата — не привязан к реальному коду Modal):
После закрытия
Modalчерез клик по backdrop фокус не возвращается на элемент, открывший модалку — путь закрытия через backdrop не проходит через ту же логику восстановления фокуса, что и закрытие через кнопку/Escape(см. соответствующие обработчики в diff). Пользователь, открывшийModalс клавиатуры, после закрытия через backdrop теряет позицию навигации и вынужден заново обходить страницу табом.
Конкретный механизм (какой путь закрытия не восстанавливает фокус и почему), конкретный impact — а не просто "могут быть проблемы с фокусом".
Хорошо — конкретный API finding (гипотетический, для иллюстрации формата — реальный пример такого рода см. в references/public-api.md):
Union-тип
viewуButtonсужен — удалён вариант'tertiary', при этом changeset помеченpatch, а неmajor. Потребители, использующиеview='tertiary', получат TS-ошибку компиляции при обновлении, но не получат ожидаемого major-бампа, сигнализирующего о breaking change (см.references/public-api.md, правило changeset).
Конкретное изменение публичного контракта, конкретное следствие для потребителей, конкретная нестыковка bump-типа.
© core-ds, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
SKILL.md and 6 other files (references) in .agents/skills/core-components-code-review of core-ds/core-components.
- SKILL.md
- references/accessibility-interaction.md
- references/code-conventions.md
- references/platform-and-performance.md
- references/public-api.md
- references/states-and-visual.md
- references/tests-and-conventions.md
Open the folder on GitHubat commit 4c64730
Compare with similar skills
Core Components Code Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Core Components Code Review this skillcore-ds/core-components | 137 | — | ~5.4k | Automated safety check: Pass | MIT | |
| Docs Syncmicrosoft/apm | 4k | — | ~3k | Automated safety check: Pass | MIT | |
| Evaluate PR Testsdotnet/maui | 23k | — | ~2.9k | Automated safety check: Pass | MIT | |
| Code ReviewerYikai-Liao/symusic | 189 | 1 repos | ~1.3k | Automated safety check: Pass | MIT | |
| Code Quality ReviewStudentWeis/ropy | 193 | — | ~2.2k | Automated safety check: Pass | MIT | |
| Tsh Reviewing FrontendTheSoftwareHouse/copilot-collections | 284 | — | ~4.4k | Automated safety check: Pass | MIT |
Similar skills
- Official
- Official
Evaluate PR Tests
dotnet/maui
Reviews the tests added in a pull request for fix coverage, quality, edge cases and test type, and recommends lighter test types where they would do.
Code Reviewer
Yikai-Liao/symusic
Analyzes code diffs and files to identify bugs, security vulnerabilities (SQL injection, XSS, insecure deserialization), code smells, N+1 queries, naming issues, and architectural concerns, then…
Code Quality Review
StudentWeis/ropy
Review a code change, diff, pull request, module, or test suite for code quality, comment and documentation quality, and test quality.
Tsh Reviewing Frontend
TheSoftwareHouse/copilot-collections
Frontend-specific code review criteria, component anti-patterns, hooks quality, rendering correctness, accessibility and performance spot-checks, and module organization issues.
Panel Review
stacklok/mecatl
Review completed non-trivial code across four independent axes: Spec, Standards, Test adequacy, and installed Domain specialists.
More from core-ds/core-components
Core Components
core-ds/core-components
Work with @alfalab/core-components React UI library — imports, theming, MCP tools, and component patterns
Related
Categories
Questions about Core Components Code Review
What does Core Components Code Review do?
Review a Pull Request or diff in the @alfalab/core-components UI library — correctness bugs, public API/breaking changes, accessibility, keyboard/focus/pointer interaction, component states…. Core Components Code Review is an agent skill from core-ds/core-components. Review a Pull Request or diff in the @alfalab/core-components UI library — correctness bugs, public API/breaking changes, accessibility, keyboard/focus/pointer interaction, component states, visual/layout regressions, SSR/browser compatibility, performance, and test coverage.
When should I use Core Components Code Review?
Core Components Code Review fits situations like: asked to review a PR; review changes to a component under packages/; check a diff before merge.
How do I install Core Components Code Review in Claude Code?
Run `npx skills add core-ds/core-components --skill core-components-code-review -a claude-code`. Or copy the skill folder (.agents/skills/core-components-code-review in core-ds/core-components) into .claude/skills/core-components-code-review in your project. Claude Code loads it when a task matches its description.
How do I install Core Components Code Review in Codex?
Run `npx skills add core-ds/core-components --skill core-components-code-review -a codex`. Or copy the skill folder (.agents/skills/core-components-code-review in core-ds/core-components) into .agents/skills/core-components-code-review in your project. Codex loads it when a task matches its description.
Can I use Core Components Code Review in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add core-ds/core-components --skill core-components-code-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/core-components-code-review, .gemini/skills/core-components-code-review, .github/skills/core-components-code-review and .opencode/skills/core-components-code-review in your project.
What does Core Components Code Review need to run?
Going by SKILL.md and its folder, Core Components Code Review needs the command-line tools its instructions call (git).
Does Core Components Code Review access the network?
SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Is Core Components Code Review safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Core Components Code Review use?
Core Components Code Review is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Core Components Code Review use?
About 5.4k tokens (SKILL.md is roughly 22k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 26k tokens, read only when the agent opens those files.
What are the alternatives to Core Components Code Review?
Skills that share tags, products or a category with Core Components Code Review: Docs Sync (microsoft/apm, 4k stars), Evaluate PR Tests (dotnet/maui, 23k stars), Code Reviewer (Yikai-Liao/symusic, 189 stars) and Code Quality Review (StudentWeis/ropy, 193 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Core Components Code Review?
core-ds (a GitHub organization) maintains it in core-ds/core-components, which has 137 GitHub stars. The repository holds 2 skills in this directory. The repository was last updated on October 6, 2026.
Source: core-ds/core-components on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.