Выработка правовой позиции по делу с итогом в markdown и .docx. Используй, когда юрист просит «выработать позицию», «подготовить аргументацию», «оценить риски», «разработать стратегию» или «обновить позицию после новых документов». Ветка Ф5b: Sonnet-main оркестрирует, Opus-subagent делает анализ по контракту 3.1a, Sonnet-subagent оформляет .docx через arbitrum-docx по контракту 3.2.
Instalación
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Выработка правовой позиции по делу с итогом в markdown и .docx. Используй, когда юрист просит «выработать позицию», «подготовить аргументацию», «оценить риски», «разработать стратегию» или «обновить позицию после новых документов». Ветка Ф5b: Sonnet-main оркестрирует, Opus-subagent делает анализ по контракту 3.1a, Sonnet-subagent оформляет .docx через arbitrum-docx по контракту 3.2.
build-position — Выработка правовой позиции
Скилл следует контрактам из shared/subagent-dispatch.md. Main-Sonnet собирает контекст и проверяет структуру, Opus-subagent формирует позицию, Sonnet-subagent оформляет .docx.
при наличии — предыдущие версии в <case_root>/positions/*.md
Если .vassal/index.yaml пуст, не содержит документов, или после сверки с .vassal/mirrors/doc-*.md не осталось ни одного доступного зеркала документа, верни SKILL_UNAVAILABLE с reason no documents и остановись без создания выходных файлов.
Покажи Сюзерену preview:
какие файлы войдут в контекст;
какой предварительный номер версии виден сейчас: v{{preview_version}};
какие файлы предположительно будут созданы: <case_root>/positions/position-v{{preview_version}}.md, <case_root>/positions/position-v{{preview_version}}.docx;
что финальный vN подтверждается только в момент записи после повторного пересчёта;
что ветка идёт по 3.1a с READY_FOR_DOCX: analytical.
Дождись подтверждения.
Фаза 2 — Apply (main-Sonnet + Opus-subagent + Sonnet-subagent)
Перед любым Task(...) ещё раз проверь, что .vassal/index.yaml содержит документы и список доступных .vassal/mirrors/doc-*.md не пуст; если документов нет, верни SKILL_UNAVAILABLE с reason no documents и остановись без создания выходных файлов.
Выполни mkdir -p {{positions_dir}} до любых записей и перед повторным вычислением версии.
Собери prompt Opus-subagent по контрактам 3.0 и 3.1a:
использовать только допустимые верхнеуровневые секции:
## Фабула
## Квалификация
## Доказательства
## Схема сторон
## Риски
## Стратегия
OUTPUT: единый markdown; последняя строка строго READY_FOR_DOCX: analytical.
Вызови Task с параметрами:
subagent_type: "general-purpose"
model: "opus"
description: 3-5 слов
Проверь OUTPUT через валидационный скрипт:
передай полный текст OUTPUT Opus-subagent в
python3 "$PLUGIN_ROOT/scripts/validate_opus_output.py" --skill build-position --contract 3.1a --stdin;
скрипт должен вернуть valid=true.
Если valid=false, ровно один раз перезапусти Opus-subagent с напоминанием о контракте 3.1a, разрешённых секциях и обязательном READY_FOR_DOCX: analytical, затем повтори валидацию тем же скриптом.
Если и после retry valid=false, покажи errors и останови скилл.
Непосредственно перед записью файлов атомарно зарезервируй version:
заново определи кандидат N по фактическому содержимому {{positions_dir}}; не используй preview_version как окончательный номер;
попытайся создать sentinel-каталог {{positions_dir}}/v{{N}}.lock через mkdir; на POSIX это атомарное резервирование слота версии;
если mkdir не сработал, считай что v{{N}} уже занята другим параллельным запуском, увеличь N и повтори попытку;
только после успешного mkdir зафиксируй version = N, lock_dir, md_path и docx_path.
Сохрани markdown-оригинал как есть в {{md_path}}, не снимая {{lock_dir}} до завершения записи всех итоговых файлов.
Подготовь вызов Sonnet-subagent по контракту 3.2:
markdown_input = markdown без последней строки READY_FOR_DOCX: analytical
case_meta = поля из .vassal/case.yaml
out_dir = {{positions_dir}}
doc_name = position-v{{version}}.docx
Запусти Sonnet-subagent. Если получен SKILL_UNAVAILABLE, main-Sonnet сам вызывает arbitrum-docx.
После успешной записи и {{md_path}}, и {{docx_path}} удали {{lock_dir}}. Если после резервирования произошёл сбой до успешного завершения, удали созданный этим запуском {{lock_dir}} перед возвратом блокера.
Фаза 3 — Verify (main-Sonnet)
Проверь, что существуют:
{{md_path}}
{{docx_path}}
Прочитай {{md_path}} и проверь:
присутствует ## Схема сторон;
внутри есть блок ````mermaid```;
последняя строка строго READY_FOR_DOCX: analytical;
нет верхнеуровневых ## секций вне списка Ф5b.
Проверь {{docx_path}}:
файл существует;
файл не пустой.
Покажи Сюзерену короткое резюме:
версия позиции v{{version}};
пути к markdown и .docx;
какие секции попали в итог.
Дисциплина
Не использовать sidecar-превью.
Не генерировать .docx в обход arbitrum-docx.
Не добавлять верхнеуровневые ## секции вне списка Ф5b.
Не вставлять тексты исходников inline в prompt main-Sonnet.
Не считать номер версии окончательным на этапе preview: финальный vN резервируется только перед записью через атомарный mkdir lock-директории.
Блокер
Если Task(model=opus) недоступен, дважды возвращает невалидный markdown, или formatter-ветка 3.2 не создаёт .docx даже после fallback:
покажи Сюзерену конкретную причину;
не записывай частичный .docx;
не подменяй аналитическую часть ручной генерацией main-Sonnet.
