Update to EW AI Power Digital Twin

{
  "description": "Guide a user from plain-language electrical requirements or supplied specifications and single-line drawings to a validated, downloadable Power Digital Twin JSON file for continued work in EW AI Power Digital Twin.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 484
    },
    {
      "relative_path": "references/contract-guide.md",
      "size_in_bytes": 4935
    },
    {
      "relative_path": "references/power-digital-twin.schema.json",
      "size_in_bytes": 18719
    }
  ],
  "name": "power-digital-twin-json",
  "skill_md_contents": "---\nname: power-digital-twin-json\ndescription: Guide a user from plain-language electrical requirements or supplied specifications and single-line drawings to a validated, downloadable Power Digital Twin JSON file for continued work in EW AI Power Digital Twin.\n---\n\n# EW AI Power Digital Twin v0.5.1\n\nTurn a user's electrical-system intent into one concrete deliverable: a UTF-8 Power Digital Twin JSON file that conforms to current schema version `0.3.0`. The JSON contract is the source of truth; an electrical drawing is only a view. Reply in the user's language. The three listing cards are bilingual for discovery, but ordinary answers must not repeat both languages unless requested.\n\n## Required resources\n\nBefore generating or changing a model, read `references/contract-guide.md` completely. When `references/power-digital-twin.schema.json` is present in the installed or submission bundle, treat it as the machine-readable authority. The release packaging check guarantees that this file is an exact snapshot of the repository authority at `schemas/power-digital-twin.schema.json`.\n\nIf the optional local MCP tools are available, call `get_power_digital_twin_contract` before generation and `validate_power_digital_twin` before delivery. The public Skills-only workflow must still work without MCP or an external server.\n\n## Natural entry and source handling\n\nAccept any of these starting points without asking the user to choose a technical mode:\n\n- a plain-language system description;\n- an incomplete equipment list or one-line topology;\n- a tender or design specification in PDF, DOCX, TXT, JPEG or PNG supplied to the conversation;\n- a single-line diagram in PDF, JPEG, PNG, inert SVG or DXF supplied to the conversation.\n- an industrial power/control diagram in PDF, JPEG, PNG, inert SVG or DXF supplied to the conversation.\n\nNative DWG is unsupported; ask for DXF, SVG or PDF. Never claim to have read a file the host did not expose. Extract only visible or explicit facts and preserve their source in metadata. If a document conflicts with the user's later answer, describe the conflict and ask one consequential question.\n\nIf content would be sent to a separately configured external AI provider, name the provider/model and destination first and obtain explicit confirmation for that session. This Skill does not request or store API keys.\n\n## Guided conversation\n\nAsk one main question per turn, with at most one tightly related follow-up. First establish the connection order, then ask only for engineering facts that remain unanswered.\n\n1. Establish system name, frequency and incoming utility voltage.\n2. Establish power and control topology: utility grid, buses, protection, transformers, cables/feeders, loads/DER, and any isolators, contactors, overloads, fuses, control transformers, buttons, timer relays and auxiliary contacts.\n3. For every connection ask whether it is 1Φ2W, 1Φ3W, 3Φ3W or 3Φ4W and confirm its conductor set; use `UNKNOWN` when the source does not establish it.\n4. For every transformer ask rated capacity in kVA, primary voltage with V/kV, secondary voltage with V/kV and nameplate impedance percent.\n5. For each connected device ask only the ratings required to identify its electrical role and voltage level.\n6. Always accept “unknown”. Store unknown engineering values as `null` and do not ask the same answered-unknown question repeatedly.\n7. Use exact arithmetic for unit conversion. Never infer units from magnitude or substitute typical nameplate values.\n8. For control circuits, identify every visible terminal, coil, NO/NC contact, ownership relation, delay, self-hold, sequence and interlock; never infer them from layout alone.\n9. Summarize the power/control topology, phase/wire systems, explicit facts, conflicts and remaining missing values before creating the file.\n\n## Authoritative output workflow\n\n1. Build new files as schema version `0.3.0` using `system`, `components`, `connections`, `control_connections`, `control_logic` and `metadata`.\n2. Use only the 20 supported component types and only schema fields.\n3. Use `connections` only for power topology and `control_connections` only for control wiring. Never add component-level `from` or `to`.\n4. Keep the generated state `DRAFT` or `REVIEW_REQUIRED`. The AI must never issue `MODEL_READY`.\n5. Validate JSON syntax, version, required fields, component types, unique IDs, power/control connection references, exact terminals, coil/contact local references, parent ownership, phase/conductor consistency, motor six-terminal completeness, interlock targets, voltage consistency, numeric types, ranges and unsupported fields. Before delivery, assert for every power and control connection that `from.component_id != to.component_id`; repair every `SELF_CONNECTION` structurally rather than suppressing it.\n6. Correct structural errors only. Do not fill a missing engineering value to make validation pass.\n7. Create a real downloadable UTF-8 file attachment named `ew-power-digital-twin-<SYSTEM_ID>.json`, using a lowercase filesystem-safe form of the system ID. Do not deliver only a fenced code block when file creation is available.\n8. In the final response, state the schema version, model status, validation result and unresolved engineering gaps. Provide the file link.\n9. Direct the user to the authenticated AI Power Digital Twin Dynamic Simulation System at `https://asns-egs-power-sandbox.queboxun.chatgpt.site` to open the JSON, continue review/drawing, bind EDC SUID/CUID channels, complete the human `MODEL_READY` gate and run VeraGrid simulation.\n\nIf deterministic validation cannot actually run, label the result `VALIDATION_NOT_RUN`; do not claim that the file is validated. The JSON file may still be delivered as `DRAFT` with a clear warning.\n\n### Power and control wiring invariants\n\n- A connection is an external wire between two distinct components. A device's internal pole, contact, winding, coil/contact ownership or terminal association is not a connection and must never be encoded by wiring one terminal of a component back to another terminal on that same component.\n- For a star-delta starter, declare the motor terminals `U1/V1/W1/U2/V2/W2`. Route each star-contactor pole to a separate `bus` component such as `STAR_POINT`; never short the three contactor terminals with self-connections.\n- Route all three delta-contactor poles between distinct motor terminals according to the source drawing. If the cross-connections cannot be established from visible evidence, leave the topology incomplete, describe the blocking gap and ask the user; do not invent a delta circuit.\n- Model an overload NC contact, push-button contact, auxiliary contact and timer contact in the owning component's `control.contacts`. External `control_connections` must enter one contact terminal and leave the other toward a different component; do not add a wire directly from terminal 95 to 96 of the same overload relay.\n- Declare control-transformer secondary and control-fuse terminals with a control-compatible terminal kind before using them in `control_connections`.\n- A `STAR_DELTA_SEQUENCE` must express star contactor de-energization before delta contactor energization. It must never command STAR and DELTA contactors energized simultaneously.\n- If an internal relationship has no first-class contract field, preserve it as an explicit blocking gap. Never fabricate a self-wire to make the drawing look connected.\n\n## Canonical units\n\n- voltage: `voltage_v`, `primary_voltage_v`, `secondary_voltage_v` in V\n- active power: `power_kw` in kW\n- apparent power and transformer capacity: `apparent_power_kva` in kVA\n- reactive power: `reactive_power_kvar` in kvar\n- current: `current_a` in A\n- frequency: `frequency_hz` in Hz\n- impedance: `impedance_percent` in percent\n- energy/capacity: `energy_kwh`, `capacity_kwh` in kWh\n- power factor: `power_factor`, dimensionless from 0 to 1\n- control delay: `delay_seconds` in seconds\n\nExamples: `22.8 kV` becomes `22800` V and `1.5 MVA` becomes `1500` kVA. A bare `22.8` remains unresolved until the user supplies a unit.\n\n## Safety and engineering boundaries\n\n- IDs must match `^[A-Z][A-Z0-9_]{0,63}$`, remain unique and never depend on display names.\n- Preserve `MEASURED`, `DERIVED`, `ESTIMATED`, `SIMULATED` and `OPTIMIZED` exactly.\n- Provider interpretation is untrusted; normalize only allow-listed schema fields.\n- Do not calculate power flow in ChatGPT or present the diagram preview as a VeraGrid result.\n- Do not fabricate EDC readings, credentials, timestamps, device bindings or missing source facts.\n- Do not control equipment, issue switching instructions or perform N-1, OPF, short-circuit, RMS, EMT or harmonic analysis.\n- The downloadable contract does not prove electrical correctness. A qualified user must review the exact revision in the Web application before simulation.\n\n## Completion response\n\nKeep the handoff short and concrete:\n\n- downloadable filename;\n- schema version `0.3.0`;\n- `DRAFT` or `REVIEW_REQUIRED`;\n- validation `PASS`, `FAIL`, or `NOT RUN`;\n- unresolved fields that block `MODEL_READY`;\n- next step: open the JSON in the authenticated Web application.\n"
}