SDS/MSDS Risk Scanner

v1.0.0

Extract hazard codes and safety info from chemical safety datasheets.

0· 82·0 current·0 all-time
byAIpoch@aipoch-ai
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
Name/description match the included code: a small local parser that extracts H- and P-codes and produces a risk level. The SKILL.md and examples imply the script will accept an input SDS file (--sds) and produce outputs, but scripts/main.py currently only implements a --demo mode and does not read the --sds file. This is a functional mismatch (missing file I/O implementation) rather than an unexplained or malicious requirement.
Instruction Scope
SKILL.md guides the agent to validate inputs, run the packaged script, and read/write workspace files. Those instructions stay within the skill's stated purpose. However, the runtime instructions expect the script to process input files while the shipped script only prints demo output; the agent may be instructed to read/write files when the code does not implement that behavior. The instructions do not ask for unrelated system files, environment variables, or external endpoints.
Install Mechanism
No install spec; script is instruction-only with a small local Python file. No downloads, third-party installers, or archive extraction are present.
Credentials
No environment variables, credentials, or config paths are requested. This is proportionate to the described functionality.
Persistence & Privilege
Skill does not request always:true and does not modify system/other-skill config. It runs locally when invoked; autonomous invocation is allowed by default but not combined with any broad privileges here.
Assessment
This skill appears to be a small, local SDS text parser and is internally coherent and low-risk as packaged. However, the shipped script is effectively a demo: it implements --demo output but does not open or process an --sds input file despite the SKILL.md examples. Before relying on this skill: 1) Review/modify scripts/main.py to implement safe file reading if you intend to feed real SDS files (open files defensively, validate/sanitize paths to prevent ../ traversal). 2) Confirm there are no network calls added later and consider running the script in a sandboxed workspace when testing. 3) Add tests for edge cases and large files, and pin any future third-party dependencies. 4) If you plan to allow autonomous agent invocation, be comfortable that the agent may read/write workspace files per the instructions — restrict the workspace and run in a controlled environment. Overall, there are no red flags for credential exfiltration or hidden endpoints, but the functional mismatch (demo-only behavior) should be fixed before production use.

Like a lobster shell, security has layers — review code before you run it.

latestvk979vk5mrwtyp6w61f0bfhza5583yy6s
82downloads
0stars
1versions
Updated 2w ago
v1.0.0
MIT-0

SDS/MSDS Risk Scanner

Chemical safety data extraction.

When to Use

  • Use this skill when the task needs Extract hazard codes and safety info from chemical safety datasheets.
  • Use this skill for evidence insight tasks that require explicit assumptions, bounded scope, and a reproducible output format.
  • Use this skill when you need a documented fallback path for missing inputs, execution errors, or partial evidence.

Key Features

  • Scope-focused workflow aligned to: Extract hazard codes and safety info from chemical safety datasheets.
  • Packaged executable path(s): scripts/main.py.
  • Reference material available in references/ for task-specific guidance.
  • Structured execution path designed to keep outputs consistent and reviewable.

Dependencies

See ## Prerequisites above for related details.

  • Python: 3.10+. Repository baseline for current packaged skills.
  • Third-party packages: not explicitly version-pinned in this skill package. Add pinned versions if this skill needs stricter environment control.

Example Usage

cd "20260318/scientific-skills/Evidence Insight/sds-msds-risk-scanner"
python -m py_compile scripts/main.py
python scripts/main.py --help

Example run plan:

  1. Confirm the user input, output path, and any required config values.
  2. Edit the in-file CONFIG block or documented parameters if the script uses fixed settings.
  3. Run python scripts/main.py with the validated inputs.
  4. Review the generated output and return the final artifact with any assumptions called out.

Implementation Details

See ## Workflow above for related details.

  • Execution model: validate the request, choose the packaged workflow, and produce a bounded deliverable.
  • Input controls: confirm the source files, scope limits, output format, and acceptance criteria before running any script.
  • Primary implementation surface: scripts/main.py.
  • Reference guidance: references/ contains supporting rules, prompts, or checklists.
  • Parameters to clarify first: input path, output path, scope filters, thresholds, and any domain-specific constraints.
  • Output discipline: keep results reproducible, identify assumptions explicitly, and avoid undocumented side effects.

Quick Check

Use this command to verify that the packaged script entry point can be parsed before deeper execution.

python -m py_compile scripts/main.py

Audit-Ready Commands

Use these concrete commands for validation. They are intentionally self-contained and avoid placeholder paths.

python -m py_compile scripts/main.py
python scripts/main.py --help

Workflow

  1. Confirm the user objective, required inputs, and non-negotiable constraints before doing detailed work.
  2. Validate that the request matches the documented scope and stop early if the task would require unsupported assumptions.
  3. Use the packaged script path or the documented reasoning path with only the inputs that are actually available.
  4. Return a structured result that separates assumptions, deliverables, risks, and unresolved items.
  5. If execution fails or inputs are incomplete, switch to the fallback path and state exactly what blocked full completion.

Use Cases

  • Lab safety training
  • Hazard communication
  • Emergency response
  • Compliance documentation

Parameters

  • sds_document: PDF or text input
  • chemical_name: Compound name

Returns

  • H-codes (hazard statements)
  • P-codes (precautionary statements)
  • Safety summary card
  • PPE recommendations

Example

Acetone → H225, H319, H336 → Flammable, irritant

Risk Assessment

Risk IndicatorAssessmentLevel
Code ExecutionPython/R scripts executed locallyMedium
Network AccessNo external API callsLow
File System AccessRead input files, write output filesMedium
Instruction TamperingStandard prompt guidelinesLow
Data ExposureOutput files saved to workspaceLow

Security Checklist

  • No hardcoded credentials or API keys
  • No unauthorized file system access (../)
  • Output does not expose sensitive information
  • Prompt injection protections in place
  • Input file paths validated (no ../ traversal)
  • Output directory restricted to workspace
  • Script execution in sandboxed environment
  • Error messages sanitized (no stack traces exposed)
  • Dependencies audited

Prerequisites

No additional Python packages required.

Evaluation Criteria

Success Metrics

  • Successfully executes main functionality
  • Output meets quality standards
  • Handles edge cases gracefully
  • Performance is acceptable

Test Cases

  1. Basic Functionality: Standard input → Expected output
  2. Edge Case: Invalid input → Graceful error handling
  3. Performance: Large dataset → Acceptable processing time

Lifecycle Status

  • Current Stage: Draft
  • Next Review Date: 2026-03-06
  • Known Issues: None
  • Planned Improvements:
    • Performance optimization
    • Additional feature support

Output Requirements

Every final response should make these items explicit when they are relevant:

  • Objective or requested deliverable
  • Inputs used and assumptions introduced
  • Workflow or decision path
  • Core result, recommendation, or artifact
  • Constraints, risks, caveats, or validation needs
  • Unresolved items and next-step checks

Error Handling

  • If required inputs are missing, state exactly which fields are missing and request only the minimum additional information.
  • If the task goes outside the documented scope, stop instead of guessing or silently widening the assignment.
  • If scripts/main.py fails, report the failure point, summarize what still can be completed safely, and provide a manual fallback.
  • Do not fabricate files, citations, data, search results, or execution outcomes.

Input Validation

This skill accepts requests that match the documented purpose of sds-msds-risk-scanner and include enough context to complete the workflow safely.

Do not continue the workflow when the request is out of scope, missing a critical input, or would require unsupported assumptions. Instead respond:

sds-msds-risk-scanner only handles its documented workflow. Please provide the missing required inputs or switch to a more suitable skill.

References

Response Template

Use the following fixed structure for non-trivial requests:

  1. Objective
  2. Inputs Received
  3. Assumptions
  4. Workflow
  5. Deliverable
  6. Risks and Limits
  7. Next Checks

If the request is simple, you may compress the structure, but still keep assumptions and limits explicit when they affect correctness.

Comments

Loading comments...