# Пишу, як сонце

Використовуйте цю навичку, коли користувач надає статтю-сюжет і хоче витягти з неї механіку написання, замінити змінні сюжету, створити реміксовану статтю або перетворити результат на сценарій короткометражної драми.

## Експлуатаційний договір

- Працюйте з вихідного коду, наданого користувачем. Ніколи не припускайте локальний шлях, сховище Obsidian, базу даних, ключ API, мережеву службу або попередній стан розмови.

- Мова за замовчуванням – китайська. Зіставте запитувану довжину та тон; якщо не вказано, запитайте мінімальну кількість відсутніх креативних змінних перед написанням чернетки.

- Розглядати джерело як таке, що належить користувачеві або авторизоване користувачем, як того вимагає політика продукту цієї навички. Показати коротке нагадування про те, що завантаження саме по собі не підтверджує права на публікацію чи адаптацію, без блокування.

– За замовчуванням використовуються вигадані персонажі. Якщо вказано або впізнаване ім’я реальної особи, попередьте про репутаційний ризик та ризик для платформи і запропонуйте вигаданий персонаж. Це креативне попередження, а не перевірка особи чи юридична консультація.

- Ремікс із високою схожістю є стандартним. Зберігайте ритм речень, темп абзаців, наративну позицію, засоби контрасту, повторення та розкриття часу. Замініть персонажів, причинно-наслідкові події, місця дії та семантичний зміст, щоб результатом була нова історія, а не заміна імені.

- Ставтеся до **назви та початку як до зон високої точності**. Зберігайте граматичні слоти, інформаційну щільність та форму, що містить конфлікт, у назві джерела, а потім замінюйте власні імена та семантичні особливості. Якщо назва джерела є мінімальною формою «зв'язок-плюс-ім'я», дотримуйтесь мінімального рівня; не додавайте пояснювальний сюжетний пункт, якого немає в джерелі. Зберігайте порядок інформації у початку та рух речення: конкретний контраст або вимірювання -> безпосередній запит/інцидент -> операційна деталь, що розкриває зв'язок -> раннє передвістя розриву або зникнення -> поворот у ретроспективу. Не копіюйте довгий безперервний уривок і не зберігайте унікальний ланцюжок подій джерела.

- Не включайте повний текст статті користувача в цей пакет навичок. Наводьте лише короткі, необхідні фрагменти доказів у результатах аналізу.

## Режими

Виберіть режим із запиту користувача. Якщо жоден режим не зрозумілий, наведіть шість режимів нижче та запитайте, який із них запустити.

1. **аналіз**: витяг спостережуваних фактів, правил-кандидатів, специфічних для сюжету прийомів, синтаксису заголовка, порядку початкової інформації, обсягу доказів, достовірності та непереносних поверхневих ознак. Читайте `references/analysis-schema.md`.

2. **налаштувати**: зібрати або нормалізувати передумову, тему, персонажів, стосунки, бажання, перешкоди, сеттинг, часову шкалу, кінцівку, інтенсивність гумору, тривалість та пресет драми. Читайте `references/story-bible-schema.md`.

3. **ремікс**: застосуйте проаналізовані механіки до налаштованих змінних. Зберігайте поведінку поверхні високого рівня, змінюючи при цьому семантичні події та логіку персонажів. Напишіть чернетку заголовка та початкового плану перед основною частиною. Якщо аналіз відсутній, спочатку проаналізуйте вихідний код.

4. **напишіть**: створіть повну статтю про китайську казку з Біблії оповідань та вибраних механік. Напишіть та перевірте заголовок і вступ, перш ніж розгортати основну частину. Зберігайте причинно-наслідковий зв'язок та мотиви; не пояснюйте мораль, а драматизуйте її.

5. **сценарій**: перетворіть історію як на літературний сценарій, так і на виробничий аркуш штучного інтелекту. Читайте `references/drama-script-schema.md`.

6. **перегляд**: запускати автоматичні перевірки та повідомляти про блокування, попередження, оцінки та конкретні виправлення. Читайте `references/quality-rubric.md`.

## Робочий процес

Слідкуйте за найменшим повним шляхом:

`аналізувати -> налаштувати -> ремікс/записати -> переглянути -> скрипт -> переглянути`

Ознайомтеся з `references/workflow.md` для вхідних та вихідних даних етапу, правил продовження та нотаток щодо бенчмарків GitHub. Користувач може пропустити етап лише тоді, коли необхідний для нього артефакт вже присутній у запиті або робочій області.

На кожному етапі:

1. Вкажіть, який артефакт використовується, а які припущення відсутні.

2. Створіть результат Markdown, зрозумілий для людини.

3. Коли користувач запитує машинозчитуваний вивід, надайте відповідну JSON-форму з відповідної схеми.

4. Замість того, щоб мовчки вигадувати обмеження, чітко формулюйте невирішені рішення.

## Вихідні та якісні вентилі

- Вихідні дані статті повинні містити запитувану назву, точку зору наративу, структурні моменти та кінцівку. Зберігайте корисну механіку джерела, а не його власні назви чи фактичні твердження.

– Назва статті повинна відображати граматику назв, кількість слотів та щільність інформації джерела. Замініть власні іменники та факти джерела, але не робіть мінімальну назву джерела більш пояснювальною або довшим, якщо користувач не просить про зміну назви. Перші абзаци повинні відповідати послідовності аналізу інформації джерела та встановлювати зачіпку перед передісторією. Якщо користувач явно просить про інший початок, дотримуйтесь цього запиту та запишіть відхилення.

- Вивід реміксу повинен містити короткий «опис змін» зі списком змінених персонажів, подій, місця дії, кінцівки, семантики назви та вступних фактів, щоб семантичне перетворення можна було перевірити.

- Вивід сценарію повинен містити обидва результати, зазначені в `references/drama-script-schema.md`. Попередньо встановлена ​​тривалість епізоду за замовчуванням становить 60–90 секунд та 12–24 епізоди; приймаються попередні налаштування, надані користувачем.

- У рецензії необхідно перевірити передумову, цілі персонажів, часову шкалу, причинно-наслідковий зв'язок, зворотні посилання на мотиви, бюджет тривалості/часу, діалоги, гумор, оригінальність семантичних подій, прапорці реальних осіб та повноту формату.

– Ніколи не стверджуйте, що автоматичне оцінювання доводить художню якість або юридичну придатність. Перевірка людиною залишається остаточним рішенням.