Larchanka Skills
Двенадцать независимых скиллов для разработки: цикл агентов с планом и ревью, разбор pull request, TDD и триаж почты.
- 53 ★ репозитория
- Последний коммит
Расширенный доступ
Почему такой уровень
- Скиллы запускают `gh`, скрипты и утилиты на вашей машине.
- Почтовый и Slack-скиллы читают переписку, которой доступ нужно ограничить.
Установка
- Работает в
В терминале, через SkillFoxx CLI
npx skillfoxx add skills/larchanka-skillsОпределит агенты на машине, покажет уровень доступа и зафиксирует версию.
Другие способы установки
Доступ и проверки
Как мы проверяемРасширенный доступИнструмент запускает код или ходит в сеть, а внешние данные только читает.
- Скиллы запускают `gh`, скрипты и утилиты на вашей машине.
- Почтовый и Slack-скиллы читают переписку, которой доступ нужно ограничить.
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
Коллекция из двенадцати самостоятельных скиллов для разработки и автоматизации, у каждого своя папка с `SKILL.md`. Среди них `agent-loop` ведет цикл из субагентов планирования, разработки, ревью и публикации, где координатор не читает код и только передает задачи. `code-review` оценивает изменения по пяти осям: корректность, читаемость, архитектура, безопасность и производительность. `codebase-context-generator` строит контекст проекта через AST и граф зависимостей на Python. Остальные скиллы закрывают `pull-request`, `refactoring`, `test-driven-development`, `planning-and-task-breakdown`, `project-change-intelligence`, `manual-automation`, `email-triage`, `slack-cli` и `yt-random-comment-picker`. Что понадобится из внешних инструментов, зависит от скилла: `gh`, `yt-dlp`, `jscpd`, tree-sitter и другие.
Для кого. Разработчикам, которым нужен набор готовых рабочих процессов для агента: от планирования задачи до публикации pull request.
Подходит, если
- Фичу нужно довести от плана до pull request циклом субагентов с ревью.
- Перед объемной правкой строят карту зависимостей и символов проекта.
- Изменения в ветке оценивают по чек-листам безопасности и производительности.
- Входящую почту разбирают по приоритетам с помощью агента.
Не подходит, если
- Нужен один узкий скилл, а подключать целый набор не хочется.
- На машине нельзя ставить `gh`, `yt-dlp` и другие CLI.
- Команда использует собственный процесс ревью и не хочет менять его.
Пример запроса к агенту
Разбей задачу по плану, реализуй ее через TDD и подготовь pull request после ревью по пяти осям.Ограничения
Общей команды установки нет: каждый скилл самостоятелен, его клонируют или копируют по отдельности, а подробности лежат в его `SKILL.md`. Часть скиллов зависит от внешних программ, например `gh`, `yt-dlp`, Chrome, `slackcli` или gog, и от Python-пакетов из `requirements.txt`. Скиллы `email-triage` и `slack-cli` работают с почтой и рабочим чатом, поэтому им требуется доступ к этим аккаунтам, выдавайте его по минимуму.
Как отключить. Удалите папки отдельных скиллов из каталога скиллов агента и отзовите доступы, выданные почте и Slack.
Частые вопросы
Сколько скиллов в репозитории?
Двенадцать, и каждый лежит в отдельной папке со своим `SKILL.md` и `README.md`.
Что делает `agent-loop`?
Координирует субагентов планирования, разработки, ревью и публикации. Координатор не читает файлы и не пишет код. Ревью повторяется, пока замечаний не останется.
По каким осям идет `code-review`?
По пяти: корректность, читаемость и простота, архитектура, безопасность, производительность.
Нужны ли внешние программы?
Зависит от скилла. В README есть таблицы: `gh`, `yt-dlp`, `jscpd`, tree-sitter и другие с командами установки.
Можно ли взять один скилл?
Да, скиллы независимы. Достаточно скопировать нужную папку и следовать ее `SKILL.md`.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
СкиллыДевять коротких навыков: тесты, ревью, планы в виде ADR, слайды, база знаний, картинки, воркдеревья и исполнение планов.
Builder Skills
Skills for agents
Набор небольших скиллов от Builder.io для рабочих привычек агента: визуальные планы и разборы диффов, сверка с документацией, кросс-агентное ревью и аккуратные
Библиотека скиллов для Claude Code, Cursor и Codex: ревью командой агентов, TDD, стековые PR, оценка готовности репозитория
Brooklyn skills — 25 переносимых скиллов для агентов: ведение pull request, триаж, чистка кода, проверка интерфейса и исследования
Набор независимых скиллов против дрейфа в больших кодовых базах: hard-cut, поиск первопричины, тесты и проверка CI.
Набор из 17 инженерных скиллов: отладка по доказательствам, обзор кода, git worktree, SSH-туннели и мобильная автоматизация.
Коротко о README
Репозиторий описывает двенадцать скиллов, их назначение и требования к внешним программам. В конце есть сводка быстрой установки зависимостей для macOS и Linux.
Бейдж для README
Исходный SKILL.md
--- name: code-review description: Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch. metadata: version: 1.1.0 --- # Code Review and Quality ## Overview Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance. **The approval standard:** Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it. ## When to Use - Before merging any PR or change - After completing a feature implementation - When another agent or model produced code you need to evaluate - When refactoring existing code - After any bug fix (review both the fix and the regression test) ## The Five-Axis Review Every review evaluates code across these dimensions: ### 1. Correctness Does the code do what it claims to do? - Does it match the spec or task requirements? - Are edge cases handled (null, empty, boundary values)? - Are error paths handled (not just the happy path)? - Does it pass all tests? Are the tests actually testing the right things? - Are there off-by-one errors, race conditions, or state inconsistencies? ### 2. Readability & Simplicity Can another engineer (or agent) understand this code without the author explaining it? - Are names descriptive and consistent with project conventions? (No `temp`, `data`, `result` without context) - Is the control flow straightforward (avoid nested ternaries, deep callbacks)? - Is the code organized logically (related code grouped, clear module boundaries)? - Are there any "clever" tricks that should be simplified?