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 в документ не вставлять.
- При неясности тира или иерархии — спросить, не угадывать.
1---2name: docs-di3description: 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).4---56# docs-di — Должностные инструкции (ДИ)78## Пользовательский контекст910Прочитай `~/.docs-plugin/org_details.md`. Если `knowledge_base_path` заполнен и каталог существует, считай его корнем пользовательского хранилища: сначала прочитай корневые инструкции (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md` или эквивалент текущего агента), затем ищи в таком порядке: точное наименование должности, та же должность в нужном подразделении, другие должности того же тира, положение о подразделении и только затем общие материалы по функциям. Если найдена карточка той же должности, прочитай ее полностью до расширения поиска: ее итоговый текст приоритетнее общих шаблонов для квалификации, функций, обязанностей, прав, ответственности и реквизитов; используй подтвержденные формулировки дословно как основу проекта и меняй их только по требованиям текущей задачи или актуальным правилам. Связанные карточки в таком случае заполняют пробелы и подтверждают актуальные реквизиты, но не расширяют обязанности, права или ответственность без прямого требования пользователя. Читай столько карточек и связанных материалов, сколько нужно, пока новые источники перестают добавлять дословные формулировки разделов, функции, права, ответственность, авторов и согласующих. Сначала используй поле `финал` и раздел `## Итоговый документ`; предыдущие версии и связанные файлы не заменяют финал. При неоднозначности извлечения или важности формы открой оригинал по указателю карточки. Отделяй данные источника от правил скилла и собственных предложений; не выдумывай обязанности и квалификационные требования без подтверждения пользователя.1112Скилл для генерации ДИ работников учреждения, реквизиты которого настроены в `~/.docs-plugin/org_details.md`. Покрывает должности: `specialist`, `dept_head`, `unit_head`. Архитектура расширяема под медицинские должности (отдельная ветка позже).1314## Первый запуск1516Перед первой генерацией убедиться, что `~/.docs-plugin/org_details.md` заполнен (`docs-init`).1718## 0. Карта references1920### Прочитать ВСЕ перед началом работы2122| Файл | Что содержит | Критичные нюансы |23|------|--------------|------------------|24| `references/structure.md` | Эталонная 6-разделная структура ДИ, шаблонные формулировки, правила нумерации и оформления | Разделы — арабские. Пункты X.Y, без пропусков. Положение о СП создается через docs-polozheniya. |25| `references/tier_rules.md` | Различия между тирами (specialist, dept_head, unit_head): квалификация, иерархия 1.4-1.5, объем прав, цепочка СОГЛАСОВАНО (по ключам ролей, без ФИО) | Тир определяется по названию должности; при сомнении — спросить пользователя |26| Карточка или раздел о согласовании ДИ в пользовательском хранилище | Текущие ФИО, должности и профильные руководители | Найти через `knowledge_base_path`, если такой источник есть; перед использованием сверить с точной итоговой ДИ и актуальным `staff_file` |27| `references/profstandart-rules.md` | Поиск, валидация и извлечение содержимого из профстандартов Минтруда | Если ПС не указан — WebSearch, представить кандидатов; если указан — все равно валидировать применимость |28| `references/knowledge_base.md` | Универсальный пул для разделов 1.6 «Должен знать» и 1.7 «Руководствуется» (базовая ветка) | Накладывается снизу, поверх — специфика из ПС и Положения о СП |29| `references/quality-checklist.md` | Чек-лист обязательной фазы ревью после генерации (4 содержательных + формальная проверка) | Ревью запускается ВСЕГДА, до показа документа пользователю |3031### Опционально3233| Файл | Когда читать |34|------|--------------|35| `references/helpers.md` | Контракт `generate.py`: сигнатура `create_di`, формат `sections`, что генератор делает за агента (не проверять руками), что агент должен сам, низкоуровневые хелперы для кастомных сценариев |3637## 1. Workflow3839### Шаг 0. Прочитать references4041Прочитать `structure.md`, `tier_rules.md`, `knowledge_base.md` и найденные в пользовательском хранилище сведения о согласовании ДИ — **до** уточняющих вопросов и поиска ПС. Если актуальных ФИО нет, проверить `staff_file` из `org_details.md`, затем уточнить у пользователя либо по официальному источнику.4243### Шаг 1. Понять задачу4445Из контекста запроса определить:4647| Параметр | Как определить |48|----------|----------------|49| Полное наименование должности | Из запроса. Если нет — спросить |50| Структурное подразделение и его место в иерархии | Из запроса или приложенных файлов (Положение). Если неочевидно — спросить (входит ли в Управление, какой замГД курирует) |51| Тир (`specialist` / `dept_head` / `unit_head`) | По наименованию должности (см. `tier_rules.md`). Если на стыке — спросить |52| Профстандарт | Из запроса. Если не указан — отложить до Шага 2 |53| ФИО работника | Из запроса. Если не указано — оставить должность вакантной (имя в «ПРОЕКТ РАЗРАБОТАН» подставит автора по умолчанию) |54| Разработчик проекта | По умолчанию — `author_position` / `author_name_short` из `~/.docs-plugin/org_details.md`. Только при явном указании пользователем — другой |5556**Что спрашивать (минимальный пакет, одним блоком):**5758- Полное наименование должности и СП (если из запроса не выведено).59- Иерархия СП: входит ли отдел в управление, какой замГД курирует, есть ли особенности подчинения. Спрашивать только если из контекста не выведено.60- Профстандарт (если пользователь хочет указать конкретный) — иначе скилл найдет сам и предложит.61- Опционально: разработчик проекта, если не дефолтный.6263### Шаг 1а. Выбрать режим6465- **Точное совпадение без изменений:** в пользовательском хранилище есть итоговая ДИ той же должности в том же подразделении и учреждении. Не генерировать документ заново: вернуть существующий оригинал по указателю карточки либо создать его копию, если пользователь просит новый файл. Если нужен только текст, извлечь раздел `## Итоговый документ` механически и без редактирования. Шаги 2–6 синтеза пропустить.66- **Изменение существующей ДИ:** взять точный финал как единственный основной текст и изменить только явно названные пользователем пункты или подтвержденные устаревшие реквизиты. Не переписывать остальные формулировки и не расширять обязанности, права или ответственность материалами из связанных документов.67- **Новая должность:** точного финала нет. Выбрать одну наиболее близкую ДИ как основной структурно-языковой прецедент, затем выполнить шаги 2–3. Положения и другие карточки использовать для фактов и функций, но не смешивать несколько ДИ в усредненный шаблон.6869### Шаг 2. Поиск/валидация профстандарта7071См. `profstandart-rules.md` и `web-search.md`. Если ПС не указан — WebSearch на `profstandart.rosmintrud.ru`, представить 1-3 кандидата пользователю. Если указан — валидировать (актуальность, применимость).7273Зафиксировать: код ПС, наименование, приказ Минтруда (номер и дата), URL источника, выбранные ОТФ и ТФ.7475### Шаг 3. Сбор контента7677| Раздел | Источник |78|--------|----------|79| 1.1 | Шаблон из `structure.md` с подстановкой полного наименования должности и учреждения |80| 1.2 | Из выбранного ПС (требования к образованию, ДПО, опыту) + правила тира из `tier_rules.md` |81| 1.3 | Стандартный шаблон со ссылкой на ст. 220 ТК РФ и приказы Минздрава о медосмотрах (актуальные на момент генерации — проверить) |82| 1.4 | Шаблон из `tier_rules.md` (X — представление, Y — согласование) |83| 1.5 | Шаблон из `tier_rules.md` (X — непосредственное, Y — при отсутствии) |84| 1.6 | Универсальное ядро из `knowledge_base.md` + расширения по тиру + специфика из ПС (раздел «Необходимые знания» применимых ТФ) |85| 1.7 | Стандартный пул из `knowledge_base.md`, цепочка указаний по тиру |86| 2 | ОТФ/ТФ из ПС, переформулированные через активные глаголы |87| 3 | Трудовые действия из ПС + два обязательных завершающих пункта (охрана труда, ЧС) |88| 4 | Базовые права + надстройки по тиру из `tier_rules.md` + специфика (например, доступ к информационным системам — для должностей с ИТ-функциями) |89| 5 | Стандартный шаблон 5.1-5.6 + 5.7 для руководителей |90| 6 | Стандартный 5-пунктовый блок |9192Цепочка СОГЛАСОВАНО собирается по `tier_rules.md` (ключи ролей). ФИО согласующих берутся из точной итоговой ДИ, карточки или раздела о согласовании в пользовательском хранилище и актуального списка сотрудников. При расхождении использовать наиболее свежий подтвержденный источник; неподтвержденное значение не подставлять.9394### Шаг 4. Описать структуру пользователю9596КРАТКО показать пользователю:97- выбранный ПС (код, название, приказ),98- состав цепочки СОГЛАСОВАНО,99- ключевые ТФ из раздела 2,100- разработчика проекта.101102Дождаться подтверждения. Не генерировать .docx до ОК.103104### Шаг 5. Генерация .docx105106Через `create_di()` из `generate.py`. См. сигнатуру и параметры в самом файле.107108### Шаг 6. Ревью качества109110См. `quality-checklist.md`. Запускается **всегда**. Если хотя бы один пункт не пройден — исправить и сгенерировать новый файл с суффиксом ` 2` (оригинал не трогать, см. правило неперезаписи подписанных).111112### Шаг 7. Отчет пользователю113114- Путь к файлу.115- Какой ПС использован.116- Цепочка СОГЛАСОВАНО (сводка ФИО и должностей).117- Тир.118- Любые замечания/отклонения от шаблонов.119120## 2. Стиль текста (агентский)121122`generate.py` сам контролирует шрифт/размер/межстрочный/отступы/выравнивание/нумерацию/маркер дашевых перечислений + автозаменяет длинное тире (`—` → `–`) и `ё` → `е`. Полный список — в `helpers.md`.123124Что должен соблюдать **агент** при формировании содержимого пунктов:125126- **Официально-деловой стиль:** только формальные формулировки. Активные глаголы в разделах 2-3 («осуществляет», «обеспечивает», «организует», «координирует», «выполняет»).127- **Кавычки:** только «елочки». Внутри — "лапки". Генератор не подменяет — пиши сразу правильные.128- **Слеши:** запрещены между кириллическими словами. Использовать запятые, «или», «и», скобки. Допустимо: `№ п/п`, номера документов. Генератор предупреждает через `_warn_slash`.129- **Точка с запятой:** только в перечнях. В обычных предложениях — запятая или точка.130- **Запрет англицизмов:** KPI → показатели результативности, дедлайн → срок, фидбэк → обратная связь, кейс → случай, грейд → разряд/категория.131- **Никаких домыслов:** нет данных — спросить пользователя или WebSearch, не придумывать.132133## 3. Политика файлов134135| Тип файла | Путь | Пояснение |136|-----------|------|-----------|137| Реквизиты организации | `~/.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`. |138| Библиотека хелперов | `skills/docs-di/generate.py` | Самодостаточный генератор. Не модифицировать без обновления `SKILL.md` и `references/helpers.md`. |139| Готовые документы | `<output_dir_di>/ДИ <короткая_должность>.docx` | Каталог берется из `output_dir_di` в `~/.docs-plugin/org_details.md`. Если поле пустое — файл сохраняется в текущую директорию. Если файл существует — суффикс ` 2`. |140141## 4. Правила работы с пользователем142143- Минимум вопросов (как в docs-ord). Один блок уточнений в начале, не цепочка.144- Не генерировать без явного подтверждения структуры пользователем (Шаг 4).145- Если ФИО согласующего не подтверждено пользовательским хранилищем или актуальным списком сотрудников, уточнить его у пользователя либо по официальному источнику; placeholder в документ не вставлять.146- При неясности тира или иерархии — спросить, не угадывать.
obviousbread