Imported from alexisinwork/books (default/AGENTS.md). Install upstream with npx skills add alexisinwork/books --skill default. Copyright stays with the author.

Правила работы в книжном проекте

Текущая инструкция автора имеет приоритет. Сначала прочитайте START_HERE.md, project.json и book.json выбранной книги. В общем репозитории default, buro, kontakt и riokka — отдельные области; относительные пути и команды относятся к выбранной области.

default содержит чистые формы. Исторический документ в methods/history объясняет происхождение системы и содержит примеры другого проекта. Не загружайте его как канон новой книги, не переносите имена, биографию автора или события из примеров в brief, profiles, series или книги.

Обязательный цикл для каждой сцены и главы

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

1. До письма прочитайте STYLE.md, профиль выбранной книги voice.json и её STYLE.md, если он есть.
2. Прочитайте относящийся к сцене канон персонажей: characters.json, канон по ссылке book.json.canon, series/glossary.json и подтверждающие фрагменты выбранной версии. Соблюдайте series/CANON-POLICY.md, если он есть.
3. Прочитайте текущее состояние именно перед этой сценой: session.md, scenes.json, timeline.json, knowledge.json, затронутые ресурсы и обещания, открытые замечания. Финал тома и знания из будущих сцен не являются исходным состоянием ранней главы.
4. Не изобретайте канон молча. Новые детали отделяйте как предложения; установленный факт меняйте только в пределах явного поручения автора, с основанием и перечнем последствий.
5. Если факт отсутствует или источники расходятся, внесите вопрос в audit/issues.json с resolution_status: "unresolved" и зависимостями. Пустой реестр не разрешает заполнить пробел выдуманным подтверждением.
6. Сохраняйте установленные знания персонажей и момент их получения. Новое знание требует события и источника в тексте; догадка, ложное убеждение и знание читателя ведутся отдельно. Реткон уже установленного знания требует явного поручения.
7. После правки обновите все затронутые записи непрерывности, версии, производные файлы и якоря по порядку синхронизации. Запишите результат в revision-log.json и session.md; для отдельного варианта ведите собственные состояния.
8. Выполните проверки прозы из того же руководства и технические проверки выбранной версии. Зафиксируйте охват и результат; незапущенную или устаревшую проверку нельзя отмечать пройденной.

Сцена завершена, когда текст, связанные записи и отчёт проверок согласованы. Неразрешённые зависимости должны быть явно перечислены; такой фрагмент не объявляйте полностью проверенным.

Не выбирайте последнюю версию по расширению, дате или удобству парсинга. Мастер указан автором в book.json. Проверяйте SHA-256 перед применением якорей. Производное извлечение не редактируется как рукопись. Изменение основного файла требует новой фиксации версии и перепроверки затронутых доказательств.

Приоритет подачи: автор сейчас → согласованное исключение сцены → профиль книги → явно подключённые авторские черты → необязательный пресет. Канон задаёт факты мира; профиль задаёт способ рассказа. Книги могут сознательно походить друг на друга.

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

Используйте подходящий скилл на текущий этап: ru-book-writer — написание; ru-book-voice — подача; ru-book-architect — структура; ru-book-auditor — проверка; ru-book-revision — замечания и правки. Полные инструкции находятся в skills; пути сопоставлены в guides/SCHEMA.md.

При запросе анализа не выдавайте предложение за применённую правку. При порученном переписывании доведите его до текста, запишите точное «было / стало», затем обновите затронутые записи. Новая трактовка не становится каноном сама собой. Статусы proposed, accepted, applied и verified обозначают разные этапы.

Не выводите литературные решения из числовых квот. Не называйте симуляции ИИ независимыми живыми читателями. Не объявляйте полный аудит по выборке. При смене POV или времени проверяйте причинный переход, а не формальное равенство состояний соседних глав.

Независимые проходы можно поручать разным агентам по просьбе автора. Назначайте каждому свой набор файлов; объединяйте правки по выбранной версии. Сначала завершите чтение и проверку, затем фиксируйте результат, а не наоборот. Детальный цикл и положения исходной системы — guides/SYSTEM-APPLICATION.md.

Языковая политика с 14 сентября 2026

Gemini вызывается только через agy CLI — постоянное решение автора. gemini CLI запрещён, включая fallback. Недоступность модели в agy фиксировать явно, не подменять исполнителя или клиента.

Новые книги и новая проза по умолчанию — украинские; английский оригинал возможен по прямому выбору автора. Старые русские тексты сохраняются с прежними хешами и статусами. Общая архитектура и языковые правила: project.json.book_system, в этом репозитории BOOK_SYSTEM. До письма прочитайте CORE и целевой LANGUAGES; до адаптации — ADAPTATION/WORKFLOW. Для литературной проверки обязательны Opus, Gemini 3.8 Flash и Gemini 3.1 Pro. Исторический префикс навыков ru- сохранён для совместимости, язык определяется изданием.