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

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

По умолчанию у всех абзацев, включая заголовки и ячейки таблиц, отключены «Запрет висячих строк», «Не отрывать от следующего», «Не разрывать абзац» и «С новой страницы» (widowControl, keepNext, keepLines, pageBreakBefore = 0).

Прочитай ~/.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

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

Опционально

1. Workflow

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

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

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

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

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

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

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

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

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

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

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

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

Цепочка СОГЛАСОВАНО собирается по 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. Политика файлов

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

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