| name | ai-dev-workflow |
| description | Методологія сольної AI-розробки: один білдер веде проєкт за допомогою кількох AI як команди. Хто з AI за що (Claude=код+архітектура; інші=альтернативи, Google-екосистема, документація, тренди), готові промпт-шаблони для інших AI, захист ідеї при роботі з публічними AI (кодові назви, не давати одному AI весь контекст, ідея локально, приватний репо до релізу), 6-фазний план від ідеї до релізу, чек-лист старту, ефективна робота з Claude. ALWAYS use when: планування фаз розробки, розподіл задач між кількома AI, як делегувати різним AI, конфіденційність/захист ідеї при роботі з AI, промпти для ChatGPT/Gemini/NotebookLM/Grok, з чого почати проєкт, кодова назва, dev workflow. Also triggers for: який AI для якої задачі, multi-AI development, project kickoff, idea confidentiality, code name. DO NOT use for: runtime-маршрутизація провайдерів у застосунку (multi-provider-ai-orchestration), упаковка APK/PWA (pwa-to-android-app), створення скілів (skill-creation-guide), ведення/закриття експерименту (experiment). |
| license | Proprietary |
| metadata | {"version":"1.4.0","author":"Melania (Master Administrator)","category":"workflow","created":"2026-06-03T00:00:00.000Z","last_updated":"2026-07-26T00:00:00.000Z"} |
AI Dev Workflow — v1.4.0
Напрацьовано з майстер-плану «APK з нуля». Як один білдер (вайбкодер) веде проєкт за допомогою кількох AI як команди: розподіл ролей, захист ідеї, готові промпти, фази, чек-лист.
Українською-перша: пояснення й приклади — українською за замовчуванням; код і технічні ідентифікатори — англійською. Перемикання мови лише слідом за користувачем.
Аудиторія — вайбкодер, не професійний програміст: фахові терміни роз'яснювати коротко в дужках при першому вживанні.
🛡️ Протокол Збереження Перед Оновленням (ОБОВ'ЯЗКОВО)
Обов'язковий перед БУДЬ-ЯКОЮ зміною цього скіла. Канонічне джерело (не дублювати тут): melania — секції «🛡️ Протокол Збереження Перед Оновленням» + «Update Workflow» + «Core Rule 10 — Re-Read Before Update».
Стисло: re-read диску → порівняти версії (диск новіший → диск база) → integrity-diff → validation-mesh → safety-compliance-gate (перед пакуванням/публікацією) → backup/snapshot → merge-not-replace → bump+CHANGELOG → показати diff і чекати явного схвалення MA (Закон II).
Core Rule
Один білдер + кілька AI = команда. Признач кожному AI його сильну роль, рухайся фазами від ідеї до релізу, і захищай ідею за замовчуванням (кодова назва, ніякого УТП у публічні AI). Claude — головний по коду й архітектурі; решта AI — допоміжні за спеціалізацією. Це методологія процесу розробки, не код усередині застосунку.
Critical Facts
- [C] Клієнтський код завжди видимий. Будь-який код, що виконується в браузері чи на пристрої користувача, можна переглянути — реальний секрет має лежати на сервері, а не в клієнтській частині.
- [C] Мініфікація не приховує код. Стиснення (мініфікація) коду ускладнює його читання людиною, але не є способом сховати логіку від того, хто хоче її прочитати.
- [C] Знання моделі має дату відсічення (cutoff) і може застаріти. Тому інформація про поточний стан зовнішніх рішень/SOTA — гіпотеза до перевірки вебом, а не факт, на який можна покладатися без звірки.
Pattern 1 — Захист ідеї (opsec при роботі з AI)
«opsec» = операційна безпека: правила, щоб не злити цінне під час роботи.
Захищай ідею незалежно від політики приватності будь-якого AI — це оборона за замовчуванням, а не довіра:
- Кодова назва. Внутрішня назва проєкту (напр.
ProjectAlpha) у ВСІХ запитах до AI замість справжньої. УТП (унікальну торгову перевагу — те, що відрізняє продукт) не розкривати.
- Розбивай контекст. Не давай ОДНОМУ AI повну картину. Технічні задачі — одному, архітектуру — іншому, UX-ідеї — третьому. Жоден не бачить усе.
- Ідея — локально.
idea.md і бізнес-план тримати тільки на пристрої або в зашифрованому сховищі, не вставляти цілком у чат.
- Приватний репозиторій. (Репозиторій / «репо» — місце, де зберігається код, напр. на GitHub.) Тільки приватний до релізу. Ніколи не публікувати код наперед.
- Чесно про код клієнта. Будь-який код, що виконується в браузері/на пристрої, видно. Реальний секрет = на сервері, не в клієнті. Мініфікація (стиснення коду) ускладнює читання, але не приховує.
Pattern 2 — Розподіл задач між AI (хто за що)
Дефолтна розкладка ролей (евристика, не догма — можливості моделей змінюються; актуальні специфіки моделей див. у multi-provider-ai-orchestration):
| AI | Роль | Сильні задачі |
|---|
| Claude | Головний розробник | Архітектура, увесь код, debug (пошук помилок), рефакторинг (переписування для чистоти), типи, code review, документація |
| ChatGPT | Технічний консультант | Альтернативні рішення, питання по API, regex (шаблони пошуку тексту), SQL-запити, bash-скрипти |
| Gemini | Google-екосистема | Firebase (бекенд від Google), Google Maps, Play Store опис, Google Analytics |
| NotebookLM | База знань | Аналіз документації, вивчення бібліотек, нотатки, аналіз конкурентів |
| Grok | Поточні новини | Актуальні тренди, нові бібліотеки, спільнота X/Twitter, порівняння підходів |
Принцип: одну задачу — найсильнішому виконавцю; не розпорошувати контекст (також підсилює Pattern 1).
Pattern 3 — Готові промпт-шаблони для інших AI
Заміняй [У ДУЖКАХ] на свої дані. Кодова назва замість справжньої.
ChatGPT — альтернативне рішення:
Я розробляю застосунок (стек: [СТЕК]). Треба реалізувати [ФУНКЦІЯ].
Мій поточний підхід: [ОПИС]. Які є альтернативи? Порівняй по:
1) складність 2) продуктивність 3) підтримка. Без повного коду — тільки порівняння + рекомендація.
Gemini — Firebase / Google:
У мене [СТЕК] проєкт. Треба підключити Firebase для: [аутентифікація / база / сховище].
Покажи тільки конфіги та import-рядки. Версія: [ВЕРСІЯ]. Без пояснень — тільки код.
NotebookLM — документація:
Завантаж як джерела: [URL-и документації]. Питання: [КОНКРЕТНЕ ПИТАННЯ].
Дай відповідь з посиланнями на конкретні розділи.
Grok — ринок:
Знайди свіжі пости про [КАТЕГОРІЯ ДОДАТКУ, без назви]. На що скаржаться користувачі
існуючих рішень? Які функції найбільше просять? Аудиторія: [АУДИТОРІЯ].
Pattern 4 — 6-фазний план (ідея → реліз)
| Фаза | Задача | AI / інструменти | Орієнтовно |
|---|
| 1 · Планування | Ідея, функції, аудиторія, список екранів, чернетки екранів | Claude, NotebookLM | 1-2 дні |
| 2 · Налаштування | Середовище, проєкт, приватний репо, конфіг збірки | за стеком | ~1 день |
| 3 · UI/UX | Дизайн-система (кольори, шрифти), базові компоненти, навігація | Claude, ChatGPT | 3-7 днів |
| 4 · Логіка | Бекенд, бізнес-логіка, API, стан застосунку | Claude, Gemini | 7-14 днів |
| 5 · Тестування | Тестова збірка, встановлення, виправлення багів | Claude (debug) | 3-5 днів |
| 6 · Реліз | Опис у сторі, фінальна збірка, публікація | Claude | 2-3 дні |
Терміни — орієнтир для одного білдера; коригувати під реальність.
Spec-first — спершу домовся, потім будуй
Вихід Фази 1 — не просто список, а компактний spec.md: мета, MVP-функції, критерії «готово», екрани. Фази 3–6 реалізують проти spec, не навпаки. Spec правиться першим, код — після: змінити напрям на папері дешевше, ніж у коді. (Узгоджено зі спец-підходом скілів — skill-creation-guide: spec → evals → skill.)
Звір поточний SOTA (Фаза 1): якщо будуєш щось, що конкурує із зовнішніми рішеннями — зроби короткий веб-скан актуального стану. Знання моделі = гіпотеза до перевірки (можливе застарівання після cutoff), не факт.
Pattern 5 — Ефективна робота з Claude
- Повний контекст. Завжди вказуй стек, версію, структуру проєкту (або підвантаж
CLAUDE.md).
- Цілий файл, не шматок. Вставляй повний вміст файлу — Claude бачить увесь контекст.
- Точні помилки. Вставляй повний текст помилки (stacktrace — повний слід помилки), не переказуй.
- Питай «чому». «Поясни, чому саме цей підхід» — навчання разом із результатом.
Чек-лист старту (перед першим рядком коду)
Планування: □ кодова назва · □ ідея записана локально · □ список екранів · □ обраний стек · □ обраний бекенд · □ чернетки екранів (хоч від руки) · □ MVP-функції (мінімум життєздатного продукту — найменший корисний набір)
Технічне: □ середовище розробки · □ приватний репозиторій · □ доступ до репо налаштовано · □ створено проєкт · □ перша тестова збірка пройшла
Behavior
| Ситуація | ✓ Дія | ✗ Ніколи |
|---|
| Користувач планує проєкт | дати 6-фазний план + чек-лист старту | одразу кидатись у код без плану |
| «Який AI для чого» | таблиця ролей (Pattern 2), Claude=код | сказати «будь-який підійде» |
| Захист ідеї при роботі з AI | кодова назва + розбити контекст + ідея локально | радити «просто довіряй політиці приватності» |
| Просять промпт для іншого AI | дати шаблон (Pattern 3) з плейсхолдерами | відмовити бо «це інший AI» |
| Питання про runtime-перемикання провайдерів у застосунку | передати в multi-provider-ai-orchestration | реалізовувати тут |
| Питання про збірку APK/PWA | передати в pwa-to-android-app | дублювати інструкції упаковки |
| Термін «фаховий» уперше | коротко роз'яснити в дужках | сипати жаргоном без пояснень |
Coordinates with (приклади, не закритий список)
Партнери виявляються динамічно (через semantic-router); перелік нижче — орієнтовний:
pwa-to-android-app — упаковка та збірка APK/PWA (Фаза 2, 5, 6)multi-provider-ai-orchestration — AI усередині застосунку (runtime), не процес розробкиnotebooklm-connector — Фаза 1: аналіз документації та конкурентівskill-creation-guide / skill-ecosystem-auditor — якщо напрацювання процесу варто закріпити в скілахcontinuation-memory — зберегти стан, якщо сесія > 20 обмінів
Зміни
-
v1.4.0 (2026-07-26) — Секція Critical Facts: фактичні твердження скіла винесено окремо й протеговано [C] за Core Rule 14 (claim-evidence). Лише додавання.
-
v1.3.0 (2026-07-19) — Self-Dev Wave 2 (аудит 2026-07-18): синхрон H1-банера з frontmatter (був v1.0 при version 1.2.1) [#36]; DO NOT-межа з experiment — ведення/закриття експерименту за методологією лабораторії поза скоупом [#39]. Документація/тригери; тіло методології незмінне. Рев'ю Codex PR #29: description ужато ≤1024 симв. (packaging-ліміт).
-
v1.2.1 (2026-06-15) — DRY: «Протокол Збереження» → тонкий міст на канон у melania (де-дублювання + усунення 8-варіантного дрейфу). Поведінка незмінна — гейт той самий, джерело єдине.
-
v1.1.0 (2026-06-13) — A3: spec-first (Фаза 1 → spec.md, фази 3–6 реалізують проти spec). (Реструктуризація CORE+nodes, Фаза A.)
-
v1.0.0 (2026-06-03) — початкова версія. Напрацьовано з майстер-плану «APK з нуля»: захист ідеї (opsec), розподіл задач між AI, промпт-шаблони, 6-фазний план, чек-лист старту, ефективна робота з Claude. Винесено окремим скілом (Decision Gate: не лягає в pwa-to-android-app — упаковка, ані в multi-provider-ai-orchestration — runtime).
-
v1.2.0 (2026-06-14) — P-06: Фаза 1 — звір поточний SOTA вебом; знання моделі = гіпотеза до перевірки. (SKILL-AUDIT-LEDGER, harvest RLM Harness.)
