agentleFS
alexgrebeshok-coderalexgrebeshok-coder/dirigent-skills/skills/docx-ru/SKILL.md

docx-ru

Skill0 starsChanged 4 months agoMITView on GitHub

Use when creating, editing, or exporting Russian business documents (docx/pdf) — proposals (КП), memos (справка), reports (отчёт), letters (письмо), memoranda, contract appendices, counterparty document packages. Триггеры (RU) — «сделай docx», «оформи документ», «деловой текст», «собери комплект», «выгрузи в word/PDF». Always applies a fixed Russian business formatting standard: Times New Roman, black text, Russian terminology, «Оглавление» (not "Table of Contents"), a pre-send checklist. Do NOT use for analytical/DD documents with semantic table formatting — use docx-analytical-ru.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. KondrashovDenis/claude-md-docx-skill★ 2same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository9 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always: run this after pandoc:

    line 49
  2. Distinctive:

    Verify the table of contents:

    line 57
  3. Distinctive:

    If the file has already been hand-edited (newer timestamp than its md source) → make targeted edits only, don't rebuild from scratch.

    line 65
  4. Distinctive:

    Document packages: keep uniform formatting across every file in the set.

    line 67
  5. Very specific:

    Document packages: a folder Package_{description}_{DD.MM.YYYY}/.

    line 83
  6. Distinctive:

    Gate: only send to chat / a counterparty after the checklist is green.

    line 104
  7. Distinctive:

    Add a disclaimer for legal-adjacent content at the end: "аналитика, не юридическое заключение" ("analysis, not a legal opinion").

    line 128

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Russian business documents (DOCX/PDF)

Read this skill in full before assembling any docx. Terminology details and checklists: references/delovoy-stil-i-oformlenie.md.

Hard rules

  1. Table of contents — always «Оглавление», never "Table of Contents".
  2. Font — Times New Roman, body text 12 pt, color black (RGB 0,0,0). Headings — same font, 14–16 pt bold is fine, but no "font zoo" of sizes within one document.
  3. Language — documents for people/counterparties use Russian only. Replace English legal/business jargon (see the terminology table in the reference). Latin script is fine in URLs, contract numbers, and abbreviations (tax authority names, statute references).
  4. Units — ₽/м³, м³, т/км (Cyrillic «м», not Latin m). Check for homoglyphs after pandoc.
  5. Hand-edited files win — if a docx has already been edited by hand (its file timestamp is newer than the source md), do not overwrite it from the md. Copy it as-is.
  6. Nothing internal leaks into the final file — a finished docx must not contain: "internal note", "draft", "do not send", "hardline/compromise variant" labels, fallback markers, negotiation notes.
  7. Beauty = readability — structure, tables, a summary up top, explanations for figures; never "just run pandoc and ship it".
  8. Exception — analytical documents without a table of contents: comparative analysis, due diligence, explanatory notes, partner profiles → use the docx-analytical-ru skill instead (pandoc without --toc, plus format_analytical_docx.py).

Document types

TypeStructureTone
Memo / rationale / calculationSummary → sections → tables → appendicesFor a business partner: facts, scenarios, assumptions stated explicitly
Letter to a counterpartyLetterhead → body → numbered appendicesSoft, no ultimatums or hard deadlines
Appendix to a letterHeading "Appendix N…" → body onlyNo other letter's letterhead, no list of someone else's appendices
Contract / addendumNumbered clauses, legal registerNo conversational quoting style

Summary heading for Russian-language external documents: «Резюме для партнёра» / «Резюме», not "Executive summary".

Workflow: md → docx

pandoc "INPUT.md" -o "OUTPUT.docx" \
  --toc --toc-depth=3 \
  --metadata=toc-title:"Оглавление" \
  --metadata lang=ru-RU

Always run this after pandoc:

python3 scripts/normalize_docx.py "OUTPUT.docx"

The script sets Times New Roman 12 pt, black text, fixes common homoglyphs and English terms, and optionally sets an appendix heading.

Verify the table of contents:

pandoc "OUTPUT.docx" -t plain | rg "Оглавление|Table of Contents" | head -5

Workflow: editing a finished docx

  1. If the file has already been hand-edited (newer timestamp than its md source) → make targeted edits only, don't rebuild from scratch.
  2. Otherwise: edit via python-docx, or md → pandoc → normalize_docx.py.
  3. Document packages: keep uniform formatting across every file in the set; count appendix pages via LibreOffice → PDF.

PDF

pandoc "INPUT.md" -o "OUTPUT.pdf" \
  --toc --toc-depth=3 --metadata=toc-title:"Оглавление" \
  --pdf-engine=xelatex \
  -V mainfont="PT Serif" -V lang=ru-RU -V geometry:margin=2.5cm

Fallback: docx → soffice --headless --convert-to pdf.

Naming and placement

  • Name: {Type}_{Description}_{DD.MM.YYYY}.docx (+ _DRAFT / _FINAL / _CONFIDENTIAL where needed).
  • Document packages: a folder Package_{description}_{DD.MM.YYYY}/.
  • Where the finished file lands is a project convention — route it per your own document-store rules.

Pre-send checklist (chat / counterparty delivery)

Formatting

  • Times New Roman, black, ~12 pt, tables not misaligned
  • «Оглавление», not "Table of Contents"
  • ₽/м³, м³ — Cyrillic; no m³ / ₽/m³

Text

  • No English legal jargon (take-or-pay, make-up, fallback…)
  • No internal notes or negotiation-track labels
  • Business register consistent with your own house style guide (see the reference file)
  • Letters: soft tone, no ultimatums; appendices numbered, page counts stated

Content

  • Figures and cross-references are consistent across the whole document package
  • Statute/regulation references double-checked (no stale or wrong article numbers)
  • Price basis stated (e.g. incoterm / delivery point) — otherwise a margin figure is meaningless

Gate: only send to chat / a counterparty after the checklist is green. A short ✅/⚠️/🔧 report in the message or a separate note.

Markdown source (for analytical content)

---
title: "..."
subtitle: "..."
date: "DD.MM.YYYY"
audience: "..."
---

# Резюме для партнёра

**Задача:** ...
**Вывод:** ...

---

# 1. ...
  • Tables — markdown; complex calculations — separate "check" / "comment" columns.
  • Number sections for long documents (# 1., # 2.…).
  • Add a disclaimer for legal-adjacent content at the end: "аналитика, не юридическое заключение" ("analysis, not a legal opinion").

Related skills

  • docx-analytical-ru — due diligence, comparative analysis, partner memos (no TOC, bordered tables)
  • pptx — visual QA for slide decks, if you also build a companion presentation

If pandoc fails

Show stderr. Don't stay silent. Don't hand over a half-assembled file.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.