Методологія Gemina
інструкція, як її записати
Ви отримали два файли. Цей файл для вас, його треба прочитати. Він пояснює, як влаштований процес, що зібрати, як налаштувати ШІ, що саме ШІ створить і як передати результат нам. Другий файл, робочий файл для ШІ, призначений для інструмента. Ви завантажуєте його у свій проєкт, і ШІ працює за ним. Ви можете його читати, але жодних дій від вас він не вимагає.
Усі промпти та повідомлення для ШІ в цьому документі залишені англійською навмисно: робочий файл для ШІ англійський, і підсумковий результат також буде англійським.
| Частина 1 | Як це працює |
| Частина 2 | Матеріали, які треба зібрати |
| Частина 3 | Налаштування ШІ: системний промпт і повідомлення |
| Частина 4 | Що створить ШІ |
| Частина 5 | Передача результату |
У вас є методологія. Вона живе у вашому досвіді, у людях, яких ви вели, у питаннях, які ви їм ставите, і в планах, які ви для них будуєте. Застосунку потрібна ця методологія, записана повністю й у фіксованому форматі, бо все, що робить застосунок, походить з неї: кожне питання, яке він ставить, кожен висновок про людину, кожен план, який він будує, кожен огляд, який він проводить. Застосунок не може бути розумнішим за те, що записано.
Ви експерт у змісті. Ніхто не очікує, що ви експерт у форматі. Для цього існують ці два файли та ШІ.
Сьогодні застосунок працює на тимчасовому контенті, який наша команда написала, щоб перевірити сценарії. Це не ваша методологія, і тут ніщо з нього не береться за основу. Якщо правильна відповідь відрізняється від того, що застосунок робить сьогодні, перемагає правильна відповідь: кількість питань, їх групування, тривалість плану, назви понять, усе.
Чотири кроки. Кроки 1 і 4 ваші. Кроки 2 і 3 здебільшого виконує ШІ.
Крок 1. Зберіть матеріали. Частина 2 перелічує, що зібрати, у порядку важливості, і як це підготувати. Сире краще за переписане. Саме цей крок визначає якість усього, що буде далі.
Крок 2. Налаштуйте ШІ й дайте йому прочитати. Створіть проєкт у ChatGPT або Claude за інструкцією з Частини 3: завантажте робочий файл для ШІ та всі свої матеріали, вставте системний промпт в інструкції проєкту, вставте стартове повідомлення в перший чат. ШІ прочитає все і покаже вам карту: на що ваші матеріали вже відповідають, а на що ні.
Крок 3. Відповідайте там, де матеріали мовчать. ШІ ставитиме вам питання, по одному, користуючись питаннями з робочого файлу для ШІ. Відповідайте з досвіду. Коли він запитує, як ви щось вирішуєте, дайте правило, якщо воно у вас є, а якщо немає, розкажіть, як ви думаєте, і наведіть три реальні приклади. Потім він складе результат у форматі з Section 1 робочого файлу для ШІ, перевірить його на реальних кейсах і звірить із чеклістом приймання.
Крок 4. Перегляньте й передайте. Читайте результат так само скептично, як читали б переказ вашої роботи незнайомою людиною. Виправте все, що не є вашою методологією. Потім передайте нам, як описано в Частині 5.
Правило чи судження. Застосунок може вирішувати двома способами. Правило — це те, що розробник може закодувати: якщо людина обрала А в питанні 3 і Б в питанні 7, її головна перешкода — X. Судження — це те, що робить ШІ, читаючи ваші міркування і застосовуючи їх до однієї людини. Правила передбачувані й працюють навіть тоді, коли ШІ вимкнений; судження справляються з нюансами, але «пливуть», якщо міркування не записані. Ми використовуватимемо і те, і те. ШІ наполягатиме на правилі всюди, де робочий файл позначає точку рішення, і прийме описане судження з трьома прикладами там, де правила не існує. Півправила з винятками цілком підходять.
Походження кожного твердження. ШІ дуже добре вміє створювати текст, який читається як готова методологія. Промпт змушує його позначати кожне твердження: воно від вас, з названого матеріалу або це його власна пропозиція. Пропозиція може залишитися лише після того, як ви її підтвердите. Ніколи не приймайте непозначене твердження.
Приклади в робочому файлі для ШІ не ваші. Кожний приклад у його додатках взятий з вигаданої методології для незалежних музикантів. Вони показують форму й глибину гарної відповіді, і нічого більше. Промпт забороняє ШІ адаптувати їх до вашої сфери.
Ми не торкаємося змісту методології. Але ми стежимо, щоб процес не зупинився, у трьох точках:
Між цими точками один канал для питань. Якщо ШІ робить щось, що вас непокоїть, надішліть нам цей фрагмент розмови.
Ви вирішуєте методологію: кожне питання, висновок, правило, напрям фокусу, дію і слово голосу. Ми вирішуємо, як це побудувати. Якщо під час реалізації ми знайдемо прогалину чи суперечність, ми надішлемо вам питання, а не виправлення. Якщо щось у цих файлах не відповідає тому, як ваша методологія працює насправді, скажіть нам, що має змінитися.
Що зібрати перед початком роботи з ШІ, у порядку важливості, і як це підготувати. Якість результату вирішується тут більше, ніж будь-де: ШІ може лише впорядкувати те, що йому дали, і питатиме вас про все, чого йому не дали.
Сире краще за переписане. Безладна нотатка з реальної сесії з реальною людиною варта більше, ніж чистий абзац, написаний цього тижня про те, як методологія працює загалом. Реальні кейси показують, що ви насправді вирішуєте і чому; теорія показує, що ви думаєте, що вирішуєте. Не причісуйте, не стискайте і не перекладайте нічого перед завантаженням. Анонімізуйте імена, де потрібно, а решту залиште як є.
Якщо щось існує лише у вашій голові, запишіть себе на диктофон і зробіть транскрипт. Проговорити кількох реальних людей від початку до кінця зазвичай дає більше придатної методології, ніж писати про методологію загалом.
case-photographer-2025-went-badly.docx, intake-questions-v3.pdf, voice-messages-after-a-missed-week.txt.about-these-materials.txt, з одним рядком про кожен файл: що це, звідколи, наскільки ви йому довіряєте.Записуйте в тиші, мовою, якою думаєте, одна людина або одна тема на запис. Далі отримайте транскрипт одним із цих способів:
Потім прочитайте транскрипт один раз і виправте лише імена та ключові терміни, які транскрибування спотворило. Решту не причісуйте. Збережіть як текстовий файл, названий за змістом, із датою і кейсом, і додайте до папки як будь-який інший матеріал.
Не пишіть його з нуля як документ. Натомість, коли ШІ дійде до цієї частини, скажіть йому, що такого матеріалу немає, і відповідайте на його питання з пам'яті, кейс за кейсом. ШІ побудує матеріал разом із вами. Написане заздалегідь зазвичай виходить теорією; відповіді на питання зазвичай дають те, що ви робите насправді.
Усе, що ви вставляєте в ChatGPT або Claude, і куди саме. Три елементи: системний промпт, який залишається увімкненим упродовж усього проєкту, стартове повідомлення, яке запускає роботу, і кілька коротких повідомлень для наступних сесій. Нічого тут редагувати не треба; копіюйте як є. Копіюйте з онлайн-версії цього документа, де біля кожного блоку є кнопка Copy, а не з PDF: копіювання з PDF розриває кожний рядок, а розірваний промпт збиває ШІ з пантелику. Усі вони англійською, бо робочий файл для ШІ і підсумковий результат англійські.
У ChatGPT
.md, а не його PDF-копію: звичайний текст ШІ читає найкраще), а потім усі свої матеріали. Файл, який ви зараз читаєте, завантажувати не потрібно. Якщо впираєтеся в ліміт кількості файлів, об'єднайте дрібні матеріали в один документ; не залишайте нічого за бортом.У Claude
Працює будь-який із двох інструментів. Claude зазвичай читає довгі файли повністю; ChatGPT шукає всередині них, тому правило 9 системного промпту велить ШІ відкривати розділи цілком. Тримайтеся одного інструмента протягом усього проєкту, щоб він зберігав контекст.
Вставте в поле інструкцій проєкту. Він діє в кожному чаті проєкту.
You are the writing partner of the owner of a career-development methodology for creative professionals. Together you are turning that methodology into a complete written document and spreadsheet that a software team, Spaceberry, will implement as the logic and prompts of an app called Gemina. ROLES The owner is the only authority on the content of the method. You are the authority on the format. The format is defined in the project file "Gemina methodology - AI working file": Section 1 is the deliverable specification, Section 2 the spreadsheet tabs, Section 3 the acceptance checklist, Appendices 1 to 7 the questions you use to draw the method out. Every other project file is the owner's own material. HOW YOU WORK The work runs in four phases, given in the kickoff message: map, interview, draft, verify. Always know which phase and which part you are in, and state it in one line at the top of every reply. Never move to the next phase without the owner's explicit confirmation. When the owner opens a new chat and says "continue", first state where you stopped, then continue. STANDING RULES, FOR EVERY MESSAGE 1. You are an interviewer and an editor, never the author of the method. 2. Never invent methodology content. If the materials and the owner have not said it, ask. Do not fill a gap with typical coaching practice, with what a generic methodology would say, or with what the current Gemina app does. 3. Mark the source of every statement you write: [owner] the owner said it in this project. [source: file name] it comes from a material; name the file. [suggestion] you proposed it and it is not yet confirmed. A [suggestion] stays only if the owner confirms it explicitly; then relabel it [owner]. Never leave a statement unmarked. 4. Ask one question at a time. Before asking, quote what the materials say about it, with the file name, or say plainly that they are silent. 5. Where a question is marked with the decision-point symbol, push for a rule a developer could code. If the owner cannot give one, ask how they decide, what they look at, and for three real examples with the conclusion for each. Record the answer in that order: rule, reasoning, examples. 6. One name per concept: the one in the glossary, Section 1 item A.7. Point out any new word for an existing concept. Add a genuinely new concept to the glossary with the owner's definition and ask whether the app's user ever sees the name. 7. On any contradiction, between materials, between answers, or between a rule and a worked example, stop and show both statements side by side. Do not resolve it yourself. 8. The examples in the appendices are from a made-up methodology for musicians. They show the shape of an answer. Never adapt them to the owner's domain and never let them influence content. 9. Read the AI working file by section, not by search. When a phase needs Section 1, 2 or 3 or an appendix, open that section in full and quote its headings before using it. If you cannot find a section, say so instead of guessing what it contains. 10. Write in English. Keep the owner's wording where it is clear; tighten it where it is not and show what changed. Translate quoted material and show the original for any term that matters. Address the app's user as "you" and describe them as "the person" or "they". 11. If anything in the AI working file does not fit the owner's method, say so and propose the smallest change, marked [suggestion]. Never silently bend the method to the file or the file to the method. 12. End every reply that completes a piece of work with a status block: phase and part; items answered, partly answered, not yet answered; open [suggestion] marks; unresolved contradictions; decide-later items with their owners.
Вставте як перше повідомлення першого чату.
We start now. Work in the four phases below. Finish each and wait for my confirmation before the next. PHASE 1 - READ AND MAP Open the AI working file and read Sections 1 and 2 and Appendices 1 to 7 in full, section by section. Then read every one of my materials completely, starting with about-these-materials.txt. Then, for every numbered item in parts A to G of Section 1, tell me which of my materials already answer it (quote the passage and name the file), which answer it partly, and which do not touch it. Output one table: item, status (covered / partial / missing), evidence. Also list every case where my materials use different names for the same concept, and every place two materials contradict each other. Ask me nothing in this phase. PHASE 2 - INTERVIEW For every partial or missing item, ask me the matching question from the appendices, most important first: all "must" parts before any "should" part, and within a part in the order given. One question per message, with what my materials say quoted before it. Where I say something is not part of the method, record that as the answer. Where I say decide later, record an owner and a date. The phase ends when every item in every "must" part has an answer, a "not part of the method", or a "decide later". PHASE 3 - DRAFT Write the deliverable exactly in the structure of Section 1, one part per message, headings as given, provenance marks on every statement. Produce each spreadsheet tab from Section 2 as a table I can paste, one tab per message, columns as defined. Then write part H by applying the written rules to at least two real people from my materials and one edge case, step by step, using only what is written. Wherever a walk-through needs something that is not written, stop, tell me, and we add it to the right part before continuing. End each example with the list of everything that was added this way. PHASE 4 - VERIFY Run every check in Section 3 against the draft. Report every failure with the part and the line. Fix each one with me. Then produce the final version: no [suggestion] marks, one glossary used everywhere, part I complete, and a one-page summary of what changed since the draft. Begin Phase 1. When the map is ready, show it to me and stop.
Коли починаєте новий чат у проєкті
Continue. First tell me the phase and part where we stopped, the open [suggestion] marks and the unresolved contradictions. Then carry on.
Коли переходите до наступної фази
Phase confirmed. Move to the next phase as described in the kickoff message.
Коли хочете побачити, на якому етапі справи
Show me the current coverage map: every item of Section 1 parts A to G with its status, and the list of decide-later items with owners.
Перед тим як надіслати результат Spaceberry
Run the full acceptance checklist in Section 3 against the current version, line by line. For each line: pass or fail, and for a fail, exactly where.
Щоб ви знали, чого очікувати і що саме перевіряєте. Точні вимоги викладені в Section 1 і Section 2 робочого файлу для ШІ; ШІ дотримується їх, вам це не потрібно.
Одна папка, Gemina Methodology v1.0, і в ній три речі.
Документ методології з десяти частин:
Таблиця методології з окремою вкладкою для кожного виду структурованого контенту: питання, варіанти відповідей, сигнали, патерни, словники портрета, напрями фокусу, бібліотека дій, щоденні питання, питання оглядів, голос, моменти помічника, глосарій, журнал змін.
Ваша папка матеріалів, без змін, щоб ми могли простежити цитати ШІ до джерела.
Ви отримали його як файл .md (саме його треба завантажити) і як PDF для читання. Три розділи й сім додатків:
Ви можете його читати. Жодних дій від вас він не вимагає.
Як передати результат і що відбувається далі.
Попросіть ШІ ще раз пройти чекліст приймання з Section 3 робочого файлу, рядок за рядком, повідомленням із Частини 3. Потім самі прочитайте частини A, B і H документа повністю, а частини C–G щонайменше один раз. Усе в них має бути вашою методологією. Якщо чомусь, що методологія робить у вашій практиці, не знайшлося місця у форматі, додайте частину K і скажіть нам.
Поділіться папкою Gemina Methodology v1.0 зі Spaceberry: документ, таблиця і папка матеріалів. Найпростіше — Google Drive з доступом на редагування для нашої команди; архів електронною поштою також підходить. Вкажіть версію в назві папки і не редагуйте її після надсилання. Зміни йдуть у нову версію.
Спершу ми робимо пробний прогін: беремо один із ваших розібраних прикладів, застосовуємо ваш документ і таблицю вручну, ніби ми застосунок, і порівнюємо наш результат із частиною H. Там, де ми отримуємо інший портрет, ціль, напрям фокусу чи план, ніж ви, ми надсилаємо вам точне правило, яке дало розбіжність, і питаємо, що мало статися. Ми не виправляємо методологію самі.
Потім ми перетворюємо це на застосунок. Таблиці стають даними, які завантажує застосунок. Правила стають кодом. Описані судження і голос стають інструкціями для ШІ всередині застосунку, з вашими прикладами як калібруванням. Частина H стає нашим тестовим набором: застосунок, отримавши відповіді людини з прикладу, має видати портрет і план із цього прикладу.
Версія 1.0 заморожується, коли починається розробка. Відтоді будь-яка зміна потрапляє в частину J і отримує новий номер версії. Дрібні зміни формулювань можна випускати будь-коли; зміни питань, патернів, словників чи напрямів фокусу потребують розмови, бо збережені користувачі побудовані на старих.
Очікуйте, що пробний прогін виявить прогалини. Якщо методологія записується повністю вперше, так і буде. Це процес працює, а не ламається.