# Docs Ord

> Use when the user needs an organizational directive document: order (приказ), directive (распоряжение), or instruction (указание) with an organizational header, preamble and directive section such as ПРИКАЗЫВАЮ. Trigger when user mentions: приказ, распоряжение, указание, ОРД, написать приказ, подготовить распоряжение, издать указание, внести изменения в приказ, commission order, or a separate order approving another document. НЕ использовать для самостоятельного Положения о структурном подразделении с собственным грифом УТВЕРЖДАЮ, согласованием и листом ознакомления — это docs-polozheniya. Also trigger in REVIEW mode when the user supplies an existing order/directive (.doc/.docx) and asks to review, check, proofread or fix it: ревью приказа, проверь приказ, поправь приказ, вычитай приказ, отрецензируй приказ, посмотри приказ.

- Skill: `obviousbread/docs-ord` (Agent Skill, multi-file: 16 files)
- Install (CLI): `npx skillmds@latest add obviousbread/docs-ord`
- Raw SKILL.md: https://api.skillmd.com/api/skills/obviousbread/docs-ord/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: obviousbread (https://skillmd.com/u/obviousbread)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/obviousbread/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

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

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

| Файл | Что содержит | Критичные нюансы |
|------|-------------|------------------|
| `npa-rules.md` | Формат реквизитов НПА, верификация через WebSearch, действия при ненахождении | **Исключения из формата:** кодексы (ТК РФ), Конституция, ГОСТы, СанПиНы указываются БЕЗ реквизитов «от ... №...». Субагент `npa-verifier` этого не знает и вернет полные реквизиты - главный агент обязан отфильтровать |
| `basis-rules.md` | Правила блока обоснования (вводная часть до ключевого слова) | Обоснование не заканчивается запятой. Ключевое слово на отдельной строке после пустой строки |
| `~/.docs-plugin/org_details.md` | Реквизиты, шапка, подписант, дефолтные согласующие, структура учреждения | Должность подписанта берется ТОЛЬКО отсюда. Правило для подразделений и филиалов - уточнить у пользователя |

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

| Файл | Когда читать | Критичные нюансы |
|------|-------------|------------------|
| `doc-types.md` | Если тип документа не приказ (распоряжение, указание) | Падежи: приказ, указание - дательный (кому), распоряжение - винительный (кого). Закрывающие пункты распоряжения тоже в винительном |
| `staff-rules.md` | При включении ФИО в документ | Сверка сотрудников НЕ делегируется субагенту. Делать самостоятельно через openpyxl. Формат ФИО: «Фамилия И.О.» в теле, «И.О. Фамилия» в подписи руководителя |
| `approval-rules.md` | При формировании листов согласования и ознакомления | Минимальный уровень для согласования - не ниже зам. ГД. Начальники отделов и управлений идут в ознакомление, не в согласование |
| `attachment-types.md` | Если документ содержит приложения | Каталог 10+ типов. Состав комиссии ВСЕГДА отдельным приложением |
| `deadline-rules.md` | Если приложение содержит столбец сроков (план, программа, график, дорожная карта) | Конкретные даты DD.MM.YYYY вместо кварталов. Проверка по производственному календарю |
| `amendment-rules.md` | Если приказ о внесении изменений | Полное переизложение приложения (не текстовое описание правок) |
| `examples.md` | Для подбора формулировок обоснования | Примеры со ссылками на НПА в корректном формате |

### Справочные

| Файл | Когда читать |
|------|-------------|
| `helpers.md` | При написании кастомного скрипта (API хелперов generate.py) |
| `usage-examples.md` | При написании скрипта (примеры вызова create_ord) |
| `review-checklist.md` | В **режиме ревью** (раздел 5): чек-лист конформанса эталону generate.py — пол, а не потолок |
| `maintenance.md` | При изменении generate.py (правило синхронизации) |

## 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. Понять задачу

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

| Параметр | Как определить |
|----------|----------------|
| Тип документа | Из контекста. Если не приказ - прочитать `doc-types.md`. Если неясно - спросить |
| Приложения | Из контекста. Если неясно - спросить |
| Реквизиты | Номер и дата - пропуски; сроки - из запроса |

**Что НЕ спрашивать:**
- **НПА** - субагент ищет автоматически
- **Основания для издания** - нет в запросе - нет в документе

**Что спрашивать:**
- **Контроль** - обязательный вопрос (если не указан явно)
- **До 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. Политика файлов

| Тип файла | Путь | Пояснение |
|-----------|------|-----------|
| Библиотека хелперов | `skills/docs-ord/generate.py` | Переиспользуемый код. Не модифицировать без обновления SKILL.md |
| Временные сценарии | `/tmp/<название>.py` | Одноразовые сборочные сценарии; не сохранять в пользовательском конфиге |
| Готовые документы | `{output_dir_ord}/<название>.docx` из `~/.docs-plugin/org_details.md` | Выходные файлы |

## 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`-отчёты — все находки и предложения в чат.