Template SDS Generator

Generate a deterministic, template-preserving 16-section SDS/MSDS package from 1 DOCX template, 1 prompt/rule file, and 1-3 source SDS/MSDS files, with DOCX/...

Security Scan

The skill's code, runtime instructions, and requested resources are consistent with a local, template-preserving SDS generator; nothing requests unrelated credentials or hidden remote endpoints, though it does self-bootstrap a Python virtualenv and install pinned Python packages at first run (expected for this type of tool).

Purpose & Capability

The name/description (template-preserving SDS generator) matches the files and functionality: parsers for PDF/DOCX, extraction/reconciliation, template filling, and renderers. Required binaries (python3/python/py) align with the Python-based implementation. Config files and preconditions (replace fixed_company.yml, optional OCR/PDF engines) are appropriate for the purpose.

Instruction Scope

SKILL.md and the entrypoint scripts limit activity to local processing: creating a .venv, installing dependencies, parsing supplied input files, and producing outputs under outputs/runs/... The instructions explicitly require the user-supplied template and prompt files and warn not to fabricate critical fields. There are no instructions to read unrelated system files or to send data to external APIs.

Install Mechanism

There is no platform package install spec, but the skill is self-bootstrapping: on first run it creates a .venv under the skill folder and runs pip install -r requirements.lock. This will fetch packages from PyPI (network access) and write files to the skill directory. This is expected for a Python tool but is a runtime install operation the user should be aware of.

Credentials

The skill requests no environment variables or external credentials. It optionally checks for system binaries (tesseract, soffice/libreoffice) but does not require access to unrelated secrets or config paths. The only writable locations are the skill folder (.venv, assets, outputs).

Persistence & Privilege

always:false and no special platform privileges. The skill writes its own .venv and output artifacts within its folder and does not attempt to modify other skills or global agent configuration. Autonomous invocation is allowed by default (disable-model-invocation:false) which is normal for skills.

Assessment

This skill appears coherent for its stated purpose. Before running or installing: (1) inspect/replace config/fixed_company.yml so you don't accidentally ship example contact info; (2) review requirements.lock (and optionally run install in an isolated/sandbox environment) because the skill auto-creates a .venv and will pip-install packages from PyPI; (3) ensure you have Python 3.11+ available (SKILL.md requires it) or expect runtime_doctor to report incompatibilities; (4) if you expect scanned PDFs or need PDF export, confirm tesseract and soffice/libreoffice are available on the host; (5) if you have sensitive data, run the tool in a controlled environment since it will read the input files you give it and write outputs under the skill directory. If you want higher assurance, review requirements.lock and run the code in an ephemeral VM or container before using it on production data.

Use this skill when the user wants a traceable SDS/MSDS package that must preserve a supplied Word template.

Use {baseDir} to refer to this skill folder.

Preconditions

• Before production use, replace the placeholder company block in {baseDir}/config/fixed_company.yml with the owning company's approved supplier information.
• The runtime needs Python 3.11+.
• OCR is optional. If scanned PDFs are expected, tesseract must be available on the host or in the sandbox/container runtime.
• PDF export requires soffice or libreoffice on the execution runtime.
• This package is self-bootstrapping at runtime: the Python launcher creates .venv and installs requirements.lock inside the skill folder on first use.
• ClawHub publishes text files only. The fallback base template assets/templates/sds_base.docx is generated locally on first use when it is missing.

Canonical entrypoint

Prefer the bundled cross-platform Python launcher instead of shell-only wrappers:

python3 {baseDir}/scripts/run_openclaw_skill.py --template-docx <template.docx> --prompt-file <rules.txt> --sources <source1> [<source2> <source3>] --outdir <target> --mode draft

Windows launcher variants:

py {baseDir}\scripts\run_openclaw_skill.py --template-docx <template.docx> --prompt-file <rules.txt> --sources <source1> [<source2> <source3>] --outdir <target> --mode draft
python {baseDir}\scripts\run_openclaw_skill.py --template-docx <template.docx> --prompt-file <rules.txt> --sources <source1> [<source2> <source3>] --outdir <target> --mode draft

Workflow

1. If the runtime looks incomplete, run: python3 {baseDir}/scripts/runtime_doctor.py On Windows use py or python.
2. Run the canonical entrypoint. The launcher creates or repairs .venv, installs requirements.lock, and generates a generic base template if assets/templates/sds_base.docx is missing.
3. Use --enable-ocr only when scanned PDFs are expected. If no OCR backend is available, the run fails clearly.
4. Return the generated files from outputs/runs/.../final.
5. When provenance or review details matter, inspect outputs/runs/.../audit.

Output expectations

Primary deliverables:

• final/sds_document.docx
• final/sds_document.pdf when a PDF engine is available
• final/structured_data.json
• final/field_source_map.csv
• final/review_checklist.md

Audit outputs may also include:

• audit/content_policy_report.json
• audit/ocr_audit.json
• audit/field_source_map.md
• run_manifest.json

Guardrails

• Preserve the supplied template layout. Do not clear the document body when the user provides a client template.
• Do not invent safety-critical values such as GHS classifications, UN numbers, packing groups, flash points, LD50 values, or regulatory identifiers.
• Treat structured_data.json, field_source_map.csv, and review_checklist.md as first-class deliverables alongside the DOCX/PDF.