agentleFS
gclmgclm/super-stack/skills/core/doc/SKILL.md

doc

Skill0 starsChanged 7 months agoMITView on GitHub

Read, create, or edit `.docx` documents. Use this skill when Word document structure, formatting, tables, pagination, or rendered layout matters, and choose the lightweight text path before the full visual rendering path when layout is not the main concern.

We split this skill into the rules it gives an agent

14 rules. 0 are common, 7 are distinctive, and 7 are very specific to this project.

  • 0

    Common

    Most of the 26 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use this skill when the task involves .docx files and success depends on extracting content reliably, editing with preserved structure, or …

    line 8
  2. Distinctive:

    avoid over-installing heavy document tooling for one-off text extraction tasks

    line 19
  3. Distinctive:

    verify rendered layout visually when pagination, tables, or spacing matter

    line 21
  4. Distinctive:

    do not treat extracted text as proof that DOCX layout is correct

    line 27
  5. Distinctive:

    when the document contains tables, pagination-sensitive content, diagrams, or client-facing formatting, route to the full rendering path

    line 28
  6. Distinctive:

    prefer the user's or project's default Python environment before creating ad hoc environments

    line 29
  7. Very specific:

    only install system tools such as libreoffice and poppler when the task truly needs rendering or page-image review

    line 30
  8. Distinctive:

    if visual review is impossible, state the layout risk clearly instead of pretending the document is fully verified

    line 31
  9. Very specific:

    Read references/task-routing.md and classify the task.

    line 35
  10. Distinctive:

    Run a quick environment preflight for Python and DOCX/PDF rendering tools.

    line 36
  11. Very specific:

    If the task is text extraction, prefer python-docx for structured text reads.

    line 37
  12. Very specific:

    If the task is editing or rendering-sensitive, use python-docx for edits and render the result through soffice plus page-image checks when …

    line 38
  13. Very specific:

    Use scripts/render_docx.py when you need a stable local render helper for page review.

    line 39
  14. Very specific:

    Keep intermediate artifacts in tmp/docs/ and final repo outputs in output/doc/ when working inside a repository.

    line 40

“Common” is measured: kept by at least 6 in 10 of the 26 edited versions of this file we could read. “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

DOCX

Use this skill when the task involves .docx files and success depends on extracting content reliably, editing with preserved structure, or validating rendered layout.

Read First

  • the target .docx files
  • references/task-routing.md to choose between lightweight text extraction and full rendering review
  • harness/state.md if the task is part of an ongoing project workflow
  • harness/history.md if it exists

Goals

  • choose the lightest DOCX workflow that still answers the user request correctly
  • avoid over-installing heavy document tooling for one-off text extraction tasks
  • preserve structure and formatting when editing DOCX files
  • verify rendered layout visually when pagination, tables, or spacing matter

Rules

  • first classify the task as either lightweight text extraction or full DOCX review/editing
  • for content extraction, summaries, field reads, or quick checks, prefer the lightweight path
  • do not treat extracted text as proof that DOCX layout is correct
  • when the document contains tables, pagination-sensitive content, diagrams, or client-facing formatting, route to the full rendering path
  • prefer the user's or project's default Python environment before creating ad hoc environments
  • only install system tools such as libreoffice and poppler when the task truly needs rendering or page-image review
  • if visual review is impossible, state the layout risk clearly instead of pretending the document is fully verified

Process

  1. Read references/task-routing.md and classify the task.
  2. Run a quick environment preflight for Python and DOCX/PDF rendering tools.
  3. If the task is text extraction, prefer python-docx for structured text reads.
  4. If the task is editing or rendering-sensitive, use python-docx for edits and render the result through soffice plus page-image checks when needed.
  5. Use scripts/render_docx.py when you need a stable local render helper for page review.
  6. Keep intermediate artifacts in tmp/docs/ and final repo outputs in output/doc/ when working inside a repository.
  7. Report which workflow path was used, what dependencies were required, and what evidence supports the result.

Output

Tell the user:

  • which DOCX workflow path was used: lightweight text extraction or full DOCX review/editing
  • which dependencies or tools were available, missing, or installed
  • whether layout fidelity was actually verified visually
  • where any output files were written
  • any remaining evidence gaps such as unverified pagination, scanned assets, or missing render tooling

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.

Reviews can't be read right now.

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.