Инструкции
#Пишем как солнце
Используйте этот навык, когда пользователь предоставляет статью с рассказом и хочет извлечь из нее элементы грамматики, заменить переменные в рассказе, сгенерировать переработанную статью или преобразовать результат в короткий драматический сценарий.
## Договор эксплуатации
- Работайте с источником, предоставленным пользователем. Никогда не предполагайте локальный путь, хранилище 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 эпизода; принимаются пользовательские настройки.
- В обзоре необходимо проверить завязку сюжета, цели персонажей, хронологию, причинно-следственные связи, отсылки к мотивам, продолжительность/временной бюджет, диалоги, юмор, оригинальность смысловых событий, наличие реальных людей и полноту формата.
— Никогда не утверждайте, что автоматическая оценка доказывает художественное качество или юридическую легальность. Окончательный этап проверки — это проверка человеком.
Описание
Один файл Skill.md занимает 5,54 КиБ. Печатная рукопись объёмом в пятьдесят миллионов иероглифов весит около 250 килограммов. Writing Like Sun вдохновлён известной статьёй на X. Он объединяет заголовок, начало, ритм, структуру, желания персонажей, возвращающиеся детали и принцип построения финала в единый метод письма, позволяющий помещать новых вымышленных персонажей, миры и события в одну и ту же повествовательную атмосферу. С помощью этого Skill вы сможете создавать истории с тем же ощущением, что и «та статья», даже в совершенно новых декорациях, а также повышать структурную, языковую и повествовательную проработанность текста до уровня, который олицетворяет первое место в конкурсе сочинений «Новая концепция»: сдержанно и точно, абсурдно, но правдоподобно, внешне серьёзно, но с деталями, постоянно создающими контраст. Как если бы вы описывали солнце, — Writing Like the Sun. Этот Skill не связан ни с какими реальными людьми и событиями.
Писать как Sun
YouMind пишет на уровне «Новой концепции»
Инструкции
#Пишем как солнце
Используйте этот навык, когда пользователь предоставляет статью с рассказом и хочет извлечь из нее элементы грамматики, заменить переменные в рассказе, сгенерировать переработанную статью или преобразовать результат в короткий драматический сценарий.
## Договор эксплуатации
- Работайте с источником, предоставленным пользователем. Никогда не предполагайте локальный путь, хранилище 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 эпизода; принимаются пользовательские настройки.
- В обзоре необходимо проверить завязку сюжета, цели персонажей, хронологию, причинно-следственные связи, отсылки к мотивам, продолжительность/временной бюджет, диалоги, юмор, оригинальность смысловых событий, наличие реальных людей и полноту формата.
— Никогда не утверждайте, что автоматическая оценка доказывает художественное качество или юридическую легальность. Окончательный этап проверки — это проверка человеком.
Описание
Один файл Skill.md занимает 5,54 КиБ. Печатная рукопись объёмом в пятьдесят миллионов иероглифов весит около 250 килограммов. Writing Like Sun вдохновлён известной статьёй на X. Он объединяет заголовок, начало, ритм, структуру, желания персонажей, возвращающиеся детали и принцип построения финала в единый метод письма, позволяющий помещать новых вымышленных персонажей, миры и события в одну и ту же повествовательную атмосферу. С помощью этого Skill вы сможете создавать истории с тем же ощущением, что и «та статья», даже в совершенно новых декорациях, а также повышать структурную, языковую и повествовательную проработанность текста до уровня, который олицетворяет первое место в конкурсе сочинений «Новая концепция»: сдержанно и точно, абсурдно, но правдоподобно, внешне серьёзно, но с деталями, постоянно создающими контраст. Как если бы вы описывали солнце, — Writing Like the Sun. Этот Skill не связан ни с какими реальными людьми и событиями.
Найди свой следующий любимый скилл
Изучи больше отобранных AI-скиллов для исследований, творчества и повседневной работы.