Docs Ord

docs-ord – Организационно-распорядительные документы

Пользовательский контекст

Прочитай ~/.docs-plugin/org_details.md. Если knowledge_base_path заполнен и каталог существует, считай его корнем пользовательского хранилища: сначала прочитай корневые инструкции (AGENTS.md, CLAUDE.md, GEMINI.md или эквивалент текущего агента), затем найди карточки ОРД по теме задачи. Читай столько карточек и связанных материалов, сколько нужно, пока новые источники перестают добавлять факты, дословные формулировки, основания, распорядительные пункты, согласование, ознакомление и приложения. При неоднозначности извлечения или важности формы открой оригинал по указателю карточки. Отделяй данные источника от правил скилла и собственных предложений; не выдумывай обязанности, сроки и реквизиты без подтверждения пользователя.

Режим работы: создание или ревью

Скилл работает в двух режимах. Определи режим из запроса до всего остального:

• Создание (по умолчанию): пользователь даёт вводные и просит составить документ → разделы 0–4 ниже.
• Ревью: на вход подаётся готовый документ (.doc/.docx) И есть слова вроде «ревью / проверь / поправь / вычитай / отрецензируй / посмотри приказ» → раздел 5. Режим ревью.

0. Карта references

Прочитать до начала работы

Эти файлы содержат правила, без которых документ будет некорректным. Читать ВСЕ четыре перед формированием текста.

Читать по ситуации

Справочные

1. Workflow

Шаг 0. Прочитать обязательные references

Gemini CLI: ~/.docs-plugin/org_details.md не подгружается автоматически. Прочитай файл явно до любых других шагов. Используй native Gemini tools. Если файла нет – сообщи пользователю и предложи запустить docs-init.

Codex: ~/.docs-plugin/org_details.md не подгружается автоматически. Прочитай файл явно до любых других шагов. Используй native Codex tools. Если файла нет – сообщи пользователю и предложи запустить docs-init.

Прочитать npa-rules.md, basis-rules.md и ~/.docs-plugin/org_details.md – до запуска субагентов и до формирования текста.

Шаг 1. Понять задачу

Определить из контекста запроса:

Что НЕ спрашивать:

• НПА - субагент ищет автоматически
• Основания для издания - нет в запросе - нет в документе

Что спрашивать:

• Контроль - обязательный вопрос (если не указан явно)
• До 5 содержательных уточняющих вопросов по существу документа. Вопросы зависят от темы и контекста - задавать то, что нельзя угадать и что критично для содержания. Примеры:
  • Сроки исполнения (если в запросе нет конкретных дат)
  • Признание утратившими силу предыдущих ОРД по этой теме
  • Конкретные механизмы и процедуры (если приказ утверждает порядок или положение)
  • Ответственные исполнители по пунктам (если из запроса неясно)
  • Источник финансирования (если приказ подразумевает расходы)
  • Подписант (если тип документа - распоряжение или указание)
  • Состав участников, комиссии, рабочей группы
• Допускается больше 5 вопросов, если контекст документа объективно требует дополнительных уточнений
• Вопросы задаются одним блоком вместе с вопросом о контроле, до показа структуры документа

Шаг 2. Запустить npa-verifier

Субагент запускается сразу – параллельно с уточняющими вопросами. Промпт:

Для каждого НПА из списка: <список НПА или описание темы>
Проверь через WebSearch реквизиты и актуальность по протоколу web-search.md. Источники: publication.pravo.gov.ru, официальные сайты ведомств, consultant.ru, garant.ru.
Для каждого НПА верни: {"npa_key": "...", "official_name": "...", "date": "...", "number": "...", "status": "актуален"|"отменен"|"изменен", "source_url": "...", "checked_at": "...", "confidence": "high"|"medium"|"low", "notes": "..."}.
Если НПА не найден – верни {"npa_key": "...", "status": "не найден"}.
Если тема указана без НПА – подбери 2-4 релевантных НПА и верни их реквизиты.
Не придумывай реквизиты. Вернуть только JSON-массив.

Claude Code: запусти субагентом как описано выше.

Gemini CLI: субагент недоступен. Выполни проверку inline по web-search.md: WebSearch по каждому НПА на publication.pravo.gov.ru / официальных сайтах ведомств / consultant.ru / garant.ru. Примени те же правила фильтрации: кодексы (ТК РФ и др.), Конституция, ГОСТы, СанПиНы – без реквизитов «от ... №...».

Codex: если в текущей сессии доступен agent/subagent tool, можно делегировать проверку. Иначе сообщи пользователю subagents unavailable in this session, continuing inline и выполни ту же inline-проверку по web-search.md.

Шаг 3. Сверить сотрудников

Прочитать staff-rules.md. Сверку делать самостоятельно через openpyxl (не субагентом). Логика:

1. Определить, какие подразделения затронуты документом
2. Найти всех их сотрудников в сводном .xlsx
3. Выбрать старшего по иерархии
4. Распределить по согласованию и ознакомлению (правила - в approval-rules.md)

Лист ознакомления: add_notify_sheet() автоматически сортирует сотрудников по ФИО (А-Я) и устанавливает равную ширину столбцов.

Шаг 4. Применить правила формата к результатам субагента

Субагент npa-verifier возвращает сырые данные. Перед вставкой в документ проверить каждый НПА по правилам из npa-rules.md:

• Кодексы, Конституция, ГОСТы, СанПиНы - убрать реквизиты «от ... №...»
• Формат ссылки: [вид акта] [орган] от [дата] № [номер] «[название]»
• Убрать лишние заметки (редакция, регистрация в Минюсте)

Шаг 5. Описать структуру пользователю

КРАТКО описать: обоснование (какие НПА, в каком формате), тело (пункты), приложения (если есть), согласование, ознакомление.

Если есть приложения - прочитать attachment-types.md для выбора правильного типа.

Заголовок подприложения (к Положению, Программе и т.д.) не воспроизводит имя родительского документа - оно уже есть в грифе. Писать «Таблица мониторинга», а не «Таблица мониторинга Программы профилактики профессионального выгорания персонала».

Если приложения содержат столбец «Сроки выполнения» или «Сроки» - прочитать deadline-rules.md. Проверить все предлагаемые даты по производственному календарю (WebSearch) до показа структуры пользователю.

Дождаться подтверждения пользователя.

Шаг 6. Генерация .docx

Генерировать через create_ord() или кастомный скрипт (для нестандартных приложений). Подробности по API - см. helpers.md и usage-examples.md.

Шаг 7. Чек-лист

Перед выдачей документа проверить:

• Тип документа, ключевое слово и падеж согласованы
• Все ФИО проверены по списку сотрудников
• Должности указаны полностью и корректно
• НПА верифицированы, формат реквизитов корректен (исключения для кодексов и пр.)
• Кавычки - только «елочки»
• Нет длинных тире (—) в тексте (generate.py заменяет автоматически, но агент не должен их генерировать)
• Есть пункт о контроле
• Приложения оформлены корректно (если есть)

2. Стиль текста

Правила, которые generate.py не контролирует – ответственность агента:

• Официальный деловой стиль: только формальные формулировки
• Кавычки: только «елочки» (« »), не " "
• Тире: дефис (-) или среднее (–, U+2013). Длинное тире (U+2014) запрещено; generate.py заменяет его автоматически, но агент не должен его генерировать
• Запрет англицизмов: KPI - показатели результативности, дедлайн - срок исполнения, фидбэк - обратная связь, кейс - случай, ассессмент - оценка, грейд - разряд, категория
• Глаголы в пунктах: инфинитивы (Утвердить, Назначить, Возложить, Обеспечить, Провести, Организовать)
• Завершающие пункты: ознакомление и размещение скан-копии - по умолчанию НЕ включать (только по явной просьбе пользователя). Контроль - включать всегда
• Контроль: как правило, возлагается на профильного заместителя ГД. Оставлять за собой - крайне редко. Для control_person="self" в документе: «Контроль за исполнением настоящего приказа оставляю за собой.»
• Состав комиссии: всегда отдельным приложением, не в теле приказа
• Нумерация: использовать _list_para(), не вписывать номера вручную
• Запрет косой черты: не использовать «/» как разделитель слов. Вместо «приказ/распоряжение» писать «приказ, распоряжение» или «приказ или распоряжение». Допустимо: № п/п, номера документов.
• Никаких домыслов: нет данных - сообщи пользователю, не придумывай

3. Политика файлов

4. Правило согласованности

generate.py, SKILL.md и references/review-checklist.md должны быть синхронизированы. Подробности - см. references/maintenance.md.

5. Режим ревью (проверка готового документа)

Вход: готовый .doc/.docx + запрос на проверку/правку. Цель — найти всё, что не так или можно улучшить, и привести документ к эталону.

Принцип: чек-лист — это пол, а не потолок. Не запирай себя в список. Ревьюй как живой человек, у которого в голове весь накопленный корпус правил, а не только инварианты формата.

Шаг 0. Подготовка

1. Если вход .doc — конвертируй в .docx (textutil -convert docx на macOS или libreoffice --headless --convert-to docx). Дальше работай с .docx.
2. Прочитай ~/.docs-plugin/org_details.md (реквизиты-эталон, revision_author) и review-checklist.md.
3. Создай копию <имя>_правки.docx рядом с оригиналом. Оригинал не трогай.

Шаг 1. Петля 1 — холистическая (главная)

Прочитай тот же корпус правил, что и при создании такого документа (по типу и содержанию): npa-rules, basis-rules, doc-types, approval-rules, staff-rules, attachment-types, deadline-rules, amendment-rules, examples, org_details, ~/DOCX Rules.md. Затем прочитай документ и ревьюй так, будто собираешь его заново и сравниваешь. Выноси всё: логику, обоснование, верность и формат НПА (через npa-verifier), дубли, структуру разделов, формулировки, стиль, контроль (на профильного зам. ГД, не на исполнителей).

Шаг 2. Петля 2 — конформанс (страховочный пол)

Прогони инварианты review-checklist.md детерминированным скриптом (сверка XML, не через .text). Это гарантирует, что механика формата не потеряется, даже если петля 1 что-то не заметила. Объедини и дедуплицируй находки двух петель.

Шаг 3. Классификация и применение

Дели находки на два слоя (детали и принадлежность — в review-checklist.md):

• Текстовый слой (орфография, пунктуация, кавычки/тире/косая черта, даты прописью → ДД.ММ.ГГГГ, перечисление через «;» → список, ручные пробелы и переносы, формулировки): собери одним батч-предложением со списком конкретных правок. По «ОК» внеси как track-changes в <имя>_правки.docx; автор ревизий — revision_author из конфига (нет ключа — обезличенный дефолт).
• Структурный слой (реквизиты/заголовок/подписант/согласование → таблицы; разрыв страницы → раздела; Calibri → TNR в нумерации; поля; столбцы листа ознакомления; переоформление таблицы-перечня): track-changes это выразить НЕ может. Опиши в чате поэлементно, что изменится при пересборке, + обоснование. По «ОК» — пересобери через generate.py (create_ord()) в отдельный эталонный .docx.

Предложи пользователю на выбор три варианта (к каждому — опциональные комментарии):

1. Применить только текстовый слой → track-changes в <имя>_правки.docx.
2. Применить только структурный слой → пересборка в эталонный .docx.
3. Комбинированный (рекомендуй по умолчанию): применить все правки сразу — текстовые правки внести прямо в контент и пересобрать в один эталонный .docx через generate.py. В этом варианте <имя>_правки.docx с диффами не нужен: исправленный текст уже в пересобранном документе.

Содержательные правки, меняющие смысл (контроль, объединение/удаление категорий, признание утратившими силу), не вноси молча даже в комбинированном варианте — сохраняй исходный смысл и вынеси на отдельное подтверждение.

Ничего не применяй молча. Не плоди .md-отчёты — все находки и предложения в чат.