Peredelka Dogovorov Arendy

Переоформление И Управление Договорами Найма

Запуск Навыка

При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:

Применяю «Переоформление договоров найма»: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания.

Не включайте в строку author_github, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

Не завершайте первый ответ планом будущей разведки. Если папка объекта однозначно доступна, сразу выполните read-only поиск документов и верните первые наблюдаемые факты. Если источник нельзя определить из текущего контекста или инструментов, в том же ответе задайте один ближайший вопрос о папке или исходном договоре.

Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

Ownership

Это личный доменный asset, подготовленный к публикации как командный skill.

• исходный автор и текущий owner в registry: см. skill.yaml;
• публичный skill содержит методологию, forensic-чеклист и проверяемые шаблоны форматирования, но не хранит реальные ФИО, ИИН, номера документов, адреса объектов или суммы конкретных сделок.

Privacy Boundary

Не переносите в публичный repo реальные ФИО сторон, ИИН, номера УДО/паспорта/РВП, адреса объектов, суммы конкретных сделок или фрагменты переписки. Все примеры в этом skill вымышленные (см. подписные блоки ниже и references/audit-checklist.md).

Реальные реквизиты и суммы всегда берутся из документов и переписки, которые пользователь предоставляет в моменте работы, и показываются на сверку перед подготовкой пакета. Если для конкретной команды нужны закрытые эталонные пакеты или memory-файл rental-lessons.md с накопленными уроками, храните их в приватном источнике, а не как публичный repo text.

Когда Использовать

• Смена наймодателя (переоформление внутри семьи / при продаже).
• Фиксация перерасхода бюджета улучшений через допсоглашения.
• Создание нового договора на основе старого.
• Аудит существующего договора на дыры и риски.
• Приведение пакета документов к единому оформлению.

Порядок Работы

Фаза 1. Разведка

Прежде чем что-либо делать — прочитайте всё в папке проекта.

1. Просканируйте файлы папки объекта: .docx, .pdf, .xlsx, экспорты переписки (.html).
2. Извлеките текст из docx через python-docx, читая и параграфы (document.paragraphs), и таблицы (document.tables) — в договорах и актах реквизиты, суммы и графики платежей часто лежат именно в таблицах, а не в обычных абзацах.
3. Извлеките текст из PDF через pypdf; OCR не нужен для текстовых PDF, но проверьте текстовый слой — скан без текстового слоя требует Read tool или OCR.
4. В экспортах переписки ищите по ключевым словам: адрес, ФИО, суммы, «бюджет», «улучшен», «чек», «перерасход», «спецсчёт», «реквизит».
5. Фото документов (удостоверение личности, вид на жительство, паспорт) читайте через Read tool.

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

Фаза 2. Анализ

Проверяйте каждый документ по чеклисту в references/audit-checklist.md.

Ключевые проверки:

• идентификация сторон: реквизиты и документы сторон — актуальны ли на дату подписания;
• правоустанавливающие документы: указан ли конкретный документ и есть ли он в папке;
• бюджет улучшений: сколько потрачено фактически vs сколько компенсировано, есть ли перерасход;
• акт приема-передачи: заполнены ли поля (счетчики, ключи, опись);
• раздел о расторжении: операционализированы ли критерии, нет ли коллизий между пунктами;
• коммуналка: есть ли механизм контроля оплаты;
• повышение аренды: есть ли cap.

Фаза 3. Планирование

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

План должен содержать:

• какие документы нужны (расторжение, соглашение о сальдо, новый договор, допсоглашения);
• как они связаны между собой (кто на кого ссылается);
• какие суммы фигурируют и как они сходятся;
• какие открытые вопросы нужно решить до написания текстов;
• порядок подписания.

Фаза 4. Создание Документов

Общие правила форматирования

Все документы пакета — единый стиль: формат A4, поля 2.0/1.5/2.0/1.5 см, ширина текста 17.5 см, шрифт Times New Roman 11pt, межстрочный 1.15 (в подписных блоках 1.0), отступ после абзаца 3pt.

Заголовки документов

Центрированные, жирные, 13pt. Подзаголовок (адрес объекта) — курсивом. Дата и город — на одной строке через tab stop.

Заголовки разделов

Центрированные, жирные, заглавными буквами.

Таблицы

Горизонтальные линии без вертикальных перегородок: заголовок — темный фон, белый текст, жирная рамка сверху и снизу; секции — серый фон, средняя рамка; данные — чередование белого и светло-серого фона с тонкими горизонтальными разделителями; итого — серый фон, жирная рамка. Столбцу с описанием отдавайте 65-70% ширины.

Подписные блоки

Вертикальный формат (не таблица, не двухколоночный). Пример структуры с вымышленными данными:

────────────────────────────────────────────
Наймодатель: Петров Петр Петрович
ИИН 123456789012, УДО № 123456789 от 01.01.2020 (МВД РК)
Подпись _______________________________ / Петров П. П. /

Наниматель: Иванов Иван Иванович
ИИН 210987654321, паспорт 123456789 (РФ), РВП № 01-23RVP-4567890
Подпись _______________________________ / Иванов И. И. /

Обязательно keep_with_next и keep_together на всех параграфах подписного блока. Горизонтальная линия перед блоком — через w:pBdr/w:bottom.

Инструменты

Используйте python-docx для создания новых документов и точечного редактирования существующих. Для сложного редактирования XML, если python-docx не справляется: unpack → edit XML → repack. Конвертация в PDF для проверки: soffice --headless --convert-to pdf. Визуальная проверка: pdftoppm -jpeg -r 200 → Read tool.

Фаза 5. Проверка

После создания пакета — обязательная проверка:

1. Математика: цепочка сумм должна сходиться сквозь все документы. Пример на вымышленных числах: 300 000 (расходы) → −50 000 (март) = 250 000 (передается) → −50 000 (апрель) = 200 000 → ...
2. Перекрестные ссылки: документ B ссылается на документ A по реквизитам.
3. Подписные блоки не разрываются через страницу.
4. Поля и размер страницы одинаковы во всех файлах пакета (A4).
5. Единый стиль: шрифт, межстрочный, заголовки, подписи — визуально один пакет.

Фаза 6. Forensic-Аудит (По Запросу)

Проверяйте договор как инженер эксплуатации, а не как юрист-формалист. Ключевые вопросы:

• где подменяются реальные механизмы словами («нарушение» без определения);
• где нет measurement layer (износ, поломки, коммуналка — кто и как считает);
• где скрыт ручной труд (чеки в переписке без реестра);
• где договор ломается при споре (пустой акт, молчание = согласие, переписка как юр. канал);
• где нет enforcement кроме суда (суд по мелкому спору стоит дороже предмета спора);
• где fantasy architecture (например фотоотчет якобы обновляет опись без подписей).

Для каждой дыры: тезис → почему ломается → скрытое допущение → как решают сильные.

Типовые Конструкции

Соглашение О Сальдо (При Смене Наймодателя)

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

Ключевой пункт — условный, а не безусловный отказ от претензий: обязательства прежнего наймодателя считаются прекращенными только с момента подписания нанимателем и новым наймодателем отдельного документа о принятии; до подписания обязательство сохраняется за прежним наймодателем. Безусловный отказ равносилен подарку — если новый наймодатель не подпишет допсоглашение, наниматель теряет деньги; условный отказ оставляет рычаг.

Допсоглашение О Принятии Перерасхода

Назначение: новый наймодатель принимает на себя обязательство по компенсации накопленного перерасхода из арендных платежей.

Обязательные элементы: признание суммы со ссылкой на соглашение о сальдо, зачеты прошлых месяцев, график помесячного погашения, автоматическая пролонгация до полного погашения, досрочная компенсация при прекращении, обязательство сохраняется независимо от состояния или принадлежности объекта.

Правки Раздела О Расторжении

Типичные дыры в шаблонных договорах и как их закрывать:

Антипаттерны

• Не начинайте делать документы без плана; не превращайте показ плана в повторный запрос уже данного разрешения.
• Не оставляйте пустые поля в подписанных документах (площадь, этаж, счетчики).
• Не называйте месяцы порядковыми номерами — только именами месяцев.
• Не пишите безусловный отказ от претензий при наличии непокрытого перерасхода.
• Не оправдывайте финансовые решения «духом договора» — ссылайтесь на конкретный пункт или редактируйте договор.
• Не делайте документы на US Letter — только A4.
• Не делайте разные подписные блоки в документах одного пакета.

Опрос После Использования

Опрос задаётся один раз — после передачи готового пакета документов, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

Опрос по skill:
1. Что в этом использовании peredelka-dogovorov-arendy было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/peredelka-dogovorov-arendy/usage-feedback.jsonl — лучше через bundled script:

python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет redaction_applied и redaction_types. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

Логирование Сбоев

Перед выполнением прочитайте локальный known-exceptions.yaml как список уже известных случаев и применяйте подходящее do_next_time без нового поиска.

Если план разошелся с реальностью пакета, forensic-чеклист пропустил случай, пользователь поправил структуру или пришлось отклониться от инструкции, запишите приватную карточку в ~/.codex/skill-runs/peredelka-dogovorov-arendy/exception-log.jsonl.

Пишите факты: какой пакет документов был входом, что делал skill, где возник сбой, какая предпосылка оказалась неверной и что делать в следующий раз. Если поле неизвестно, пишите unknown. Raw logs не коммитить.

Эволюция Скилла

Этот skill не финальная версия — он развивается через опыт.

После каждого применения проверьте: столкнулись ли вы с ситуацией, которую skill не покрывает; пришлось ли отклониться от инструкций; обнаружили ли антипаттерн, которого нет в списке; был ли пользователь недоволен рекомендацией skill.

Если да хотя бы на один вопрос — запишите урок в приватный memory-файл rental-lessons.md: что произошло, почему skill не справился, что сделали вместо этого и какое правило зафиксировать на будущее. Не вписывайте уроки в SKILL.md автоматически — только через осознанную ревизию с пользователем.

Definition Of Done

Задача закрыта, когда:

• план пакета документов зафиксирован до генерации, а реальные развилки, если они возникли, подтверждены пользователем;
• все реквизиты и суммы сверены с исходными документами и перепиской;
• математика сходится сквозь все документы пакета;
• пакет визуально единообразен (формат, поля, шрифт, подписные блоки);
• пользователь видит итоговый пакет и список открытых вопросов, если они остались.