# Peredelka Dogovorov Arendy

> «Переоформи договор аренды на другого наймодателя», «перерасход бюджета улучшений», «проверь договор найма на дыры», «forensic-аудит», «хронология документов по объекту».

- Skill: `kir-kopylov/peredelka-dogovorov-arendy` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add kir-kopylov/peredelka-dogovorov-arendy`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/peredelka-dogovorov-arendy/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kir-kopylov (https://skillmd.com/u/kir-kopylov)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kir-kopylov/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 (например фотоотчет якобы обновляет опись без подписей).

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

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

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

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

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

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

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

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

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

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

| Проблема | Решение |
|----------|---------|
| «безосновательно» без определения | Закрытый перечень оснований |
| «нарушает условия» без порога | Закрытый перечень существенных нарушений с числами |
| Пункт о безусловном праве расторжения противоречит пункту о штрафе | Явная привязка последствий к конкретным пунктам |
| Компенсация только за текущий месяц | Расширить на весь непогашенный остаток |
| Нет cap на повышение аренды | Установить предельный процент и право уйти с сохранением компенсации |

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

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

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

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

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

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

```bash
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

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

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