ai-dev-workflow

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.)