# Dopsoglasheniya Po Oplate

> «ДС по постоплате», «допник по оплате», «дополнительное соглашение на вычет», «измени сумму аренды допсоглашением», «ДС к договору найма». Сборка DOCX.

- Skill: `kir-kopylov/dopsoglasheniya-po-oplate` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add kir-kopylov/dopsoglasheniya-po-oplate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/dopsoglasheniya-po-oplate/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: kir-kopylov (https://skillmd.com/u/kir-kopylov)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kir-kopylov/dopsoglasheniya-po-oplate

---


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

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

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

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

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

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

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

## Ownership

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

- исходный автор workflow: Елизавета;
- текущий owner в registry: см. `skill.yaml`;
- публичный skill содержит процесс, обезличенные примеры и проверяемый генератор,
  но не хранит raw-реквизиты, приватные договоры или внутренние эталонные блоки.

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

Используйте skill, когда пользователь просит сделать ДС, допник или дополнительное
соглашение к договору аренды/найма по одному из трех сценариев:

- перенос оплаты на постоплату;
- разовый вычет из арендной платы;
- разовое изменение суммы аренды за конкретный месяц.

Skill должен собирать документ как конструктор: шапка, преамбула арендатора,
преамбула арендодателя, тело под тип ДС и подписной блок.

## Privacy Boundary

Не переносите в публичный repo raw-реквизиты, приватные договоры, ИНН, номера
свидетельств, личные адреса объектов или внутренние эталонные формулировки без
явного privacy-review.

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

## Контрфактический Гейт Рабочего Вопроса

Проверку проводи внутренне; пользователю не показывай вероятные ответы и карту изменений.

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

## Процесс

1. Найдите договор, на основе которого нужно сделать ДС.
2. Определите формат договора:
   - `.docx` можно читать механически;
   - `.pdf` сначала проверьте на текстовый слой;
   - скан без текстового слоя требует OCR или ручного визуального чтения.
3. Извлеките реквизиты сторон, дату договора, адрес объекта, вид договора и исходный
   порядок оплаты.
4. Покажите пользователю извлеченные реквизиты на сверку до генерации. Особенно
   сверяйте ИНН, даты, номера свидетельств, ФИО и адрес.
5. Определите номер ДС: проверьте папку объекта на предыдущие допсоглашения. Не
   хардкодьте `N 1`; если номер неясен, спросите пользователя.
6. Уточните тип ДС и параметры:
   - для постоплаты: период, день оплаты, условия возврата к обычному порядку;
   - для вычета: месяц и сумма цифрами и прописью;
   - для изменения суммы: месяц и новая сумма цифрами и прописью.
7. Соберите JSON config для `scripts/build_ds.py` и сгенерируйте DOCX.
8. Проверьте документ визуально: A4, Times New Roman, корректные преамбулы, суммы
   цифрами и прописью, подписи не разрываются.
9. Покажите пользователю результат и список реквизитов, по которым собирался ДС.

## Конструктор

Используйте `references/bloki-DS.md` как карту веток. Он намеренно содержит
обезличенные шаблоны и поля конфигурации, а не приватные реквизиты конкретных
контрагентов.

Генератор принимает два обязательных пользовательских слоя:

- `tenant.full_clause` и `tenant.short_name` - формулировка арендатора из договора;
- `landlord` - статус и реквизиты арендодателя, извлеченные из договора.

Если в договоре встретилась новая ветка, не подгоняйте ее под ближайшую старую.
Зафиксируйте новый случай, покажите пользователю, что именно изменилось, и
предложите отдельный patch в reference-файл после privacy-review.

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

- Не генерируйте юридически значимый документ без сверки извлеченных реквизитов.
- Не считайте OCR безошибочным источником для ИНН, дат и номеров свидетельств.
- Не подставляйте статус арендодателя по догадке.
- Не выдумывайте сумму, месяц, день оплаты или номер ДС.
- Не оставляйте пустые поля в готовом DOCX.
- Не превращайте этот skill в юридическое заключение: он собирает документ по
  утвержденному шаблону и требует человеческой проверки.

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

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

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

Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/dopsoglasheniya-po-oplate/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` без нового поиска.

Если пользователь поправил реквизиты, OCR дал неверное значение, генератор
собрал неверную ветку, документ визуально сломался или пришлось добавлять новый
case в конструктор, запишите приватную карточку в
`~/.codex/skill-runs/dopsoglasheniya-po-oplate/exception-log.jsonl`.

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

## Definition Of Done

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

- тип ДС и параметры подтверждены пользователем;
- реквизиты сторон сверены с договором;
- номер ДС проверен по папке объекта или явно подтвержден пользователем;
- DOCX сгенерирован без пустых полей;
- документ визуально проверен;
- пользователь видит, из каких реквизитов и веток был собран результат.