feat: добавить skill для SLM Design
- добавлена сборка self-contained skill для Claude Code и opencode - добавлен install-ready архив skill в public/slm-design/skill - обновлена карточка SLM Design с меню действий открыть/скачать - добавлен static fallback главной страницы из общего конфига - подключены Mantine Menu и Phosphor Icons для действий карточки
This commit is contained in:
98
projects/slm-design/skill/slm-design.skill.md
Normal file
98
projects/slm-design/skill/slm-design.skill.md
Normal file
@@ -0,0 +1,98 @@
|
||||
# SLM Design Skill
|
||||
|
||||
SLM Design — новая архитектура. Не заменяй её правилами Feature-Sliced Design, Atomic Design, Clean Architecture или другими привычными схемами. Если в проекте нет локальной документации SLM, считай этот файл единственным источником правды.
|
||||
|
||||
## Определение Контекста
|
||||
|
||||
Перед применением правил убедись, что проект использует SLM Design.
|
||||
|
||||
1. Проверь характерные слои SLM. Сильные сигналы: одновременное наличие `src/screens/` и `src/widgets/` (комбинация специфична именно для SLM — в FSD это `pages/`, в Atomic и Clean таких слоёв нет); файлы `*.factory.ts` в business-модулях с `index.ts`, экспортирующим только фабрику и type-only. Дополнительные сигналы: `src/ui/`, `src/shared/`, `src/layouts/` как слои. В монорепо проверяй то же внутри `apps/{app}/src/`.
|
||||
ВАЖНО: отсутствие `src/business/` НЕ означает, что проект не на SLM. В маленьких или ранних проектах бизнес-доменов может ещё не быть.
|
||||
2. Проверь, что business-модули (если они есть) имеют `*.factory.ts` в корне и `index.ts` экспортирует только фабрику и type-only экспорты.
|
||||
3. Если видишь признаки другой архитектуры — `features/`, `entities/`, `pages/` (FSD), `atoms/`, `molecules/` (Atomic), `domain/`, `useCases/` (Clean) — это НЕ SLM. Не применяй правила этого skill.
|
||||
4. Если структура неоднозначна или проект новый — спроси пользователя, какая архитектура используется, прежде чем применять правила.
|
||||
5. Если пользователь работает в legacy-коде без SLM и НЕ просит миграцию — не предлагай рефакторинг по SLM. Соблюдай существующие паттерны кода.
|
||||
## Порядок Работы
|
||||
|
||||
1. Найди границу приложения: `src/` или `apps/{app}/src`.
|
||||
2. Определи ответственность изменения: запуск приложения, layout, screen, widget, business-domain, infra-service, UI-kit или shared resource.
|
||||
3. Размещай код на самом низком подходящем уровне и поднимай выше только при реальной потребности переиспользования.
|
||||
4. Проверяй, является сущность модулем или компонентом. Если сущность получает данные, владеет сценарием, композирует зависимости или имеет внутреннюю архитектуру — это модуль, а не компонент в `ui/`.
|
||||
5. Все внешние импорты между модулями делай только через публичный API (`index.ts`). Deep imports запрещены.
|
||||
6. Для `business` runtime-зависимостей между доменами используй фабрики. Не импортируй runtime-код одного business-домена напрямую в другой.
|
||||
7. Перед завершением проверь слой, модульную границу, сегменты, публичный API, направление импортов и monorepo-ограничения.
|
||||
|
||||
## Жёсткие Правила
|
||||
|
||||
- Направление зависимостей внутри приложения: `app → [ layouts | screens ] → widgets → business → infra → ui → shared`.
|
||||
- `layouts` и `screens` параллельны и не импортируют друг друга.
|
||||
- Модули одного слоя в группе «Композиция» изолированы друг от друга.
|
||||
- Runtime-импорты между `business`-доменами запрещены. Cross-domain runtime-зависимости передаются только через аргументы фабрики.
|
||||
- `import type` в группе «Ядро» разрешён в обоих направлениях, потому что не создаёт runtime-зависимость.
|
||||
- Каждый внешний импорт модуля идёт через `index.ts` модуля или публичный API пакета.
|
||||
- `business/{name}/index.ts` экспортирует только фабрику и type-only экспорты.
|
||||
- Компонент в `ui/` родительского модуля не импортирует проектный код за пределами родительского модуля, не получает данные, не вызывает сценарные хуки и не содержит бизнес-логику.
|
||||
- `parts/` содержит только вложенные модули, не произвольные `.tsx`, стили или хуки.
|
||||
- `shared/` не знает о продукте, бизнес-доменах, UI-kit сущностях и runtime-состоянии.
|
||||
- В monorepo SLM применяется внутри каждого `apps/{app}/src`.
|
||||
- В `packages/*` можно выносить только общие `ui`, `infra` и `shared`. `business`, `app`, `layouts`, `screens`, `widgets` не выносятся в пакеты.
|
||||
|
||||
## Выбор Места Для Кода
|
||||
|
||||
- Код нужен одной странице или layout: оставь его внутри `screens/{name}/parts/` или `layouts/{name}/parts/`.
|
||||
- Абстрактный UI без бизнес-логики и сценариев: `ui/{name}/`.
|
||||
- Составной блок интерфейса без принадлежности конкретному домену, используемый в нескольких screens/layouts: `widgets/{name}/`.
|
||||
- Код принадлежит бизнес-домену: `business/{domain}/`, даже если переиспользуется.
|
||||
- Технический сервис приложения: `infra/{service}/`.
|
||||
- Чистая утилита или фундаментальный ресурс без знания о продукте: `shared/`.
|
||||
- В monorepo общий UI/infra/shared код, потенциально нужный двум и более frontend-приложениям: `packages/ui/*`, `packages/infra/*`, `packages/shared`.
|
||||
|
||||
## Шаблон Business-Модуля
|
||||
|
||||
```text
|
||||
business/{name}/
|
||||
├── {name}.factory.ts
|
||||
├── hooks/
|
||||
├── services/
|
||||
├── mappers/
|
||||
├── types/
|
||||
│ ├── {name}-api.type.ts
|
||||
│ ├── {name}-deps.type.ts
|
||||
│ └── {name}-factory.type.ts
|
||||
├── ui/
|
||||
└── index.ts
|
||||
```
|
||||
|
||||
Фабрика лежит в корне business-модуля и возвращает публичный runtime API. Если модулю нужны другие домены, принимай зависимости аргументом фабрики доменными именами.
|
||||
|
||||
```ts
|
||||
export { customerFactory } from './customer.factory'
|
||||
|
||||
export type { Customer } from './types/customer.type'
|
||||
export type { CustomerApi } from './types/customer-api.type'
|
||||
export type { CustomerDeps } from './types/customer-deps.type'
|
||||
export type { CustomerFactory } from './types/customer-factory.type'
|
||||
```
|
||||
|
||||
## Чеклист Ревью
|
||||
|
||||
Проверяй архитектуру в таком порядке:
|
||||
|
||||
1. Правильно ли выбран слой по ответственности?
|
||||
2. Не вынесен ли код выше, чем нужно для текущего использования?
|
||||
3. Не лежит ли модульная сущность в `ui/` как компонент?
|
||||
4. Не содержит ли компонент в `ui/` данные, сценарии, внешние импорты или вложенную архитектуру?
|
||||
5. Есть ли у каждого модуля публичный API и нет ли deep imports?
|
||||
6. Соблюдено ли направление зависимостей?
|
||||
7. Нет ли runtime-импортов между business-доменами?
|
||||
8. Экспортирует ли `business/index.ts` только фабрику и типы?
|
||||
9. Не попали ли продуктовые типы, конфиги или стили в `shared/`?
|
||||
10. В monorepo не вынесены ли `business`, `screens`, `layouts` или `widgets` в `packages/*`?
|
||||
|
||||
При ревью сначала перечисляй нарушения с файлами и причиной. Затем предлагай минимальное исправление.
|
||||
|
||||
## Каноническая Спецификация
|
||||
|
||||
Ниже находится полная спецификация SLM Design из канонов проекта. Не сокращай и не переинтерпретируй эти правила.
|
||||
|
||||
<!-- SLM_CANON_CONTENT -->
|
||||
Reference in New Issue
Block a user