# Docs Di

> Use when the user needs a job description (должностная инструкция, ДИ) for an employee of an organization configured in ~/.docs-plugin/org_details.md. Trigger when user mentions: должностная инструкция, ДИ, написать должностную, подготовить инструкцию для должности, должностные обязанности, оформить ДИ. Covers specialist, head of department, and head of directorate positions. НЕ использовать для приказов (docs-ord), писем (docs-letter), служебных записок (docs-memo), положений о структурном подразделении (docs-polozheniya).

- Skill: `obviousbread/docs-di` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add obviousbread/docs-di`
- Raw SKILL.md: https://api.skillmd.com/api/skills/obviousbread/docs-di/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: obviousbread (https://skillmd.com/u/obviousbread)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/obviousbread/docs-di

---


# docs-di — Должностные инструкции (ДИ)

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

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

Скилл для генерации ДИ работников учреждения, реквизиты которого настроены в `~/.docs-plugin/org_details.md`. Покрывает должности: `specialist`, `dept_head`, `unit_head`. Архитектура расширяема под медицинские должности (отдельная ветка позже).

## Первый запуск

Перед первой генерацией убедиться, что `~/.docs-plugin/org_details.md` заполнен (`docs-init`).

## 0. Карта references

### Прочитать ВСЕ перед началом работы

| Файл | Что содержит | Критичные нюансы |
|------|--------------|------------------|
| `references/structure.md` | Эталонная 6-разделная структура ДИ, шаблонные формулировки, правила нумерации и оформления | Разделы — арабские. Пункты X.Y, без пропусков. Положение о СП создается через docs-polozheniya. |
| `references/tier_rules.md` | Различия между тирами (specialist, dept_head, unit_head): квалификация, иерархия 1.4-1.5, объем прав, цепочка СОГЛАСОВАНО (по ключам ролей, без ФИО) | Тир определяется по названию должности; при сомнении — спросить пользователя |
| Карточка или раздел о согласовании ДИ в пользовательском хранилище | Текущие ФИО, должности и профильные руководители | Найти через `knowledge_base_path`, если такой источник есть; перед использованием сверить с точной итоговой ДИ и актуальным `staff_file` |
| `references/profstandart-rules.md` | Поиск, валидация и извлечение содержимого из профстандартов Минтруда | Если ПС не указан — WebSearch, представить кандидатов; если указан — все равно валидировать применимость |
| `references/knowledge_base.md` | Универсальный пул для разделов 1.6 «Должен знать» и 1.7 «Руководствуется» (базовая ветка) | Накладывается снизу, поверх — специфика из ПС и Положения о СП |
| `references/quality-checklist.md` | Чек-лист обязательной фазы ревью после генерации (4 содержательных + формальная проверка) | Ревью запускается ВСЕГДА, до показа документа пользователю |

### Опционально

| Файл | Когда читать |
|------|--------------|
| `references/helpers.md` | Контракт `generate.py`: сигнатура `create_di`, формат `sections`, что генератор делает за агента (не проверять руками), что агент должен сам, низкоуровневые хелперы для кастомных сценариев |

## 1. Workflow

### Шаг 0. Прочитать references

Прочитать `structure.md`, `tier_rules.md`, `knowledge_base.md` и найденные в пользовательском хранилище сведения о согласовании ДИ — **до** уточняющих вопросов и поиска ПС. Если актуальных ФИО нет, проверить `staff_file` из `org_details.md`, затем уточнить у пользователя либо по официальному источнику.

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

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

| Параметр | Как определить |
|----------|----------------|
| Полное наименование должности | Из запроса. Если нет — спросить |
| Структурное подразделение и его место в иерархии | Из запроса или приложенных файлов (Положение). Если неочевидно — спросить (входит ли в Управление, какой замГД курирует) |
| Тир (`specialist` / `dept_head` / `unit_head`) | По наименованию должности (см. `tier_rules.md`). Если на стыке — спросить |
| Профстандарт | Из запроса. Если не указан — отложить до Шага 2 |
| ФИО работника | Из запроса. Если не указано — оставить должность вакантной (имя в «ПРОЕКТ РАЗРАБОТАН» подставит автора по умолчанию) |
| Разработчик проекта | По умолчанию — `author_position` / `author_name_short` из `~/.docs-plugin/org_details.md`. Только при явном указании пользователем — другой |

**Что спрашивать (минимальный пакет, одним блоком):**

- Полное наименование должности и СП (если из запроса не выведено).
- Иерархия СП: входит ли отдел в управление, какой замГД курирует, есть ли особенности подчинения. Спрашивать только если из контекста не выведено.
- Профстандарт (если пользователь хочет указать конкретный) — иначе скилл найдет сам и предложит.
- Опционально: разработчик проекта, если не дефолтный.

### Шаг 1а. Выбрать режим

- **Точное совпадение без изменений:** в пользовательском хранилище есть итоговая ДИ той же должности в том же подразделении и учреждении. Не генерировать документ заново: вернуть существующий оригинал по указателю карточки либо создать его копию, если пользователь просит новый файл. Если нужен только текст, извлечь раздел `## Итоговый документ` механически и без редактирования. Шаги 2–6 синтеза пропустить.
- **Изменение существующей ДИ:** взять точный финал как единственный основной текст и изменить только явно названные пользователем пункты или подтвержденные устаревшие реквизиты. Не переписывать остальные формулировки и не расширять обязанности, права или ответственность материалами из связанных документов.
- **Новая должность:** точного финала нет. Выбрать одну наиболее близкую ДИ как основной структурно-языковой прецедент, затем выполнить шаги 2–3. Положения и другие карточки использовать для фактов и функций, но не смешивать несколько ДИ в усредненный шаблон.

### Шаг 2. Поиск/валидация профстандарта

См. `profstandart-rules.md` и `web-search.md`. Если ПС не указан — WebSearch на `profstandart.rosmintrud.ru`, представить 1-3 кандидата пользователю. Если указан — валидировать (актуальность, применимость).

Зафиксировать: код ПС, наименование, приказ Минтруда (номер и дата), URL источника, выбранные ОТФ и ТФ.

### Шаг 3. Сбор контента

| Раздел | Источник |
|--------|----------|
| 1.1 | Шаблон из `structure.md` с подстановкой полного наименования должности и учреждения |
| 1.2 | Из выбранного ПС (требования к образованию, ДПО, опыту) + правила тира из `tier_rules.md` |
| 1.3 | Стандартный шаблон со ссылкой на ст. 220 ТК РФ и приказы Минздрава о медосмотрах (актуальные на момент генерации — проверить) |
| 1.4 | Шаблон из `tier_rules.md` (X — представление, Y — согласование) |
| 1.5 | Шаблон из `tier_rules.md` (X — непосредственное, Y — при отсутствии) |
| 1.6 | Универсальное ядро из `knowledge_base.md` + расширения по тиру + специфика из ПС (раздел «Необходимые знания» применимых ТФ) |
| 1.7 | Стандартный пул из `knowledge_base.md`, цепочка указаний по тиру |
| 2 | ОТФ/ТФ из ПС, переформулированные через активные глаголы |
| 3 | Трудовые действия из ПС + два обязательных завершающих пункта (охрана труда, ЧС) |
| 4 | Базовые права + надстройки по тиру из `tier_rules.md` + специфика (например, доступ к информационным системам — для должностей с ИТ-функциями) |
| 5 | Стандартный шаблон 5.1-5.6 + 5.7 для руководителей |
| 6 | Стандартный 5-пунктовый блок |

Цепочка СОГЛАСОВАНО собирается по `tier_rules.md` (ключи ролей). ФИО согласующих берутся из точной итоговой ДИ, карточки или раздела о согласовании в пользовательском хранилище и актуального списка сотрудников. При расхождении использовать наиболее свежий подтвержденный источник; неподтвержденное значение не подставлять.

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

КРАТКО показать пользователю:
- выбранный ПС (код, название, приказ),
- состав цепочки СОГЛАСОВАНО,
- ключевые ТФ из раздела 2,
- разработчика проекта.

Дождаться подтверждения. Не генерировать .docx до ОК.

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

Через `create_di()` из `generate.py`. См. сигнатуру и параметры в самом файле.

### Шаг 6. Ревью качества

См. `quality-checklist.md`. Запускается **всегда**. Если хотя бы один пункт не пройден — исправить и сгенерировать новый файл с суффиксом ` 2` (оригинал не трогать, см. правило неперезаписи подписанных).

### Шаг 7. Отчет пользователю

- Путь к файлу.
- Какой ПС использован.
- Цепочка СОГЛАСОВАНО (сводка ФИО и должностей).
- Тир.
- Любые замечания/отклонения от шаблонов.

## 2. Стиль текста (агентский)

`generate.py` сам контролирует шрифт/размер/межстрочный/отступы/выравнивание/нумерацию/маркер дашевых перечислений + автозаменяет длинное тире (`—` → `–`) и `ё` → `е`. Полный список — в `helpers.md`.

Что должен соблюдать **агент** при формировании содержимого пунктов:

- **Официально-деловой стиль:** только формальные формулировки. Активные глаголы в разделах 2-3 («осуществляет», «обеспечивает», «организует», «координирует», «выполняет»).
- **Кавычки:** только «елочки». Внутри — "лапки". Генератор не подменяет — пиши сразу правильные.
- **Слеши:** запрещены между кириллическими словами. Использовать запятые, «или», «и», скобки. Допустимо: `№ п/п`, номера документов. Генератор предупреждает через `_warn_slash`.
- **Точка с запятой:** только в перечнях. В обычных предложениях — запятая или точка.
- **Запрет англицизмов:** KPI → показатели результативности, дедлайн → срок, фидбэк → обратная связь, кейс → случай, грейд → разряд/категория.
- **Никаких домыслов:** нет данных — спросить пользователя или WebSearch, не придумывать.

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

| Тип файла | Путь | Пояснение |
|-----------|------|-----------|
| Реквизиты организации | `~/.docs-plugin/org_details.md` | Общий конфиг docs-плагина: `full_name`, `short_name`, `leader_title`, `leader_name_nom`, `author_position`, `author_name_short`, `output_dir_di`. На первом запуске — `docs-init`. |
| Библиотека хелперов | `skills/docs-di/generate.py` | Самодостаточный генератор. Не модифицировать без обновления `SKILL.md` и `references/helpers.md`. |
| Готовые документы | `<output_dir_di>/ДИ <короткая_должность>.docx` | Каталог берется из `output_dir_di` в `~/.docs-plugin/org_details.md`. Если поле пустое — файл сохраняется в текущую директорию. Если файл существует — суффикс ` 2`. |

## 4. Правила работы с пользователем

- Минимум вопросов (как в docs-ord). Один блок уточнений в начале, не цепочка.
- Не генерировать без явного подтверждения структуры пользователем (Шаг 4).
- Если ФИО согласующего не подтверждено пользовательским хранилищем или актуальным списком сотрудников, уточнить его у пользователя либо по официальному источнику; placeholder в документ не вставлять.
- При неясности тира или иерархии — спросить, не угадывать.