---
name: university-report-writer
description: Turn a substantive Russian academic draft into final Markdown for independent review and subsequent DOCX. Use for finalizing an agreed draft or writing a report from completed work. Do not use for collecting ideas, discussing decisions or reviewing an already finished report.
---

# Academic report writer

Example Russian requests: «оформи драфт», «напиши работу по черновику»,
«подготовь финальный текст».

Shared roles and transitions: [UNIVERSITY_WORKFLOW.md](../UNIVERSITY_WORKFLOW.md).

Run in the current agent; the writer does not need a separate agent. The input draft
stores meanings and decisions and need not meet final style. Produce a saved Russian
`.md` that can be transferred to DOCX after critic approval without substantive
rewriting. Instruction language is English; preserve Russian style and literal output.

Read the [shared writer/critic core](../university-text-critic/references/report-core.md)
first. It is the single source of general style, concision, structure and Markdown
rules. If unavailable, identify the resource and stop rather than invent your own rules.

## Inputs

Use the draft, subject/topic, requirements and assigned structure, agreed decisions
and relevant previous works. Recover known information from the conversation/files;
do not ask the user to repeat it. Read selected materials completely. Prepare
unreadable formats through [file-to-markdown](../file-to-markdown/SKILL.md).

The draft may be one file, several notes or an agreed discussion. For a report after
`только артефакты`, also use the completed execution plan, verified code, notebook,
calculations, diagrams and saved results; do not demand repeated proven execution
or invent missing observations. Identify draft materials and distinguish current
decisions from rejected alternatives. Previous works need readable local copies
under the critic contract; a missing file does not mean there was no previous work.

## Work with the draft

1. Map requirements to the draft's meanings. Identify facts, decisions, arguments,
   results and important limits to preserve. This is an author check, not an added
   report section. For a substantive gap/conflict, prepare independent parts and
   ask a specific clarification. Do not guess or call incomplete text ready.
2. Build structure from the core: assigned sections take precedence; without a
   prescribed structure, create logical sections for the material. Do not preserve
   incidental note order simply because it exists in the draft.
3. Write final prose: combine scattered explanations, remove filler/repetition,
   align terms and preserve decision arguments and mandatory results. Discussed but
   unaccepted proposals must not become claims. Do not disguise contradictions with
   polished wording.
4. Save the user-selected `.md`. When DOCX is requested or the practical's basename
   is established, use matching names: `PR3.md` → `PR3.docx`. Otherwise reuse the
   existing canonical report; only if absent create `report.md` beside the draft.
   Keep the draft separately unless in-place editing was requested. Read an existing
   report before changing it and preserve user edits. With `.critic-state.json`,
   keep the registered source and existing review history.
5. Reread the saved file against the assignment, decisions and shared core. Separately
   check unconfirmed currencies/units, manually typed numbers/words generated by Word
   styles or the builder, and em dashes `—` in authored prose. For the «Просто стили»
   template, heading/figure-caption styles already number paragraphs: write substantive
   text without `1.`, `1.1.` or `Рисунок 1.1` prefixes in new Markdown. Preserve numbers
   in in-text references. Check links, tables, headings and code blocks. Remove service
   notes and gaps preventing assignment completion; fix obvious author errors before
   invoking review.

Do not edit inputs while the critic reviews them. Before post-review fixes, read the
review and state. Address concrete findings without rewriting acceptable sections.
After exhaustion of the review limit, stop automatic iterations for a human decision.

## Handoff to the critic

When final Markdown is ready, automatically continue through
[university-text-critic](../university-text-critic/SKILL.md), using its caller branch.
Pass subject, topic, requirements, previous works and decisions under its contract;
the critic does not inherit writer context. If needed, supply a readable draft to
compare decisions, explicitly as source material, not a style standard.

The critic, not the writer, must be a separate agent. Check existing approval/history
before launching. The writer does not issue `.critic-approve`, reset counters or
create DOCX during writing or between edits. Complete all substantive changes in
one canonical Markdown. Revisions reuse that file and the critic's shared limit of
three launches per review cycle; only the critic's explicit `resolve` procedure can
start another cycle. If the user requests preparation without review, save Markdown
and report that approval is absent.

Link the file and report actual status: «ожидает проверки», «одобрен критиком» or
the specific stopping reason. Author self-checking is not approval. When DOCX is
requested, hand off to [university-docx-report](../university-docx-report/SKILL.md)
only after all edits and valid approval.

## Examples

- Repetitive draft explanations with assigned «Участники», «События», «Инварианты»
  sections: retain those sections and distribute decisions accordingly. Do not
  automatically add introduction/conclusion.
- Without prescribed structure, notes cover request receipt, the main process and
  errors: group them into substantive sections, preserving rejection/recovery
  conditions. Choose headings by content, not a fixed template.
- A draft says «возможно, повторять каждые 5 секунд», but no decision is accepted.
  Do not turn it into «повтор выполняется каждые 5 секунд». Clarify the choice or
  retain the question only when unresolved questions are themselves assigned.