← ClaudeAtlas

std-new-modulelisted

Создать новый модуль стандартов (новый стек, фреймворк или язык) в репозитории vibe-rules. Используй, когда пользователь просит "добавить модуль", "завести стандарты под <технологию>", "расширить репозиторий правил" новым стеком.
DanielLetto2020/vibe-rules · ★ 1 · AI & Automation · score 69
Install: claude install-skill DanielLetto2020/vibe-rules
# Новый модуль стандартов Модуль — это плагин в `plugins/std-<slug>/`. Один модуль = один стек или фреймворк. Дробить мельче не нужно: внутри модуля разделение идёт через `paths:`. ## Перед началом задай один вопрос **Что из этого нельзя проверить машиной?** Если правило проверяется линтером, типизатором или тестом — оно не должно попадать в текст. Текст — это просьба, конфиг линтера — гарантия. Модуль, состоящий только из прозы, — плохой модуль. ## Шаги ### 1. Скопируй скелет ```bash cp -r templates/module plugins/std-<slug> ``` ### 2. Заполни `.claude-plugin/plugin.json` Имя обязательно совпадает с именем директории. `version` ставь явно: без него каждый коммит считается новой версией, и пользователи получают обновления непредсказуемо. ### 3. Напиши правила в `rules/` Один файл — одна тема. Обязательный frontmatter: ```yaml --- paths: ["app/Http/**/*.php"] # без этого правило грузится ВСЕГДА owner: "@backend" # кто отвечает за содержимое enforcement: lint # lint | hook | test | review | prose enforcement_ref: # обязателен для lint, hook и test - configs/eslint.config.js # файл проверяется на существование since: "2026-07-28" --- ``` Поле `enforcement` — главное. Оно заставляет ответить, чем правило подкреплено. Значение `prose` допустимо только для того, что машина проверить не в состоянии: причины архитектурных решений, договорённости, границы ответственности. Всё остальное с `prose` — кандидат на пере