#Пишем как солнце

Используйте этот навык, когда пользователь предоставляет статью с рассказом и хочет извлечь из нее элементы грамматики, заменить переменные в рассказе, сгенерировать переработанную статью или преобразовать результат в короткий драматический сценарий.

## Договор эксплуатации

- Работайте с источником, предоставленным пользователем. Никогда не предполагайте локальный путь, хранилище 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`.

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

Следуйте по наименьшему полному пути:

`анализ -> настройка -> переработка/запись -> проверка -> скрипт -> проверка`

Для получения информации о входных и выходных данных этапов, правилах продолжения и примечаниях к сравнительному анализу GitHub ознакомьтесь с файлом `references/workflow.md`. Пользователь может пропустить этап только в том случае, если необходимый для него артефакт уже присутствует в командной строке или рабочем пространстве.

На каждом этапе:

1. Укажите, какой артефакт используется и какие предположения отсутствуют.

2. Создайте удобочитаемый результат в формате Markdown.

3. Когда пользователь запрашивает машиночитаемый вывод, предоставьте соответствующий JSON-файл из соответствующей схемы.

4. Четко формулируйте нерешенные вопросы, вместо того чтобы молча придумывать ограничения.

## Выходные и качественные затворы

— В итоговой статье должны быть указаны запрошенный заголовок, точка зрения повествования, структурные элементы и заключение. Сохраняйте полезные грамматические конструкции источника, а не имена собственные или фактические утверждения.

- Заголовок статьи должен отражать грамматику именования, количество строк и плотность информации источника. Замените имена собственные и факты источника, но не делайте минимальный заголовок источника более пояснительным или длинным, если пользователь не запросит вариант заголовка. Первые абзацы должны следовать последовательности проанализированной информации источника и задавать зацепку перед предысторией. Если пользователь явно запрашивает другое начало, выполните этот запрос и зафиксируйте отклонение.

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

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

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

— Никогда не утверждайте, что автоматическая оценка доказывает художественное качество или юридическую легальность. Окончательный этап проверки — это проверка человеком.