@michaelbel/cuckcoder-mcp 1.6.11

package/assets/skills/create-feature-bottom-sheet/SKILL.md

@@ -0,0 +1,300 @@
+---
+name: create-feature-bottom-sheet
+description: >-
+  Use when пользователь просит создать Compose bottom sheet, modal sheet фичу или пакет `_sheet`,
+  или говорит "create a bottom sheet", "add a modal sheet", "new ModalBottomSheet". Покрывает
+  раскладку пакета `{feature}_sheet`, `SharedModalBottomSheet`, `rememberModalBottomSheetState` и
+  его preview. Не используй для диалога с простыми кнопками confirm/dismiss; используй вместо этого
+  [create-feature-alert-dialog](../create-feature-alert-dialog/SKILL.md). Не используй для полного
+  навигируемого экрана; используй вместо этого
+  [create-feature-scaffold-screen](../create-feature-scaffold-screen/SKILL.md).
+metadata:
+  author: michaelbel
+---
+
+# Новый Bottom Sheet
+
+Требует зависимость `androidx.compose.material3:material3`.
+
+Создаёт Compose bottom sheet проекта. Замени `{Feature}` на назначение sheet, `{feature}` на имя в
+lower camel case, а `{package}` на целевой пакет.
+
+## Фаза 1: создать папку фичи
+
+Создай папку `features/{feature}_sheet` — постфикс `_sheet` обязателен, даже если фича сама по
+себе не заканчивается на «шит».
+
+## Фаза 2: Intent и Model
+
+Внутри `features/{feature}_sheet` создай папку `intent`. Папку `model` создавай только когда sheet
+нужны отображаемые данные; если данных нет, не создавай ни папку, ни файл Model.
+
+Файлы:
+- `features/{feature}_sheet/{Feature}BottomSheet.kt`
+- `features/{feature}_sheet/intent/{Feature}SheetIntent.kt`
+- optional `features/{feature}_sheet/model/{Feature}SheetModel.kt`
+
+### {Feature}SheetIntent.kt
+
+```kotlin
+package {package}.features.{feature}_sheet.intent
+
+import {package}.shared.mvi.Intent
+
+sealed interface {Feature}SheetIntent: Intent {
+    data object DismissClick: {Feature}SheetIntent
+}
+```
+
+Правила:
+- `DismissClick` присутствует всегда и всегда идёт первым интентом в `sealed interface`.
+- Для остальных действий (клик по элементу, primary/secondary action и т. д.) добавляй свои
+  `data object` / `data class` записи; `data object` всегда идёт перед `data class`.
+
+### {Feature}SheetModel.kt (только если есть данные)
+
+```kotlin
+package {package}.features.{feature}_sheet.model
+
+import {package}.shared.mvi.Model
+
+data class {Feature}SheetModel(
+    val showPrimaryAction: Boolean = false
+): Model
+```
+
+## {Feature}BottomSheet.kt
+
+```kotlin
+package {package}
+
+// Добавь все необходимые импорты
+
+@Composable
+fun {Feature}BottomSheet(
+    state: {Feature}SheetModel,
+    dispatch: ({Feature}SheetIntent) -> Unit
+) {
+    SharedModalBottomSheet(
+        onDismissRequest = { dispatch({Feature}SheetIntent.DismissClick) }
+    ) {
+        SharedLazyColumn(
+            modifier = Modifier.fillMaxWidth(),
+            contentPadding = PaddingValues(
+                start = 16.dp,
+                top = 44.dp,
+                end = 16.dp,
+                bottom = 16.dp
+            ),
+            verticalArrangement = Arrangement.spacedBy(16.dp),
+            horizontalAlignment = Alignment.CenterHorizontally
+        ) {
+            item {
+                {Feature}Card(
+                    state = {Feature}CardState(
+                        model = state.item,
+                        onClick = { dispatch({Feature}SheetIntent.ItemClick) }
+                    )
+                )
+            }
+            if (state.showSecondaryAction) {
+                item {
+                    {Feature}SecondaryButton(
+                        onClick = { dispatch({Feature}SheetIntent.SecondaryActionClick) }
+                    )
+                }
+            }
+            if (state.showPrimaryAction) {
+                item {
+                    Button(
+                        onClick = { dispatch({Feature}SheetIntent.PrimaryActionClick) },
+                        modifier = Modifier
+                            .fillMaxWidth()
+                            .height(56.dp),
+                        shape = RoundedCornerShape(8.dp)
+                    ) {
+                        SharedFixedText(
+                            text = stringResource(AppStrings.{Feature}PrimaryAction),
+                            style = MaterialTheme.typography.medium16.copy(
+                                textAlign = TextAlign.Center
+                            )
+                        )
+                    }
+                }
+            }
+        }
+    }
+}
+
+@PreviewWrapper(ThemeWrapper::class)
+@Preview
+@Composable
+private fun {Feature}BottomSheetPreview(
+    @PreviewParameter({Feature}SheetModelPreviewParameterProvider::class) state: {Feature}SheetModel
+) {
+    Box(
+        modifier = Modifier.fillMaxSize()
+    ) {
+        {Feature}BottomSheet(
+            state = state,
+            dispatch = {}
+        )
+    }
+}
+
+private class {Feature}SheetModelPreviewParameterProvider: PreviewParameterProvider<{Feature}SheetModel> {
+    override val values: Sequence<{Feature}SheetModel>
+        get() {
+            val item = {Feature}ItemModel(
+                id = "sample-id",
+                title = "Sample item",
+                subtitle = "Sample details"
+            )
+
+            return sequenceOf(
+                {Feature}SheetModel(
+                    item = item,
+                    showPrimaryAction = true,
+                    showSecondaryAction = false
+                ),
+                {Feature}SheetModel(
+                    item = item,
+                    showPrimaryAction = false,
+                    showSecondaryAction = true
+                )
+            )
+        }
+}
+```
+
+Правила:
+- Используй обёртку `SharedModalBottomSheet`, а не сырой `ModalBottomSheet`.
+- Не задавай `sheetState` вручную в фича-коде — `SharedModalBottomSheet` уже использует
+  `rememberModalBottomSheetState(skipPartiallyExpanded = true)` по умолчанию.
+- Не задавай `containerColor`, `sheetGesturesEnabled` или `dragHandle` — у `SharedModalBottomSheet`
+  уже есть нужные умолчания (`dragHandle` всегда рисует `SharedDragHandle()`).
+- Делай preview composable, который сам рендерит bottom sheet, а не отдельный приватный composable
+  только с содержимым.
+- Оборачивай preview bottom sheet в `Box(modifier = Modifier.fillMaxSize())`; иначе preview может
+  не отрендериться.
+- Используй анонимизированные тестовые данные для preview, такие как `sample-id`, `Sample item` и
+  `Sample details`.
+- Не добавляй пустые строки между соседними блоками `item {}` внутри `SharedLazyColumn`.
+- Не добавляй `Spacer` без визуального назначения; используй `Spacer` только в конце списка, чтобы
+  создать отступ под последним элементом.
+
+## Фаза 3: вызов sheet с экрана
+
+Sheet не хранит собственный ViewModel — видимостью и данными управляет экран, который его
+открывает.
+
+### 1. Флаг видимости в Model экрана
+
+В `Model` вызывающего экрана добавь `Boolean`-поле `is{Feature}SheetVisible` — `is`, имя sheet
+(с постфиксом `Sheet`), затем `Visible`:
+
+```kotlin
+data class {Screen}Model(
+    val is{Feature}SheetVisible: Boolean = false
+): Model
+```
+
+### 2. Показ sheet
+
+Там, где решаешь открыть sheet, диспатчи `reduce`, выставляющий флаг в `true`:
+
+```kotlin
+reduce { it.copy(is{Feature}SheetVisible = true) }
+```
+
+### 3. Обработка intent'ов sheet в ViewModel экрана
+
+Добавь в `{Screen}Intent` экрана один case `On{Feature}SheetIntent`, оборачивающий весь
+`{Feature}SheetIntent` целиком — отдельный case на каждый intent sheet не создавай:
+
+```kotlin
+sealed interface {Screen}Intent: Intent {
+    data class On{Feature}SheetIntent(val intent: {Feature}SheetIntent): {Screen}Intent
+}
+```
+
+Разбирай `intent.intent` вложенным `when` внутри `dispatch` ViewModel экрана:
+
+```kotlin
+override fun dispatch(intent: {Screen}Intent) {
+    when (intent) {
+        is {Screen}Intent.On{Feature}SheetIntent -> {
+            when (intent.intent) {
+                is {Feature}SheetIntent.DismissClick -> {
+                    reduce { it.copy(is{Feature}SheetVisible = false) }
+                }
+            }
+        }
+    }
+}
+```
+
+### 4. Отрисовка
+
+Рендери sheet внутри первой, публичной функции экрана (`{Screen}Screen`, не
+`{Screen}ScreenContent`), сразу после вызова `{Screen}ScreenContent(...)`. В `dispatch`-лямбде sheet
+просто пробрасывай весь intent в `On{Feature}SheetIntent`, не разбирая его case'ы в самом
+composable:
+
+```kotlin
+@Composable
+fun {Screen}Screen(
+    viewModel: {Screen}ViewModel = hiltViewModel()
+) {
+    val state by viewModel.stateFlow.collectAsStateWithLifecycle()
+
+    {Screen}ScreenContent(
+        state = state,
+        dispatch = viewModel::dispatch
+    )
+
+    if (state.is{Feature}SheetVisible) {
+        {Feature}BottomSheet(
+            dispatch = { intent -> viewModel.dispatch({Screen}Intent.On{Feature}SheetIntent(intent)) }
+        )
+    }
+}
+```
+
+### Если у sheet есть Model
+
+Когда sheet принимает `state`, не храни отдельную копию его Model в экране — вычисляй её свойством
+`get()` из уже существующих данных экрана. Имя свойства оканчивается на `State`, а не на `Model`
+(сам тип остаётся `{Feature}SheetModel`):
+
+```kotlin
+data class {Screen}Model(
+    val {feature}Item: {Feature}Item = {Feature}Item.Empty,
+    val is{Feature}SheetVisible: Boolean = false
+): Model {
+    val {feature}SheetState: {Feature}SheetModel
+        get() = {Feature}SheetModel(
+            item = {feature}Item
+        )
+}
+```
+
+```kotlin
+if (state.is{Feature}SheetVisible) {
+    {Feature}BottomSheet(
+        state = state.{feature}SheetState,
+        dispatch = { intent -> viewModel.dispatch({Screen}Intent.On{Feature}SheetIntent(intent)) }
+    )
+}
+```
+
+Правила:
+- Sheet не хранит собственный ViewModel; видимостью управляет `Boolean`-поле
+  `is{Feature}SheetVisible` в `Model` вызывающего экрана.
+- Экран оборачивает весь `{Feature}SheetIntent` в один case `On{Feature}SheetIntent(val intent:
+  {Feature}SheetIntent)` своего `{Screen}Intent`; отдельных case'ов на каждый intent sheet не
+  создавай — разбирай их вложенным `when` внутри `dispatch` ViewModel.
+- Рендери sheet в первой, публичной функции экрана, сразу после вызова
+  `{Screen}ScreenContent(...)`.
+- Если sheet нужна Model, вычисляй её свойством `get()` в `Model` экрана из уже существующих
+  данных — не храни отдельную копию; имя свойства оканчивается на `State`, а не на `Model`.

package/assets/skills/create-feature-scaffold-screen/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: create-feature-scaffold-screen
+description: >-
+  Use when пользователь просит создать новый Android Compose-экран или MVI-фичу с
+  Screen/ViewModel/Intent/Model/Event и опциональным route. Поддерживает static, network-only,
+  Room-backed collect/load, form и paginated экраны. Не используй для отдельного переиспользуемого
+  компонента, alert dialog или bottom sheet; используй create-shared-component,
+  create-feature-alert-dialog или create-feature-bottom-sheet. Не используй только для data/domain
+  слоя без экрана.
+metadata:
+  author: michaelbel
+---
+
+# Новый MVI-экран
+
+Создай экран в `features/{feature}`, где `{feature}` — snake_case, `{Feature}` — PascalCase, а
+`{package}` — пакет целевого проекта.
+
+Обычный набор файлов:
+
+- `{Feature}Screen.kt`
+- `{Feature}ViewModel.kt`
+- `model/{Feature}Model.kt`
+- `intent/{Feature}Intent.kt`
+- `event/{Feature}Event.kt`, только если нужны одноразовые эффекты
+- `navigation/{Feature}Route.kt`, только если экран участвует в навигации
+
+## Выбери режим
+
+Изучи ближайший аналогичный экран и выбери основной режим. Затем обязательно прочитай только его
+reference. Для гибридного экрана прочитай references только для реально объединяемых режимов.
+
+| Режим                    | Когда выбирать                                                                | Reference                                                   |
+| ------------------------ | ----------------------------------------------------------------------------- | ----------------------------------------------------------- |
+| static                   | Нет загрузки данных; экран отображает заданное состояние и локальные действия | [static-screen.md](references/static-screen.md)             |
+| network-only             | Одноразовый сетевой результат сразу становится состоянием экрана, без Room    | [network-only-screen.md](references/network-only-screen.md) |
+| Room-backed collect/load | Room — источник истины, сеть только обновляет его                             | [room-backed-screen.md](references/room-backed-screen.md)   |
+| form                     | Пользователь редактирует поля и отправляет значения                           | [form-screen.md](references/form-screen.md)                 |
+| paginated                | Экран отображает `PagingData` и load states                                   | [paginated-screen.md](references/paginated-screen.md)       |
+
+Если нужный endpoint, storage, mapper или use case отсутствует, сначала примени соответствующий
+атомарный skill либо `create-data-layer` для составного потока. Экранный skill не создаёт эти слои
+скрыто.
+
+## Общие MVI-инварианты
+
+- Всё изменяемое UI-состояние хранится в `{Feature}Model` и меняется только через
+  `reduce { it.copy(...) }`. Не держи дублирующие mutable-поля во ViewModel или Composable.
+- Исключение для Paging — публичный immutable `Flow<PagingData<T>>`; параметры, влияющие на этот
+  Flow, всё равно хранятся в Model.
+- Каждый intent представляет одно действие пользователя или lifecycle-событие. В sealed interface
+  размещай `data object` перед `data class`.
+- `dispatch` использует исчерпывающий `when` без `else`. Обрабатывай поведение прямо в его ветках;
+  не выноси ветки в приватные handler-функции.
+- Внедряй конкретные `UseCase` / `FlowUseCase`, а не Repository, Interactor или агрегирующий фасад.
+  Одноразовые use case вызывай через `.getOrThrow()` внутри `launch { ... }`; исключения обрабатывай
+  в принятом проектом `catch` ViewModel.
+- События применяй только для одноразовых эффектов: навигации, snackbar, диалога или команды
+  обновить Paging. Постоянные данные в Event не храни.
+- Публичный `{Feature}Screen(viewModel = hiltViewModel())` собирает state через
+  `collectAsStateWithLifecycle()`, наблюдает event flow при его наличии и делегирует UI приватному
+  `{Feature}ScreenContent`.
+- `{Feature}ScreenContent` получает state/data и callback `dispatch`; он не знает о ViewModel.
+  Preview создавай для content через `@PreviewWrapper(ThemeWrapper::class)` и приватный
+  `PreviewParameterProvider`.
+- Применяй `innerPadding` из `Scaffold` через `contentPadding` списка или `Modifier.padding` обычного
+  содержимого. Добавляй file-level opt-in только для реально используемых experimental API.
+
+## Навигация и завершение
+
+При необходимости создай route и зарегистрируй его в существующем navigation graph тем же
+способом, что соседние фичи. Не вводи новую навигационную абстракцию. Проверь loading, content,
+empty и error-состояния, которые действительно принадлежат выбранному режиму, preview-варианты и
+сборку затронутого модуля.

package/assets/skills/create-feature-scaffold-screen/references/form-screen.md

@@ -0,0 +1,20 @@
+# Form screen
+
+Используй этот режим для редактируемых полей, локальной валидации и отправки формы.
+
+## Контракт
+
+- Храни значения полей, ошибки и nullable submit-`Job` в Model; вычисляй `isSubmitting` из
+  активности `Job`. Не делай `remember` источником истины для бизнес-полей.
+- Создай отдельный `data class` intent для изменения каждого логически независимого поля и
+  `data object` для Submit/Retry/Back. Сохрани порядок `data object` перед `data class`.
+- В field-change ветке обновляй Model через `reduce`; очищай только ошибку изменённого поля, если
+  это соответствует UX.
+- Перед submit проверь UI-валидацию, одним `reduce` отобрази ошибки и не вызывай use case при
+  невалидной форме. Domain-валидация остаётся внутри use case/domain слоя.
+- Для двух и более значений передавай вложенный `{UseCase}.Params`, а не `Pair`, `Triple` или map.
+- При submit сохрани запущенный `Job` в Model и сбрось его через `invokeOnCompletion`; состояние
+  кнопки выводи из `isSubmitting`. Успех, требующий навигации/snackbar, отправляй через Event;
+  ожидаемые ошибки обрабатывай в `catch`.
+- Если форма сначала загружает данные, дополнительно используй network-only или Room-backed
+  reference только для этого потока и не смешивай load intent с submit intent.

package/assets/skills/create-feature-scaffold-screen/references/network-only-screen.md

@@ -0,0 +1,20 @@
+# Network-only screen
+
+Используй этот режим, когда результат запроса нужен только текущему экрану и сохранять его в Room
+не требуется.
+
+## Контракт
+
+- Добавь `LoadData` или семантический одноразовый intent, поле результата и nullable `Job` запроса в
+  Model. Вычисляй loading из активности этого `Job`; не храни отдельный изменяемый boolean.
+- В `init` отправляй load intent, если запрос должен выполняться при создании ViewModel. Не дублируй
+  запуск через `LaunchedEffect` в Screen.
+- В ветке intent запусти `Job`, сохрани его в Model, сбрось через `invokeOnCompletion`, вызови use
+  case через `.getOrThrow()` и сохрани успешный результат через `reduce`.
+- Обработай ожидаемые domain/network исключения в `catch` согласно соседним ViewModel. Не храни
+  `Result` в Model.
+- Для retry используй тот же load intent; отдельный intent нужен только если пользовательское
+  действие имеет отличную семантику.
+
+Если сетевой контракт или use case отсутствует, создай их через `create-ktor-endpoint` и
+`create-usecase`. Не добавляй Room только для унификации с другими экранами.

package/assets/skills/create-feature-scaffold-screen/references/paginated-screen.md

@@ -0,0 +1,29 @@
+# Paginated screen
+
+Используй этот режим, когда экран получает `Flow<PagingData<Item>>` и отображает Paging load states.
+
+## ViewModel
+
+- Предпочитай готовый paging use case. Публичный `val {items}PagingFlow` может быть исключением из
+  правила «всё состояние в Model»: это immutable data stream, а не вручную изменяемое UI-состояние.
+- Заверши paging flow через `cachedIn(this)` либо эквивалент, уже принятый базовым ViewModel проекта.
+- Если запрос зависит от фильтра/поиска, храни параметры в Model и строй flow как
+  `stateFlow.map { ... }.distinctUntilChanged().flatMapLatest { pagingUseCase(it) }.cachedIn(this)`.
+  Не держи второй mutable-набор тех же параметров.
+- Состояния toolbar, selection и pull-to-refresh остаются в Model.
+
+## Screen
+
+- В публичном Screen вызови `collectAsLazyPagingItems()` и передай результат в content отдельно от
+  Model.
+- Рендери initial loading, append loading, empty и error по `loadState`, не дублируя их вручную в
+  Model.
+- Retry и refresh начинаются с отдельных Intent. ViewModel отправляет одноразовый Event, публичный
+  Screen обрабатывает его через `ObserveAsEvents` и вызывает `pagingItems.retry()` или
+  `pagingItems.refresh()`; content только диспатчит Intent. После MVI-coordinated refresh отправь
+  завершающий intent для сброса `isRefreshing`, если Model хранит это UI-состояние.
+- Preview создаёт `PagingData.from(items)` через локальный Flow и передаёт полученные
+  `LazyPagingItems` в content.
+
+Этот skill оформляет только экран. `PagingSource`, `Pager`, `RemoteMediator`, DAO и API относятся к
+data/domain-потоку и должны быть готовы заранее либо созданы через `create-paging-flow`.

package/assets/skills/create-feature-scaffold-screen/references/room-backed-screen.md

@@ -0,0 +1,23 @@
+# Room-backed collect/load screen
+
+Используй этот режим, когда Room является источником отображаемых данных, а сеть обновляет Room.
+
+## Контракт
+
+- Создай отдельные intent-ы `Collect{Feature}` и `Load{Feature}`. Не объединяй бесконечное
+  наблюдение и одноразовое обновление в одну ветку.
+- В `init` сначала запускай collect intent, затем load intent, если экран должен автоматически
+  обновиться из сети.
+- В collect-ветке собирай `FlowUseCase` и обновляй Model через `reduce` при каждом значении.
+- Для сетевого обновления храни nullable request-`Job` в Model и вычисляй loading из его активности.
+  В load-ветке сохрани запущенный `Job`, сбрось его через `invokeOnCompletion` и вызови одноразовый
+  use case через `.getOrThrow()`.
+- Не копируй сетевой response в Model: load use case записывает Room, а collect-ветка доставляет
+  новое состояние.
+- Pull-to-refresh повторно отправляет load intent либо отдельный refresh intent только при
+  необходимости собственного UI-состояния.
+- Loading/empty вычисляй из реального состояния фичи; не добавляй `isLoading`, если пустая Room-
+  коллекция уже однозначно задаёт initial state.
+
+Если поток данных отсутствует, собери его через `create-data-layer` с вариантом
+Ktor → mapper → Room. Screen зависит только от готовых `UseCase` / `FlowUseCase`.

package/assets/skills/create-feature-scaffold-screen/references/static-screen.md

@@ -0,0 +1,13 @@
+# Static screen
+
+Используй этот режим, когда экран не загружает и не наблюдает данные.
+
+- Не добавляй искусственные `LoadData`, `isLoading`, use case или `init` только ради шаблона.
+- Model содержит только состояние, которое реально меняется: выбранную вкладку, раскрытую секцию,
+  локальный toggle и подобное.
+- Intent нужен только для реальных действий. Навигационное действие отправляет Event через
+  `send(...)`, а публичный Screen обрабатывает его через `ObserveAsEvents`.
+- Даже если экран полностью детерминирован входными аргументами, создай обязательные `ViewModel`,
+  `Model` и `Intent` по MVI-контракту проекта, но не добавляй в них фиктивную загрузку или состояние.
+- Preview должен показывать содержательные визуальные варианты, а не loading/content, которого у
+  экрана нет.

package/assets/skills/create-guide/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: create-guide
+description: >-
+  Use when пользователь просит создать практический Android-гайд по конкретному API или теме,
+  который публикуется как связанная пара артефактов: рабочий публичный GitHub-репозиторий и
+  объясняющая страница в Notion — например "создай гайд по Navigation3", "сделай гайд про
+  EyeDropper", "напиши гайд по Paging 3 с RemoteMediator". Проводит исследование по первичным
+  источникам, создаёт и проверяет Android-проект из актуального `MyApplication`, пишет или
+  обновляет страницу Notion в data source `POSTS` и публикует оба артефакта. Не используй для
+  обычной фичи, экрана или доработки в уже существующем прикладном проекте — для этого есть
+  `create-feature-scaffold-screen` и другие `create-*` skills. Не используй, если нужен только
+  пустой Android-проект без исследования и без Notion-страницы — для этого есть
+  `create-project-from-template`.
+metadata:
+  author: michaelbel
+---
+
+# Создание гайда: Android-проект + Notion-страница
+
+Каждый гайд состоит из двух связанных артефактов: рабочего Android-проекта в отдельном публичном
+GitHub-репозитории и страницы в Notion, которая объясняет API и ссылается на точные файлы проекта.
+Если страница уже существует, обновляй только её и не переноси между базами. Если страницы нет, по
+умолчанию создавай её в data source `POSTS`, если пользователь явно не указал другое место.
+
+Это единственное место, где живёт эта функциональность. Не создавай и не поддерживай для неё
+отдельный репозиторий или второй skill.
+
+## Обязательный контекст
+
+Перед работой:
+
+1. прочитай [references/guide-defaults.yaml](references/guide-defaults.yaml) — личные дефолты
+   (owner, package prefix, шаблон `MyApplication`, data source Notion `POSTS`);
+2. прочитай [references/existing-guides.yaml](references/existing-guides.yaml) как каталог уже
+   изданных гайдов — не создавай дубликат уже изданной темы, обнови существующий репозиторий и
+   страницу вместо этого;
+3. загрузи актуальные Kotlin/Compose/Git/GitHub правила из `michaelbel/cuckcoder` через MCP
+   `cuckcoder`;
+4. изучи актуальную ветку `michaelbel/MyApplication` перед созданием Android-проекта.
+
+`cuckcoder` определяет общий Kotlin, Compose, Git и GitHub-стиль. Этот skill определяет процесс
+создания гайда. Если правила конфликтуют именно в вопросах исследования, структуры учебного
+проекта, публикации или валидации гайда, применяй этот skill.
+
+## Команда пользователя
+
+Минимальный запрос:
+
+```text
+Создай гайд по Navigation3
+```
+
+Не заставляй пользователя заполнять анкету. Сам выбери значения из
+[references/guide-defaults.yaml](references/guide-defaults.yaml) и зафиксируй их в манифесте.
+Задавай вопрос только тогда, когда неоднозначность заметно меняет тему, объём или публичный
+результат.
+
+## Порядок работы
+
+### 1. Определи границы темы
+
+Зафиксируй прямо в этом контексте:
+
+- основной API;
+- связанные компоненты;
+- статус API: stable, alpha, experimental или platform;
+- минимальную версию Android и библиотек;
+- вопросы, которые должен закрыть гайд;
+- подходящий тип проекта: `catalog`, `scenario` или `single` (см.
+  [references/android-project.md](references/android-project.md)).
+
+### 2. Проведи исследование
+
+Приоритет источников — [references/research.md](references/research.md):
+
+1. официальная документация;
+2. исходный код AndroidX или Android Open Source Project;
+3. официальные samples;
+4. release notes;
+5. issue tracker;
+6. сторонние статьи только как дополнительный контекст.
+
+Для AndroidX зафиксируй точный ref или commit SHA и пути к изученным файлам (правила атрибуции —
+[references/androidx.md](references/androidx.md)). Не считай существующий гайд из
+`existing-guides.yaml` техническим источником истины.
+
+Создай директорию `~/Projects/<Topic>` (PascalCase, sibling к `MyApplication` и остальным гайдам)
+и в ней рабочие файлы:
+
+- `.guidekit/manifest.yaml` — из [templates/guide-manifest.yaml](templates/guide-manifest.yaml);
+- `.guidekit/research.md` — по структуре из
+  [references/research.md](references/research.md#research-report);
+- `.guidekit/implementation-plan.md` — из
+  [templates/implementation-plan.md](templates/implementation-plan.md).
+
+Сначала заполни манифест и план, затем переходи к реализации.
+
+### 3. Реализуй и провалидируй Android-проект
+
+Делегируй фоновому агенту, чтобы Gradle-логи и весь код не засоряли этот контекст:
+
+```
+Agent(subagent_type: "guide-android-builder")
+```
+
+Передай в промпте: полный `.guidekit/manifest.yaml`, `.guidekit/implementation-plan.md` и
+абсолютный путь `~/Projects/<Topic>`. Этот агент сам вызовет skill `create-project-from-template`
+для scaffold из актуального `MyApplication`, реализует сценарии и прогонит обязательные Gradle-
+проверки. Не публикуй и не пиши Notion-страницу, пока этот агент не вернул успешный результат.
+
+### 4. Напиши страницу Notion
+
+Только после успешной валидации Android-проекта делегируй:
+
+```
+Agent(subagent_type: "guide-writer")
+```
+
+Передай в промпте: `.guidekit/manifest.yaml`, путь/URL репозитория, реализованные сценарии и
+краткий summary от `guide-android-builder`. Страница пишется только на основе проверенного
+проекта — примеры кода, имена классов, версии, package и ссылки должны совпадать с репозиторием.
+
+### 5. Проведи перекрёстную проверку
+
+В этом контексте, по [references/validation.md](references/validation.md), сверь:
+
+- все заявленные сценарии реализованы;
+- каждый путь из Notion существует в GitHub;
+- каждый большой фрагмент кода в Notion совпадает с проектом;
+- версии зависимостей совпадают;
+- experimental API помечены;
+- заимствования из AndroidX атрибутированы;
+- ссылки открываются;
+- README и Notion не противоречат друг другу.
+
+### 6. Опубликуй
+
+Порядок публикации — [references/github.md](references/github.md):
+
+1. создай публичный GitHub-репозиторий (`gh repo create`, owner `michaelbel`) и запушь
+   проверенный проект;
+2. обнови существующую страницу Notion или подтверди новую в data source `POSTS`;
+3. добавь в Notion ссылки на репозиторий и точные samples;
+4. при необходимости добавь ссылку на Notion в README;
+5. запусти skill `github-repo-settings` для приведения репозитория к стандартному состоянию
+   (description, topics, disabled Wikis/Issues/Discussions/Projects/PRs, Sponsorships);
+6. повторно проверь публичные URL.
+
+Не останавливайся перед этим шагом для отдельного подтверждения — публикация автономна, но
+финальный отчёт обязан явно перечислить, что было опубликовано.
+
+## Обязательный финальный отчёт
+
+Полный формат — [references/output-contract.md](references/output-contract.md). Кратко: URL
+GitHub-репозитория, URL страницы Notion, тип проекта, версии ключевых библиотек, список
+реализованных сценариев, результаты Gradle-проверок, основные первичные источники, известные
+ограничения. Не пиши «успешно», если проверка не запускалась.
+
+## Запреты
+
+- Не выдумывай API, версии, параметры и поведение.
+- Не вставляй в Notion код, которого нет в проекте.
+- Не копируй AndroidX-код без фиксации происхождения и лицензии.
+- Не добавляй Clean Architecture, DI, многомодульность, Room или сеть без необходимости.
+- Не публикуй черновой проект вместо рабочего примера.
+- Не заменяй выбранный API альтернативной библиотекой без согласования.
+- Не сохраняй токены, Notion IDs, пароли и другие секреты в Git.
+- Не создавай дубликат уже изданной темы из `existing-guides.yaml` — обновляй существующий
+  репозиторий и страницу.