# Industrial Safety Simulator > Model safe/unsafe states and block unsafe commands by default for industrial simulation. - Skill: `authenticfake/industrial-safety-simulator` (Agent Skill) - Install (CLI): `npx skillmds@latest add authenticfake/industrial-safety-simulator` - Raw SKILL.md: https://api.skillmd.com/api/skills/authenticfake/industrial-safety-simulator/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: authenticfake (https://skillmd.com/u/authenticfake) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/authenticfake/industrial-safety-simulator --- # Skill: Industrial Safety Simulator ## Intent Ensure industrial, manufacturing, edge, shop-floor, PLC, SCADA, MES, and control-room requirements are validated through safe simulation boundaries before any real-world integration. This skill prevents generated software from treating industrial operations as ordinary CRUD workflows. ## Use when Use this skill when a REQ touches manufacturing, industrial systems, shop-floor workflows, PLC, SCADA, MES, HMI, OPC UA, Modbus, MQTT, edge gateways, sensors, actuators, alarms, safety states, production lines, maintenance workflows, or control-room UI. ## Do not use when Do not use this skill for generic enterprise software with no industrial runtime, physical process, equipment, sensor, actuator, operator, or safety implication. ## Signals - The REQ mentions industrial, manufacturing, plant, factory, shop floor, PLC, SCADA, MES, HMI, OPC UA, Modbus, MQTT, edge, sensor, actuator, alarm, maintenance, downtime, line status, operator, or control room. - The selected pack is industrial-manufacturing or industrial-solution. - The selected design profile is industrial-control-room. - Acceptance criteria include real-time status, equipment state, alarms, or operator actions. ## Required behavior - Keep real equipment integration behind explicit adapters. - Provide simulator/fake device paths for local tests. - Treat write/control actions as high-risk and require explicit approval or simulation-only behavior unless the REQ explicitly provides a safe runtime. - Model safety states explicitly where relevant: unknown, stale, degraded, alarm, stopped, manual override, and emergency. - Show stale data and telemetry age in operator-facing UI when relevant. - Document polling, latency, retry, and failure assumptions. - Separate read-only monitoring from write/control operations. - Mark real plant/equipment integration as external and non-blocking unless a safe test environment is provided. ## Forbidden behavior - Do not send commands to real equipment from generated tests. - Do not hide stale, missing, or degraded telemetry. - Do not assume all equipment states are safe or reachable. - Do not hardcode PLC/SCADA/MES endpoints, credentials, station IDs, or equipment identifiers. - Do not implement write/control actions without safety boundary and approval semantics. - Do not claim production plant readiness from simulator-only evidence. - Do not optimize for visual novelty over operator clarity and alarm readability. ## Evidence required - Simulator or fake adapter tests for industrial data and failure states. - Explicit adapter boundary for real industrial protocols or systems. - HOWTO explaining simulator/local mode and external validation mode. - Safety-state handling evidence when physical process impact exists. - Control-room UI evidence for alarm visibility, stale data, and operator readability when UI is involved. - Gate notes distinguishing simulation evidence from real integration evidence. ## Repair guidance - If code connects directly to industrial endpoints, introduce a simulator-compatible adapter. - If stale data is invisible, add timestamp/age/degraded indicators. - If write actions exist, add dry-run, approval, or disabled-by-default controls. - If tests require real equipment, replace with simulator tests and document external validation. - If UI is unclear, prioritize operator scanning, status grouping, contrast, and alarm hierarchy. ## Gate implications Gate should block promotion when: - Industrial write/control behavior lacks safety boundary. - Tests can affect real equipment. - Required simulator evidence is missing. - Stale/degraded telemetry is hidden for operator-facing requirements. - Real integration is claimed without external evidence. Gate may allow non-blocking warnings when: - Real plant validation is unavailable but simulator checks pass. - Latency/performance checks require a dedicated industrial test environment. ## Examples - A SCADA monitoring REQ uses a fake OPC UA adapter in tests and documents real endpoint configuration separately. - A control-room dashboard shows stale telemetry age, alarm severity, and degraded state. - A MES integration REQ has read-only local simulator tests and marks production connectivity as external validation. ## Non-examples - A test that writes directly to a PLC endpoint. - A dashboard that always shows green status when telemetry is missing. - A generated control action with no dry-run or approval boundary. --- # CLike Promotable KIT Enforcement Layer ## Purpose This layer makes the skill operational for CLike `/kit` generation. The goal is not to produce plausible code. The goal is to produce candidate artifacts that can be evaluated, repaired, and promoted through EVAL and GATE with minimal human rework. ## Promotable Code Obligations When this skill is selected for a REQ, the KIT must: - respect `main_module_boundary`; - respect `functional_scope` and `technical_scope`; - generate the smallest complete implementation slice; - prefer repository-native conventions over invented abstractions; - produce source files only under the target KIT source root; - produce tests only under the target KIT test root; - keep canonical `src/`, `test/`, and `tests/` read-only during candidate generation; - document any intentional limitation instead of pretending completeness; - avoid broad rewrites unless explicitly required by the REQ. ## Required Candidate Artifacts The KIT should produce or update: ```text runs/kit//src/ runs/kit//test/ runs/kit//ci/LTC.json runs/kit//ci/HOWTO.md runs/kit//docs/KIT_.md ``` If the REQ is documentation-only or policy-only, the KIT must explicitly state why source/test artifacts are not required. ## Code Shape Expectations Generated code should favor: - explicit boundaries; - dependency injection or constructor/function injection where practical; - small cohesive modules; - deterministic local behavior; - typed schemas/contracts when the stack supports them; - error paths that are visible and testable; - safe defaults; - clear adapter seams for external systems. Generated code must avoid: - hidden global state; - hardcoded environment assumptions; - silent fallbacks; - fake success; - speculative framework layers; - broad unrelated refactors; - acceptance criteria implemented only in prose. ## Test Expectations Tests must map to acceptance criteria. Prefer: - deterministic unit tests; - contract tests around adapters and payloads; - failure-path tests; - local fake/simulator tests for external dependencies; - smoke checks only when deeper tests are not possible. Avoid: - placeholder tests; - tests that only import modules when behavior is required; - tests that require production credentials; - network-dependent blocking tests unless explicitly scoped. ## LTC Expectations `ci/LTC.json` must be valid JSON and include enough information for EvalRunner or a local agent to execute checks. It should include: - target `req_id`; - lane/runtime profile when known; - blocking local commands; - optional external commands; - report paths when available; - environment-blocked status for unavailable infrastructure; - gate-relevant policy hints. ## HOWTO Expectations `ci/HOWTO.md` must be clear enough for a developer to run without guessing. It should include: - where to run commands from; - prerequisites; - local commands; - expected result; - troubleshooting; - required environment variables; - optional external validation steps; - limitations and non-goals. ## Gate Impact GATE should BLOCK promotion when this selected skill is materially violated. Blocking examples: - source is not mapped to the target REQ; - acceptance-critical behavior has no test or executable evidence; - LTC/HOWTO are missing for runnable code; - production services or credentials are required for local blocking checks; - selected capability obligations are ignored; - generated files modify forbidden canonical roots; - code claims completeness without evidence. GATE may WARN when: - optional external validation is not available but a deterministic local contract check exists; - documentation is thin but executable evidence is complete; - future hardening is correctly documented as out of scope.