tia-harness

Initialize or update the current project's AGENTS.md with the TIA harness operating guide. USE WHEN the user asks to "init / bootstrap / set up the TIA harness", "add the harness guidance to AGENTS.md", or "update the TIA harness section / refresh the harness guide in this project". Idempotent: injects the guide between stable markers and re-running only refreshes that block, never touching the project's own content. Class R (deterministic, file-only, no serve/TIA — may call only the pure tia_guide tool). DO NOT USE to drive TIA Portal or call any tia_* tool (it opens nothing), to build/verify/deploy a project (use tia.scaffold / tia.verify / tia.handoff), or to edit project content outside the harness markers.

Build a TIA project FROM a validated project-spec — the create-from-spec pipeline: subnets → devices → modules → network/IP → tag tables/tags → block shells → protection setup → compile. USE WHEN the user says "scaffold / build / create the project from this spec", "generate the TIA project", after spec.validate + spec.plan. Class M-off (offline mutation): drives the tia MCP M3/M5 tools; requires a project already OPEN (connecting is the G1 gate). Applies the verified bare-CPU protection recipe (RECIPES.md) so the result compiles clean. DO NOT USE to download/deploy (that is gated G3 → use tia.handoff), to validate or plan a spec (use tia.spec.validate / tia.spec.plan first), to interpret/repair compile errors (use tia.verify), or to open/connect a project (that is the human G1 gate).

Prepare a human-approval envelope for a GATED operation — download / CPU-STOP (G3), go-online (G4), network scan (G7), master-secret/UMAC (G6), safety/F (G5). Use when the user wants to "download / deploy / go online / commission", or after tia.verify is clean and the next step touches the physical controller. Class GATE: this skill NEVER performs the gated action — it produces the plan + planHash + exactly what the human must approve, and the precise resume call. The AI never approves, never invents a secret, never deploys F autonomously.

Initialize or update the current project's CLAUDE.md with the TIA harness operating guide. Use when the user asks to "init / bootstrap / set up the TIA harness", "add the harness guidance to CLAUDE.md", or "update the TIA harness section / refresh the harness guide in this project". Idempotent: injects the guide between stable markers and re-running only refreshes that block, never touching the project's own content. Class R (deterministic, file-only, no serve/TIA — the only MCP call it may make is the pure, offline tia_guide).

Build a TIA project FROM a validated project-spec — the create-from-spec pipeline: subnets → devices → modules → network/IP → tag tables/tags → block shells → protection setup → compile. Use when the user says "scaffold / build / create the project from this spec", "generate the TIA project", after spec.validate + spec.plan. Class M-off (offline mutation): drives the tia MCP M3/M5 tools; requires a project already OPEN (connecting is the G1 gate). STOPS before download (G3 is never autonomous). Applies the verified bare-CPU protection recipe (RECIPES.md) so the result compiles clean.

Run the offline VERIFICATION LADDER on an open TIA project — rung 1 compile (recurse the message tree; only Error blocks), rung 2 consistency + project-as-code export/diff, rung 3 simulation (future). Use when the user asks to "verify / compile / check the project builds", after tia.scaffold or any authoring change, or before tia.handoff (a clean compile is the Gd9 precondition for deploy). Class M-off: compiles via the tia MCP; repairs the known bare-CPU protection errors (RECIPES) and re-compiles. STOPS at deploy (G3 is gated).

Recommend a Siemens S7-1500/S7-1200 CPU family + variant + order number (MLFB) from an engineering need (I/O count, scan/performance, memory, communication ports, safety, redundancy, motion). Use when the user asks "which CPU / PLC should I use", gives selection criteria instead of a model, or needs a typeIdentifier for a project-spec. Deterministic heuristic over the bundled CPU reference — NO MCP. Output: recommended CPU + justification + the OrderNumber:<MLFB>/V<fw> TypeIdentifier (flagged: confirm/resolve the concrete MLFB+firmware via GET /catalog before building).

Turn a VALIDATED TIA project-spec into the ordered, named sequence of offline build operations WITHOUT mutating anything (a dry plan). Use after spec.validate passes and before tia.scaffold — when the user asks to "plan / preview / dry-run the build", or wants to see exactly what scaffolding a spec would do and in what order. Class R: runs tia_spec_validate then tia_spec_plan, both PURE (no serve, no TIA Portal). Output: the ordered M-off steps + assumptions + warnings; nothing is applied and no gate is crossed.

Validate a TIA project-spec against the JSON Schema AND the deterministic cross-field engineering rules (same-subnet, unique names, OrderNumber:<MLFB>/V<fw> format, module limits, language-by-family, and the G5 safety rule). Use BEFORE any TIA/MCP call when the user provides or edits a project-spec, asks to "validate / check / lint my spec", or before scaffolding a project from a spec. Class R (deterministic, read-only, NO MCP) — rung 0 of the verification ladder; delivers value fully offline.

Audit an EXISTING / open TIA project against the engineering baseline (optimized block access, 100% symbolic addressing, FB + instance-DB, everything typed via UDT, correct language per task, versioned library TYPEs, uniform PLCopen naming) and the verification-ladder posture. Use when the user asks to "review / audit / lint my TIA project", check best-practices / code health / maintainability, or before a handoff. Class R (READ-ONLY): reads blocks/types/tags/devices via the `tia` MCP; never mutates. Output: findings by rule + severity + location + concrete fix.

Recommend a Siemens S7-1500/S7-1200 CPU family + variant + order number (MLFB) from an engineering need (I/O count, scan/performance, memory, communication ports, safety, redundancy, motion). USE when the user asks "which CPU / PLC should I use", gives selection criteria instead of a model, or needs a typeIdentifier for a project-spec. Output: recommended CPU + justification + the OrderNumber:<MLFB>/V<fw> TypeIdentifier (flagged: confirm/resolve the concrete MLFB+firmware via GET /catalog before building). Do NOT use when the user already gave a concrete model, to validate a spec (use spec.validate), to build a plan (use spec.plan), or to audit a project (use tia.review). Deterministic heuristic over the bundled CPU reference — NO MCP.

Turn a VALIDATED TIA project-spec into the ordered, named sequence of offline build operations WITHOUT mutating anything (a dry plan). USE after spec.validate passes and before tia.scaffold — when the user asks to "plan / preview / dry-run the build", or wants to see exactly what scaffolding a spec would do and in what order. Output: the ordered M-off steps + assumptions + warnings; nothing is applied and no gate is crossed. Do NOT use to validate a spec (run spec.validate first), to actually build/apply the project (use tia.scaffold), or to audit an open project (use tia.review). Class R: runs tia_spec_validate then tia_spec_plan, both PURE (no serve, no TIA Portal).

Validate a TIA project-spec against the JSON Schema AND the deterministic cross-field engineering rules (same-subnet, unique names, OrderNumber:<MLFB>/V<fw> format, module limits, language-by-family, and the G5 safety rule). USE when the user provides or edits a project-spec, asks to "validate / check / lint my spec", or before scaffolding a project from a spec — it is rung 0 of the verification ladder, fully offline. Do NOT use to RECOMMEND a CPU (use cpu.select), to produce a build plan (use spec.plan), to audit an already-open TIA project (use tia.review), or when no project-spec is involved. Class R (deterministic, read-only, NO MCP).

Prepare a human-approval envelope for a GATED operation — download / CPU-STOP (G3), go-online (G4), network scan (G7), master-secret/UMAC (G6), safety/F (G5). USE WHEN the user wants to "download / deploy / go online / commission", or after tia.verify is clean and the next step touches the physical controller, the network, secrets, or safety. Class GATE: this skill NEVER performs the gated action — it produces the plan + planHash + exactly what the human must approve, and the precise resume call. DO NOT USE to actually perform the download/online/scan (the AI never approves, never invents a secret, never deploys F autonomously), to build a project (use tia.scaffold), or to compile/verify (use tia.verify).

Audit an EXISTING / open TIA project against the engineering baseline (optimized block access, 100% symbolic addressing, FB + instance-DB, everything typed via UDT, correct language per task, versioned library TYPEs, uniform PLCopen naming) and the verification-ladder posture. USE when the user asks to "review / audit / lint my TIA project", check best-practices / code health / maintainability, or before a handoff. Output: findings by rule + severity + location + concrete fix (recommendation only). Do NOT use to validate a project-spec offline (use spec.validate), to plan a build (use spec.plan), to run the compile/consistency ladder (use tia.verify), or to fix/ mutate anything. Requires a connected project. Class R (READ-ONLY): reads via the `tia` MCP; never mutates.

Run the offline VERIFICATION LADDER on an open TIA project — rung 1 compile (recurse the message tree; only Error blocks), rung 2 consistency + project-as-code export/diff, rung 3 simulation (future). USE WHEN the user asks to "verify / compile / check the project builds", after tia.scaffold or any authoring change, or before tia.handoff (a clean compile is the Gd9 precondition for deploy). Class M-off: compiles via the tia MCP; repairs the known bare-CPU protection errors (RECIPES) and re-compiles. DO NOT USE to download/deploy or go online (that is gated G3/G4 → use tia.handoff), to build a project from a spec (use tia.scaffold), or to "make F-logic compile" (G5 — report and defer to the human).