docs-init — Инициализация docs

Gemini CLI: use native Gemini file and shell tools. Read and write ~/.docs-plugin/org_details.md explicitly.

Codex: use native Codex file tools. Read and write ~/.docs-plugin/org_details.md explicitly.

0. Карта references

Алгоритм

1. Проверить наличие org_details.md

Прочитай файл ~/.docs-plugin/org_details.md.

Если файл существует: загрузи его содержимое в контекст и сообщи:

docs: реквизиты организации загружены.

На этом работа скилла завершается. Не задавай лишних вопросов.

Если файл не существует: переходи к шагу 2.

2. Первый запуск — настройка реквизитов

Сообщи пользователю:

docs требует настройки реквизитов организации. Они сохранятся в ~/.docs-plugin/org_details.md и не пропадут при обновлении. Пройдем по полям - это займет минуту.

Прочитай references/org_details.md.example — он содержит все необходимые поля.

Задай вопросы блоками (не по одному полю за раз):

Блок 1 — Организация:

• Полное наименование (как в ЕГРЮЛ, в кавычках-«ёлочках»)
• Полное наименование в родительном падеже (для положений о подразделениях)
• Краткое наименование (аббревиатура)
• Юридический адрес (с индексом)
• Телефон и факс
• Email, ОКПО, ОГРН, ИНН/КПП

Блок 2 — Руководитель:

• Должность
• Должность в родительном и творительном падежах (для положений о подразделениях)
• ФИО в именительном падеже (напр.: И.О. Фамилия)
• ФИО в родительном падеже (напр.: И.О. Фамилии)

Блок 3 — Автор документов (от чьего имени готовятся):

• Должность
• ФИО кратко (Фамилия И.О.)
• ФИО полностью
• Телефон
• Автор правок для режима ревью (revision_author) — имя, как в Word; проставляется автором track-changes. Можно пропустить (тогда обезличенный дефолт).

Блок 4 — Визирующие по умолчанию (для ОРД, можно пропустить):

• До 3 визирующих: ФИО + должность каждого

Блок 5 — Список сотрудников (можно пропустить):

• Полный путь к сводному .xlsx или каталогу с датированными сводными списками (напр. ~/Documents/Списки сотрудников). Каталог рекомендуется при использовании docs-staff-list: потребители автоматически выберут самый свежий сводный. Используется для проверки ФИО и должностей при генерации документов.

Блок 6 — База знаний (можно пропустить):

• Полный путь к корню Obsidian vault или другого пользовательского хранилища. Отдельный путь к правилам не нужен: скиллы читают корневые инструкции самого хранилища.

Блок 7 — Пути вывода: Укажи папки для каждого типа документов:

• Папка для ОРД (приказы, распоряжения, указания)
• Папка для писем
• Папка для служебных записок
• Папка для должностных инструкций (ДИ)
• Папка для положений о структурных подразделениях
• Папка для протоколов совещаний

Если пользователь явно отказывается указывать пути, предупреди:

Без указания папок все документы будут сохраняться в домашнюю директорию (~/). Рекомендую указать папки сейчас — потом можно изменить через docs-init.

После предупреждения спроси ещё раз. Если пользователь снова отказывается — оставь поля пустыми и продолжи.

3. Записать org_details.md

После получения ответов сформируй файл ~/.docs-plugin/org_details.md по структуре из references/org_details.md.example, подставив введенные значения вместо плейсхолдеров {{...}}. Если блок 5 пропущен — оставь staff_file пустым. Если блок 6 пропущен — оставь knowledge_base_path пустым. Если пользователь отказался от блока 7 — оставь поля output_dir_* пустыми. Строки не удалять.

Используй инструмент Write для создания файла.

Сообщи пользователю:

docs: реквизиты сохранены в ~/.docs-plugin/org_details.md. Файл сохраняется при обновлении.

4. Обновление реквизитов

Если пользователь запросил обновление (а не первичную настройку), спроси, что нужно изменить или добавить.

Прочитай текущий org_details.md, покажи нужные значения и обнови только выбранные поля. Для смены базы знаний меняй knowledge_base_path; отдельный конфиг со свободным контекстом не создавай.