Remont Dogovor I Raspiski

Remont Dogovor I Raspiski

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

Этот черновой навык запускайте только при явном вызове по имени или прямой команде пользователя. При одном смысловом совпадении не запускайте навык и не спрашивайте о его применении.

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

Применяю черновой навык «Договор и расписки на ремонт» (обратная связь — @kir-kopylov): <кратко назовите конкретную пользу для текущего запроса>; продолжаю без ожидания.

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

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

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

Обзор

Повторяемая боль: договорились на ремонт «на словах», деньги передают частями, а оформить нечем — и потом спор «сколько отдал и за что». Skill собирает связный пакет: рамочный договор оказания услуг со ссылкой на перечень работ и расписки по платежам (аванс, этапы, окончательный расчёт), при необходимости — акт. Расписки делаются переиспользованием raspiska-o-poluchenii-deneg, вёрстка .docx — через verstka-docx-po-standartu.

Ценность не в красивом шаблоне, а в сквозных инвариантах: один адрес и одни имена во всех документах, итог = аванс + остаток, аванс = сумма частей, и хронология (ни один документ не ссылается на «будущий» документ). Любое расхождение выносится пользователю, а не «чинится» молча.

Естественные Входы

• «составь договор на ремонт и расписки»
• «оформи договор оказания услуг с авансом и распиской»
• «сделай пакет документов по сделке с мастером»
• «нужен договор подряда на ремонт плюс расписки по этапам»
• «оформи документы: договор, аванс, окончательный расчёт»

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

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

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

Процесс

1. Соберите вход. Стороны (заказчик, исполнитель), адрес объекта, перечень работ (лучше из smeta-remonta-do-dogovora), общая сумма, разбивка платежей (аванс и остаток или этапы), даты. Чего нет — спрашивайте; не выдумывайте.
2. Проверьте инварианты до сборки. Адрес и имена одинаковы во всех документах; итог = аванс + остаток; аванс = сумма частей; даты согласованы. Конфликт (например, расписка раньше договора, на который ссылается) — стоп и вопрос пользователю.
3. Соберите рамочный договор. Предмет — выполнение работ по перечню (перечень — приложение, а не пересчёт сметы здесь), цена и порядок оплаты, сроки, ответственность, реквизиты и подписи. Отсутствующие личные данные — графы «____».
4. Соберите расписки. На каждый платёж — расписка через raspiska-o-poluchenii-deneg: сумма цифрами и прописью, ссылка на договор и перечень, дата. Суммы расписок в сумме дают итог договора.
5. Опционально — акт. Если нужен акт приёмки, добавьте его со ссылкой на договор и перечень; следите за хронологией (акт не раньше работ).
6. Отрендерьте и покажите. Готовый сборщик — scripts/build_package.py: на вход JSON-config сделки (стороны, адрес, перечень-ссылка, итог цифрами и прописью, список платежей), на выход — dogovor.docx плюс raspiska-N.docx по числу платежей. Он сам проверяет инварианты (итог = сумма частей, хронология) до записи, расписки формирует по образцу raspiska-o-poluchenii-deneg, вёрстку — по стандарту оформления verstka-docx-po-standartu (рендер встроен в скрипт, отдельной runtime-зависимости нет). Запуск: python3 scripts/build_package.py --config <config>.json --out-dir <каталог>. Верните пользователю пакет и сводку: какие документы, какие суммы, какие графы пустые, какие инварианты проверены.

Границы

• Не делать договоры аренды/найма и допсоглашения к ним — это dopsoglasheniya-po-oplate.
• Не составлять смету и не пересчитывать объёмы/цены — это smeta-remonta-do-dogovora; здесь перечень используется как приложение.
• Не выдумывать стороны, адрес, суммы, номера и даты; отсутствующие личные данные — графа «____».
• Не «чинить» расхождение сумм или хронологии молча — выносить пользователю.
• Не выдавать пакет за юридическое заключение: документы по шаблону требуют проверки человеком. В примерах — только синтетические данные.

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

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

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

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

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в ~/.codex/skill-runs/remont-dogovor-i-raspiski/exception-log.jsonl.

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