foyonaczy/aelionbot/document-writing

Document writing

Shape the document

Identify the reader, purpose, requested format, and available evidence. Lead with the answer or recommendation, then support each finding with a source, calculation, or clearly labeled assumption. For numerical claims record units, denominator, period, and comparison baseline. Match depth to the request; a short memo does not need a research-report ceremony.

Build an editable source

• For an existing DOCX/ODT, open it in Writer first. Preserve headings, numbering, tables, comments, tracked changes, and images that matter to the request. Edit a copy. Converting an existing complex file through HTML can discard these features.
• For a new simple report, copy assets/report.html into the Bot workspace and replace all sample text. It uses print styles, headings, a compact evidence table, and source notes. Open in Writer, adjust page style, and save as ODT or DOCX. It is a starting layout, not a requirement for every document.
• Prefer native Writer styles for headings, lists, tables, headers, page numbers, and section breaks. Keep tables within text width and avoid manually aligning text with spaces.
• For complex automation use python-docx only after checking availability. The baseline VM does not promise it. Writer is already available, so ordinary document work should not depend on installing a new SDK.

Export and verify

For command-line conversion, materialize aelion-pdf-workbench and run its scripts/office_export.py with --format docx or --format pdf and a new output directory. Open the editable document in Writer and inspect the PDF export for pagination, repeated table headers, widows, overflow, and font substitutions. Reopen the saved source and confirm content survived conversion.

Deliver the editable format requested by the user. A PDF is useful for a stable preview but does not replace an explicitly requested Word document. Preserve sources and uncertainty near the associated claims.

Aelion workspace and delivery

• Read incoming files with attachment_read; use attachment_save for binary files and use its returned path.
• python_execute and python_session run in the Linux work computer. file_read, file_write, file_patch, list_directory, find_files, search_files, and exec_command default to the user's selected local project; pass location vm only for the work computer under the current Bot's workspace. These are different filesystems. Never assume a host path exists in the VM. view_image reads host paths only: to look at a PNG or PDF rendered in the VM, open it in the work-computer browser with computer and inspect the screenshot. open_preview shows a file to the user; it is not a check you performed.
• Read supporting files with skill_file_read. Before running a bundled script in the VM, call skill_materialize for this skill and use its returned vmPath; quote that path in shell commands. Keep generated files in the Bot workspace, outside the materialized skill directory.
• Open Writer, Calc, Impress, or the work-computer browser with computer (action: open_app) only when this task needs that application. For an existing document, pass its workspace-relative path. Inspect screenshots before coordinate actions and use the latest returned observationId. Do not open a desktop app in place of search, web_read, file tools, or an edit in the selected host project.
• Final files belong in message_attach using attachments: [{path: "output/actual-file.ext"}]. This also works for a final group or private-chat reply. When explicitly sending a separate collaboration message, bot_send_message and group_send_message accept the same attachment entries. Attach only useful deliverables, not every intermediate preview.
• Discover an omitted tool with tool_search; use only tools actually available. A missing optional library does not justify changing VM networking or using another Bot's files. Prefer existing applications and libraries; report an actual missing dependency if no suitable route exists.