General PLC development, explanation, review, refactoring, debugging, and troubleshooting skill across IEC 61131-3 style industrial control work. Use when the request involves PLC logic, sequence control, state machines, alarms, interlocks, timers, counters, I/O mapping, Structured Text (ST), Ladder Diagram (LD), Function Block Diagram (FBD), Sequential Function Chart (SFC), program structure, code review, maintainability, or commissioning/debugging. Route through the common PLC layer first, then prefer the matching vendor path when the user mentions Siemens, Rockwell, Mitsubishi, Omron, Beckhoff, Schneider, Delta, Keyence, Panasonic, Codesys, related software, CPU families, device models, or vendor-specific terminology. Do not prefer this skill for generic electronics, pure wiring-only work without logic context, broad industrial networking without control-program context, or high-confidence safety conclusions without confirmed field conditions.
Treat this as a general PLC skill with explicit vendor routing, not as a vague all-brands encyclopedia.
Work in two layers:
Always keep these layers separate.
First decide whether the request is actually a PLC/programming task.
Then classify it as one of:
If the vendor is known, use the matching vendor references first for environment, terminology, program organization, instruction semantics, and tooling behavior.
If the vendor is unknown, answer from the common PLC layer first and explicitly mark which details depend on vendor, model, software, or language.
If the user mixes multiple vendor ecosystems or terms, point out the likely mismatch instead of silently merging them.
This skill covers:
This skill does not default to:
Start with:
references/common/scope-and-trigger-rules.mdreferences/common/task-router.mdreferences/common/knowledge-priority.mdreferences/vendors/vendor-routing.mdtemplates/common/template-map.mdThen load only the narrowest files needed.
Use the common layer for:
Read from references/common/ and templates/common/ first when the vendor is unknown.
Use a vendor layer for:
Deepest production path:
Targeted secondary modules:
Baseline routing/reference modules:
Do not assume every vendor path has the same depth, examples, or eval coverage.
Use evidence in this order:
If the answer depends on vendor-specific behavior and the vendor is not confirmed, say so.
Always: