메뉴
Аудит синхронизации перед коммитом изменений фреймворка DartWay — проверяет, что изменения публичного API отражены в example/, template/, toolkit/skills/, docs/ и CHANGELOG. Запускать после завершения работы над кодом пакетов, перед коммитом/PR.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Finishing a dartway task before a commit/PR (DartWay projects): the "definition of done". Audits the diff against the base branch using the dartway-clean-code contract (Flutter + server), checks the affected feature's description for drift (DwFeatureSpec next to the code, doc comments above the CRUD config) and test coverage, then SHOWS suggestions and applies ONLY what was confirmed — it never changes anything silently. Use when a task/feature is done, before committing or opening a PR (Law 6); runs as /dartway-finish.
DartwayTeam strict clean-code rules for ALL Flutter/Dart work (DartWay projects): self-explanatory naming (min 2 words), single responsibility per file (length is a soft signal: >200 lines a nudge, >350 a warning — split by responsibility, not by line count), never pass BuildContext or WidgetRef as params, no _buildXxx() widget-returning methods, no ref.invalidate, no GlobalKey tree lookups, no outer padding/margin inside a widget, no private widget classes in public feature files; plus SOLID, KISS, DRY, YAGNI, Law of Demeter, composition over inheritance, separation of concerns, fail-fast, tell-don't-ask, single source of truth, and tests for complex features / non-trivial bugfixes.
Step-by-step playbook for building a new DartWay feature end-to-end (Flutter + Serverpod): navigation → UI entry point → state/logic via the data layer and Riverpod → backend CRUD configs → models/DB → tests. Feature structure (entry point + widgets + logic), isolation (import the entry point only), domain/app/ui_kit boundaries, the `DwFeatureSpec` feature spec in the feature's own file. Use when adding new functionality, a screen, a flow, or a model.
Server-side Serverpod YAML models in DartWay: .spy.yaml files in lib/src/models/<domain>/, enums in enums/. Base vs Event models (current state vs changes on top of the base — for money/ transactions), field types and nullable discipline (nullable only if the value is genuinely absent in the domain), 1-1/1-N/N-N relations via relation(name=...) (bidirectional — the same name on both sides), onDelete=Cascade, indexes/unique, default=, enum models (serialized: byName). Workflow: edit YAML → serverpod generate → create-migration → DwCrudConfig + registration in crudConfigurations → migrations at startup. Use when creating or changing models, fields, relations, enums and the DB schema.
DartWay Flutter data layer and specials (DartWay projects): data access only through dw.repo — reads are providers under the native ref.watch/read/refresh (dw.repo.model/maybeModel/modelList), writes are dw.repo.saveModel/deleteModel (no repositories, no manual syncing), lists via dwBuildListAsync(loadingItemsCount:), narrowing by query via backendFilter, local filtering you do yourself with .where in the widget, actions from the UI via dw.action (unified error/loading handling), notifications via dw.notify.* (not SnackBar), the profile via ref.watchUserProfile/readUserProfile (getters, not CRUD), sign-out via sessionProvider.notifier.signOut(). Use when working with data, actions, notifications, loading/saving models in Flutter features.
The DartWay/Serverpod server playbook: how to write CRUD configs — DwCrudConfig<T> (one per model), DwGetModelConfig, DwGetModelListConfig (both require accessFilter), DwSaveConfig (allowSave/validateSave/beforeSaveTransaction/afterSaveTransaction/afterSaveTransform/ afterSaveSideEffects), DwDeleteConfig (allowDelete/afterDelete), DwModelWrapper, Event models, the domain(pure)/app(session-aware) boundary. All server logic goes through configs, not through endpoints. Use when adding or changing server logic, permissions, validations, or side effects for a model.
| name | framework-finish |
| description | Аудит синхронизации перед коммитом изменений фреймворка DartWay — проверяет, что изменения публичного API отражены в example/, template/, toolkit/skills/, docs/ и CHANGELOG. Запускать после завершения работы над кодом пакетов, перед коммитом/PR. |
Монорепо DartWay живёт по закону синхронизации (см. корневой CLAUDE.md): публичный API, example, template, скиллы тулкита и доки эволюционируют вместе, в одном PR. Этот скилл ловит рассинхроны по диффу.
git diff <base>...HEAD --stat # + незакоммиченное: git status, git diff
База — master, если не сказано иное. Интересуют изменения в packages/.
Публичный API пакета = его экспорты: файлы, доступные через lib/<package>.dart и lib/src/..., реэкспортируемые наружу. Изменением API считается:
DwCrudConfig, DwSaveConfig, DwAuthConfig, ...);DwCore.init, setupRepository, ...).Чисто внутренние правки (private-код, рефакторинг без смены поведения, zarchive/) — не API.
Для каждого изменения API проверь, отражено ли оно в:
| Зеркало | Что проверять |
|---|---|
example/ | Использует ли example затронутый API; компилируется ли; демонстрирует ли новую возможность |
template/ | Компилируется ли скелет. Это то, что получает каждый новый проект через dartway create; шаблон никто не запускает в буднях, поэтому он гниёт молча, а узнаёшь об этом от чужого человека. Если API затронул auth, роли, навигацию, админку, UI-кит или DwCore.init — шаблон почти наверняка задет |
toolkit/skills/ | grep по старым именам/сигнатурам в toolkit/skills/*/SKILL.md и toolkit/CLAUDE.md — скиллы не должны учить агентов устаревшему API |
docs/ | grep по затронутым понятиям — страницы не должны противоречить коду |
CHANGELOG.md пакета | Есть ли запись под текущую (unreleased) версию |
Шестое зеркало — за пределами репозитория. Изменил packages/dartway_studio_bridge — у контракта две стороны, и вторая живёт в отдельном репозитории (dartway/dartway_studio). Соседства папок больше нет, поэтому проверка держится только на этом пункте:
Если чекаут Studio есть на машине — посмотри и скажи, что там нужно поправить. Если нет — назови это в отчёте явным пунктом: «мост изменился, сторона Studio не проверена». Молча пропускать нельзя: рассинхрон моста не ловится ни компилятором, ни чекером — он проявляется пустой панелью в Studio.
То же касается docs/ и сайта, но мягче: сайт — потребитель, он забирает содержимое сам.
Дополнительно (быстро):
grep -rniE 'tvolkova|tvaity|kerla' toolkit/ → пусто;template/ нет доменных моделей — grep -riE 'club|booking|chat|news|fitness' template/ --include=*.dart --include=*.spy.yaml → пусто. Домен просачивается в шаблон незаметно (скопировали виджет из example — приехал ClubSession);git ls-files template/dartway_starter_server/migrations/ | head -1 → не пусто). Однажды они были в .gitignore, и dartway create месяцами отдавал проект, который не поднимается: локально папка есть, в клоне — нет;zarchive//zarchiv/;Выдай список рассинхронов в формате: <API-изменение> → <зеркало> → <что именно устарело/отсутствует>. Если рассинхронов нет — скажи это одной строкой.
Предложи конкретные правки. Применяй только подтверждённые — кроме тривиальных (CHANGELOG-запись, поправка имени метода в скилле), которые можно применить сразу, перечислив их.