lencx skills
lencx-skills
Два скилла для Claude Code и Codex: keel решает вопросы архитектуры, coding-protocol держит правки кода в границах задачи
- 197 ★ репозитория
- Последний коммит
- MIT
Минимальный доступ
Почему такой уровень
- Скиллы состоят из инструкций и справочных файлов, сами ничего не запускают и не обращаются к сети
- Coding-protocol сужает действия агента, но менять файлы и Git агент продолжает с теми правами, которые у него уже есть
Установка
- Работает в
В терминале, через SkillFoxx CLI
npx skillfoxx add skills/lencx-skillsОпределит агенты на машине, покажет уровень доступа и зафиксирует версию.
Другие способы установки
Доступ и проверки
Как мы проверяемМинимальный доступИнструмент ничего не запускает и не ходит в сеть.
- Скиллы состоят из инструкций и справочных файлов, сами ничего не запускают и не обращаются к сети
- Coding-protocol сужает действия агента, но менять файлы и Git агент продолжает с теми правами, которые у него уже есть
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
Набор из двух скиллов, которые ставятся вместе. Keel включается, когда нужно выбрать, проверить или удержать архитектуру: кто за что отвечает, где проходят границы модулей, кому принадлежит состояние, как выглядят контракты и восстановление после сбоя. Скилл работает в четырех режимах: решение (сравнить варианты), оценка готового проекта, надзор за уже принятой архитектурой и выход, когда архитектура задана и осталось реализовать. Coding-protocol срабатывает на правках кода, отладке, ревью, планах реализации и операциях с Git. Осторожность он подбирает по масштабу возможных последствий. Для чтения файлов он ничего не меняет, для локальной правки запускает самую узкую проверку, для бага или рефакторинга воспроизводит ошибку и ищет потребителей изменяемого кода, а перед необратимым действием выясняет цель, полномочия и путь отката. Выводы строятся на коде, тестах и выводе команд, проверкой считается только то, что реально запускалось. Оба скилла сами проверяют, подходит ли им задача. Если задача не по профилю, скилл объявляет несоответствие, ищет в каталоге подходящий скилл-исполнитель и передает работу ему.
Для кого. Разработчикам и техлидам, которые поручают агенту правки в существующем репозитории и хотят, чтобы он сверял архитектурные границы и не выходил за рамки задачи.
Подходит, если
- Проектируется новый сервис, и нужно сравнение нескольких жизнеспособных вариантов границ модулей и владельцев состояния
- Есть RFC или готовая схема, и агент должен оценить ее по заданным критериям, не подсказывая замену
- Архитектурные правила в репозитории обходят раз за разом, и надо решить: вернуть проверку, перенести правило или удалить
- Агент чинит баг в общем контракте, и перед правкой нужны воспроизведение и список потребителей
- Перед коммитом или слиянием важно сохранить чужие незакоммиченные изменения в рабочем дереве
Не подходит, если
- Архитектура уже задана, и осталось ее реализовать: `keel` сам выходит из такой задачи
- Нужно объяснить код или поправить текст без изменения контрактов: `coding-protocol` такие задачи не берет
- Набор уже стоит как плагин: второй способ установки дублирует каждый скилл
- Нужны советы по конкретному фреймворку: скиллы описывают общий порядок работы и не привязаны к стеку
Пример запроса к агенту
Сравни два варианта границы между модулем заказов и модулем оплаты через `keel` и порекомендуй один, назвав допущения, от которых зависит выборОграничения
- Скиллы объемные: SKILL.md у `keel` занимает около 130 строк, и еще шесть справочных файлов подгружаются по ходу работы, так что на мелких задачах контекст расходуется впустую.
- Тексты скиллов на английском. Режимы строгие: при неподходящей задаче скилл сразу объявляет несоответствие и уходит.
- Установка двумя способами сразу создает дубли, поэтому выберите skills installer или плагин.
- Последний коммит в репозитории датирован 21 августа 2026 года, тестов и примеров прогона в репозитории нет.
Как отключить. Удалите папки `keel` и `coding-protocol` из каталога скиллов агента. Если ставили плагином, отключите lencx-skills в менеджере плагинов Claude Code или Codex.
Частые вопросы
Чем `keel` отличается от `coding-protocol`?
Keel решает вопросы уровня архитектуры: границы, владельцев состояния, контракты, миграции. Coding-protocol регулирует сам процесс правки: проверки, доказательства, сохранение чужих изменений. Если архитектура уже выбрана, `keel` уступает место обычной реализации.
Как поставить lencx/skills в Claude Code?
Выполните `npx skills@latest add lencx/skills -a claude-code -g` либо подключите плагин командами `claude plugin marketplace add lencx/skills` и `claude plugin install lencx-skills@lencx`. Выберите один способ из двух, иначе скиллы появятся дважды.
Что делает `keel`, если архитектура уже задана?
Выходит из задачи: объявляет, что осталась только реализация, ищет в каталоге скиллов подходящий скилл-исполнитель и дальше работает общий режим агента.
Какие агенты поддерживает lencx/skills?
Claude Code и Codex. Для каждого есть родной плагин, а команда `npx skills@latest add lencx/skills -a claude-code -g` или `-a codex -g` ставит скиллы под выбранного агента.
Что делает `coding-protocol`, если нужно только объяснить код?
Ничего не меняет. Объяснения и правки текста без изменения контрактов он пропускает: объявляет несоответствие и возвращает задачу общему режиму агента.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
СкиллыСкилл для Claude Code, который передает задачи в командную строку Codex от OpenAI для анализа, ревью и правок кода
Независимые скиллы на весь цикл разработки: продукт, архитектура, планирование, реализация, QA, поставка и эксплуатация
14 скиллов, которые находят пробелы в задаче до кода: интервью, план, проверка допущений и доказательство исправления бага
22 скилла на весь цикл проекта в Claude Code: от настройки и границ задачи до код-ревью, проверки перед пушем и заметок сессий.
Набор утилит для Claude Code: фоновые скиллы, экспертные агенты, слэш-команды и шаблоны промптов для разработки
61 небольшой скилл для Codex по 13 областям: разбор кодовой базы, тесты, миграции, безопасность, CI и ревью pull request
Сравнение с похожими
Карточки с тем же главным запросом: чем они отличаются.
| Инструмент | Официальный | Звезды репозитория | Главное отличие |
|---|---|---|---|
| lencx skills (эта карточка) | нет | 197 | |
| The Architect | нет | 574 | плагин расспрашивает про задачу и пишет план сборки, а здесь скиллы оценивают и ведут архитектуру существующей системы |
| architecture-map | нет | 383 | скилл рисует карту репозитория, а keel принимает архитектурные решения и следит за их соблюдением |
Коротко о README
README разбит на установку (skills installer или родной плагин для Claude Code и Codex), список из двух скиллов и рекомендуемые компаньоны: Matt Pocock's Skills для рабочих процессов инженера и Impeccable для дизайна интерфейсов. Автор советует описывать цель, критерии успеха и ограничения, а план шагов оставлять агенту.
Бейдж для README
Исходный SKILL.md
--- name: keel description: "Design, review, or govern load-bearing architecture for open choices, design judgments, or long-lived health; skip fixed-architecture execution. Applies to new/existing systems. Private/local/reversible module boundaries qualify; scale rigor to impact. Covers responsibility/authority, interfaces/contracts, dependency/state/recovery, structural seams, guards/exceptions, drift/rot, migration, retirement, deletion, and rewrite risk." --- # Keel Keel discovers, judges, and governs load-bearing arrangements. It shapes the best-supported direction and keeps declared architecture enforceable, economical, migratable, and deletable as the system evolves. Use *keel* at module, boundary, and system scale for responsibility between parts, authority or ownership, interfaces or contracts, dependency direction, state or recovery ownership, and seams that isolate future change. Use repository-native terms and treat applicable instructions, records, contracts, and entry paths as evidence rather than decoration. ## State And Ownership Inspect only enough of the request, governing sources, and representative call sites or contracts to select the current state. Transition only when evidence changes the architecture job: - **Decision** — establish, change, or compare a load-bearing arrangement. This includes greenfield work and an authorized improvement to an existing target. - **Judgment** — evaluate the adequacy, conformance, or feasibility of a supplied architecture, design, RFC, change set, or existing system. Keep the target fixed. If it is infeasible, finish Open with evidence and required decision authority; enter Decision only when selection or improvement is authorized. - **Governance** — decide whether to restore, retain, migrate, retire, or remove a declared or evidenced architecture arrangement or control, or judge its long-lived health. Evidence must show a load-bearing obligation, recurring bypass, or architecture drift rather than ordinary maintenance. Enter Decision only when an authorized remedy requires a new load-bearing arrangement. - **Exit** — the request and governing sources fix a feasible material architecture and the remaining task only implements, diagnoses, tunes, tests, or verifies within it. Re-enter only when evidence opens a materially different load-bearing Decision, Judgment, or Governance issue. Private, local, reversible, and single-consumer choices can still require Decision or Judgment; scale evidence and ceremony to impact, reversibility, and uncertainty. Focused workflows own their domain evidence, criteria, method, vocabulary, artifact, professional judgment, and completion condition. Keel integrates only the load-bearing architecture result under declared decision authority; execution workflows own mutation, work preservation, test mechanics, and verification. Automatic or forced loading grants neither applicability nor action authority. On Exit, inspect the skill catalog when the host exposes one, select and completely read a suitable owning workflow when present, and otherwise continue with the general workflow. Stop using Keel-specific routes, references, and output framing. ## Solve Constructively Decision, Judgment, and Governance share a bounded evidence loop but do different work. Decision compares directions. Judgment tests the supplied target and transitions to Decision before proposing improvements. Governance compares applicable restoration, retention, migration, retirement, removal, and no-action responses. 1. **Frame and inspect** — state the current state's question, desired outcome, authority, hard constraints, and criteria. **Greenfield evidence** consists of user goals, explicit external constraints, provenance-bearing focused or domain findings, and operating context. Treat architecture shapes as candidates, label assumptions, and treat absent repository precedent as unavailable rather than inventing inherited architecture. Search only for evidence likely to change the framing, candidate set, or result. 2. **Form, test, or compare** — for Decision, derive the smallest set of materially distinct viable directions needed to expose the real tradeoff. For Judgment, test the supplied target against the same declared criteria without generating replacement directions. For Governance, compare only applicable interventions. Include a simpler or no-change result when credible; do not invent alternatives when constraints leave one path. Use a bounded model, characterization, conformance check, or reversible experiment when it is the cheapest decision-changing evidence. 3. **Integrate and return** — preserve focused-workflow findings, assess evidence and any real candidates on the same criteria, and return the best-supported direction, verdict, or governance action with its material tradeoffs and confidence. Surface a better option the user did not name when evidence supports it without silently changing the goal. 4. **Deepen only the supported result** — resolve numbered concerns only when their answers can still change the result, adoption, recovery, or retirement plan. Stop when more search, options, or detail are unlikely to change the result or close a material risk. If new evidence reopens a viable direction, compare it rather than defending the incumbent. Decision, Judgment, and Governance finish in one of two states; Exit hands off without this framing: - **Closed** — the best-supported result, applicable authority, accountability, and material risks are resolved; no known unknown can still change the result.