← LabWiredCONTENT HISTORY

Update to LabWired

Snapshot Nov 2, 2026 · 06:11 UTC · version 1.1.1

Collection source: downloaded plugin package.

WHAT CHANGED

Instructions updated for labwired

Full description — Now says: develop an embedded hardware device: pick a board and parts, wire them, write and test firmware on a simulated microcontroller, open an interactive hardware...

Observed in instructions or declared skills. Runtime behavior has not been tested.

Save LabWired and check future changes in Following.

Up to 10 plugins free · no card required.

All fields and original values.

Full description

Before

Oct 24, 2026 · 13:12 UTC

build or test embedded firmware on a simulated microcontroller board, wire sensors or displays to it, check the result, and open an interactive hardware lab.

After

Nov 2, 2026 · 06:11 UTC

develop an embedded hardware device: pick a board and parts, wire them, write and test firmware on a simulated microcontroller, open an interactive hardware lab, import a KiCad or Altium design, lay out a PCB, price or order parts, or fl...

Skill instructions

Before

Oct 24, 2026 · 13:12 UTC

build or test embedded firmware on a simulated microcontroller board, wire sensors or displays to it, check the result, and open an interactive hardware lab. 5. Open the lab. `labwired_lab` returns an `open_url` and an inline lab widget....

After

Nov 2, 2026 · 06:11 UTC

develop an embedded hardware device: pick a board and parts, wire them, write and test firmware on a simulated microcontroller, open an interactive hardware lab, import a KiCad or Altium design, lay out a PCB, price or order parts, or fl...

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,6 +1,6 @@
 ---
 name: labwired
-description: Use when the user wants to build or test embedded firmware on a simulated microcontroller board, wire sensors or displays to it, check the result, and open an interactive hardware lab.
+description: Use when the user wants to develop an embedded hardware device: pick a board and parts, wire them, write and test firmware on a simulated microcontroller, open an interactive hardware lab, import a KiCad or Altium design, lay out a PCB, price or order parts, or flash and debug a real board.
 ---
 
 # LabWired
@@ -15,13 +15,13 @@
 2. Compose and validate. Build a diagram `{ board, parts, wires }` and run `labwired_validate`. Fix every error before continuing. It also checks whether firmware drives the pins that were actually wired.
 3. Compile. Give `labwired_compile` the source with an explicit board, language and entry path. Large projects go through `labwired_put_source` first. Use the returned `firmware_ref` in later calls. If compilation fails, show the compiler errors and fix them.
 4. Run and check. `labwired_run` is observational: it reports status, serial output and diagnosis. `labwired_verify` checks the firmware against expectations the user states (serial text, pin behaviour, display). Report the verdict and the evidence returned. Do not call something verified unless the tool returned a pass. A fault on an unmodelled peripheral is a real limit of the simulation. Report it as such.
-5. Open the lab. `labwired_lab` returns an `open_url` and an inline lab widget. Always show the `open_url`. Omit `diagram` for a starter LED blink on a board. `labwired_share` makes a link that opens the board already running.
+5. Open the lab. `labwired_lab` returns an `open_url` and an inline lab widget. Always show the `open_url`. Omit `diagram` for a starter LED blink on a board. Pass the `firmware_ref` from step 3 to replay the exact compiled firmware, and `autorun: true` for a link that opens the board already running.
 
 ## Optional
 
-- PCB: `labwired_pcb` designs a 2-layer board from a diagram, step by step, and `labwired_pcb_view` shows it. Export and comparison run through the same tool. Check DRC output before calling a layout ready. It is not a fabrication sign-off.
+- PCB: `labwired_pcb_create` starts a 2-layer board from a diagram, `labwired_pcb_auto` places and routes it, `labwired_pcb_inspect` reads ratsnest and DRC, and `labwired_pcb_view` shows it. `labwired_pcb_simulate` checks the copper against the diagram, and `labwired_pcb_export` returns fab files only after DRC passes. It is not a fabrication sign-off.
 - Cost: `labwired_price` reads live distributor prices. Treat family matches as estimates.
-- Projects: `labwired_project` saves, lists, publishes and deletes the user's projects. Confirm with the user before delete or unpublish.
+- Projects: `labwired_project_create`, `labwired_project_list`, `labwired_project_get` and `labwired_project_update` save and read the user's projects. `labwired_project_verify` records the proof that `labwired_project_publish` needs. Confirm with the user before `labwired_project_delete` or `labwired_project_unpublish`.
 - Debugging: `labwired_debug_start`, `labwired_debug` and `labwired_debug_stop` drive a debug session on the simulated target.
 - Benches: `labwired_device_*` tools talk to a physical bench the user has docked in LabWired Studio. If none is connected, say so. Do not imply hardware was touched.
 
Full technical diff · 2 changed fields

changed /description

BEFORE
"Use when the user wants to build or test embedded firmware on a simulated microcontroller board, wire sensors or displays to it, check the result, and open an interactive hardware lab."
AFTER
"Use when the user wants to develop an embedded hardware device: pick a board and parts, wire them, write and test firmware on a simulated microcontroller, open an interactive hardware lab, import a KiCad or Altium design, lay out a PCB, price or order parts, or flash and debug a real board."

changed /skill_md_contents

BEFORE
"---\nname: labwired\ndescription: Use when the user wants to build or test embedded firmware on a simulated microcontroller board, wire sensors or displays to it, check the result, and open an interactive hardware lab.\n---\n\n# LabWired\n\nLabWired runs firmware on a deterministic simulation of microcontrollers (ARM Cortex-M, RISC-V and ESP32 families) wired to simulated parts. Everything here is simulation. It is not a physical board, and a passing run is not proof the circuit works on real hardware. Say so when reporting results.\n\nTool names are prefixed `labwired_`. Read each tool's schema instead of guessing arguments. `labwired_search` finds tools by keyword, and `labwired_context` returns suggested next steps for the session.\n\n## Workflow\n\n1. Discover. Use `labwired_list` and `labwired_describe` to find the board and parts. Use exact catalog component ids. `labwired_part` and `labwired_datasheet` give pin and register facts for a part; quote what they return and note its stated assurance level.\n2. Compose and validate. Build a diagram `{ board, parts, wires }` and run `labwired_validate`. Fix every error before continuing. It also checks whether firmware drives the pins that were actually wired.\n3. Compile. Give `labwired_compile` the source with an explicit board, language and entry path. Large projects go through `labwired_put_source` first. Use the returned `firmware_ref` in later calls. If compilation fails, show the compiler errors and fix them.\n4. Run and check. `labwired_run` is observational: it reports status, serial output and diagnosis. `labwired_verify` checks the firmware against expectations the user states (serial text, pin behaviour, display). Report the verdict and the evidence returned. Do not call something verified unless the tool returned a pass. A fault on an unmodelled peripheral is a real limit of the simulation. Report it as such.\n5. Open the lab. `labwired_lab` returns an `open_url` and an inline lab widget. Always show the `open_url`. Omit `diagram` for a starter LED blink on a board. `labwired_share` makes a link that opens the board already running.\n\n## Optional\n\n- PCB: `labwired_pcb` designs a 2-layer board from a diagram, step by step, and `labwired_pcb_view` shows it. Export and comparison run through the same tool. Check DRC output before calling a layout ready. It is not a fabrication sign-off.\n- Cost: `labwired_price` reads live distributor prices. Treat family matches as estimates.\n- Projects: `labwired_project` saves, lists, publishes and deletes the user's projects. Confirm with the user before delete or unpublish.\n- Debugging: `labwired_debug_start`, `labwired_debug` and `labwired_debug_stop` drive a debug session on the simulated target.\n- Benches: `labwired_device_*` tools talk to a physical bench the user has docked in LabWired Studio. If none is connected, say so. Do not imply hardware was touched.\n\n## Limits\n\nSign-in is required. Runs have daily allowances and time limits. Peripheral models cover what the catalog lists; unsupported hardware access fails loudly. Timing in the simulation follows the model, not measured silicon. Do not paste secrets or credentials into firmware, prompts or diagrams.\n"
AFTER
"---\nname: labwired\ndescription: Use when the user wants to develop an embedded hardware device: pick a board and parts, wire them, write and test firmware on a simulated microcontroller, open an interactive hardware lab, import a KiCad or Altium design, lay out a PCB, price or order parts, or flash and debug a real board.\n---\n\n# LabWired\n\nLabWired runs firmware on a deterministic simulation of microcontrollers (ARM Cortex-M, RISC-V and ESP32 families) wired to simulated parts. Everything here is simulation. It is not a physical board, and a passing run is not proof the circuit works on real hardware. Say so when reporting results.\n\nTool names are prefixed `labwired_`. Read each tool's schema instead of guessing arguments. `labwired_search` finds tools by keyword, and `labwired_context` returns suggested next steps for the session.\n\n## Workflow\n\n1. Discover. Use `labwired_list` and `labwired_describe` to find the board and parts. Use exact catalog component ids. `labwired_part` and `labwired_datasheet` give pin and register facts for a part; quote what they return and note its stated assurance level.\n2. Compose and validate. Build a diagram `{ board, parts, wires }` and run `labwired_validate`. Fix every error before continuing. It also checks whether firmware drives the pins that were actually wired.\n3. Compile. Give `labwired_compile` the source with an explicit board, language and entry path. Large projects go through `labwired_put_source` first. Use the returned `firmware_ref` in later calls. If compilation fails, show the compiler errors and fix them.\n4. Run and check. `labwired_run` is observational: it reports status, serial output and diagnosis. `labwired_verify` checks the firmware against expectations the user states (serial text, pin behaviour, display). Report the verdict and the evidence returned. Do not call something verified unless the tool returned a pass. A fault on an unmodelled peripheral is a real limit of the simulation. Report it as such.\n5. Open the lab. `labwired_lab` returns an `open_url` and an inline lab widget. Always show the `open_url`. Omit `diagram` for a starter LED blink on a board. Pass the `firmware_ref` from step 3 to replay the exact compiled firmware, and `autorun: true` for a link that opens the board already running.\n\n## Optional\n\n- PCB: `labwired_pcb_create` starts a 2-layer board from a diagram, `labwired_pcb_auto` places and routes it, `labwired_pcb_inspect` reads ratsnest and DRC, and `labwired_pcb_view` shows it. `labwired_pcb_simulate` checks the copper against the diagram, and `labwired_pcb_export` returns fab files only after DRC passes. It is not a fabrication sign-off.\n- Cost: `labwired_price` reads live distributor prices. Treat family matches as estimates.\n- Projects: `labwired_project_create`, `labwired_project_list`, `labwired_project_get` and `labwired_project_update` save and read the user's projects. `labwired_project_verify` records the proof that `labwired_project_publish` needs. Confirm with the user before `labwired_project_delete` or `labwired_project_unpublish`.\n- Debugging: `labwired_debug_start`, `labwired_debug` and `labwired_debug_stop` drive a debug session on the simulated target.\n- Benches: `labwired_device_*` tools talk to a physical bench the user has docked in LabWired Studio. If none is connected, say so. Do not imply hardware was touched.\n\n## Limits\n\nSign-in is required. Runs have daily allowances and time limits. Peripheral models cover what the catalog lists; unsupported hardware access fails loudly. Timing in the simulation follows the model, not measured silicon. Do not paste secrets or credentials into firmware, prompts or diagrams.\n"
Full snapshot data
{
  "description": "Use when the user wants to develop an embedded hardware device: pick a board and parts, wire them, write and test firmware on a simulated microcontroller, open an interactive hardware lab, import a KiCad or Altium design, lay out a PCB, price or order parts, or flash and debug a real board.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 466
    }
  ],
  "name": "labwired",
  "skill_md_contents": "---\nname: labwired\ndescription: Use when the user wants to develop an embedded hardware device: pick a board and parts, wire them, write and test firmware on a simulated microcontroller, open an interactive hardware lab, import a KiCad or Altium design, lay out a PCB, price or order parts, or flash and debug a real board.\n---\n\n# LabWired\n\nLabWired runs firmware on a deterministic simulation of microcontrollers (ARM Cortex-M, RISC-V and ESP32 families) wired to simulated parts. Everything here is simulation. It is not a physical board, and a passing run is not proof the circuit works on real hardware. Say so when reporting results.\n\nTool names are prefixed `labwired_`. Read each tool's schema instead of guessing arguments. `labwired_search` finds tools by keyword, and `labwired_context` returns suggested next steps for the session.\n\n## Workflow\n\n1. Discover. Use `labwired_list` and `labwired_describe` to find the board and parts. Use exact catalog component ids. `labwired_part` and `labwired_datasheet` give pin and register facts for a part; quote what they return and note its stated assurance level.\n2. Compose and validate. Build a diagram `{ board, parts, wires }` and run `labwired_validate`. Fix every error before continuing. It also checks whether firmware drives the pins that were actually wired.\n3. Compile. Give `labwired_compile` the source with an explicit board, language and entry path. Large projects go through `labwired_put_source` first. Use the returned `firmware_ref` in later calls. If compilation fails, show the compiler errors and fix them.\n4. Run and check. `labwired_run` is observational: it reports status, serial output and diagnosis. `labwired_verify` checks the firmware against expectations the user states (serial text, pin behaviour, display). Report the verdict and the evidence returned. Do not call something verified unless the tool returned a pass. A fault on an unmodelled peripheral is a real limit of the simulation. Report it as such.\n5. Open the lab. `labwired_lab` returns an `open_url` and an inline lab widget. Always show the `open_url`. Omit `diagram` for a starter LED blink on a board. Pass the `firmware_ref` from step 3 to replay the exact compiled firmware, and `autorun: true` for a link that opens the board already running.\n\n## Optional\n\n- PCB: `labwired_pcb_create` starts a 2-layer board from a diagram, `labwired_pcb_auto` places and routes it, `labwired_pcb_inspect` reads ratsnest and DRC, and `labwired_pcb_view` shows it. `labwired_pcb_simulate` checks the copper against the diagram, and `labwired_pcb_export` returns fab files only after DRC passes. It is not a fabrication sign-off.\n- Cost: `labwired_price` reads live distributor prices. Treat family matches as estimates.\n- Projects: `labwired_project_create`, `labwired_project_list`, `labwired_project_get` and `labwired_project_update` save and read the user's projects. `labwired_project_verify` records the proof that `labwired_project_publish` needs. Confirm with the user before `labwired_project_delete` or `labwired_project_unpublish`.\n- Debugging: `labwired_debug_start`, `labwired_debug` and `labwired_debug_stop` drive a debug session on the simulated target.\n- Benches: `labwired_device_*` tools talk to a physical bench the user has docked in LabWired Studio. If none is connected, say so. Do not imply hardware was touched.\n\n## Limits\n\nSign-in is required. Runs have daily allowances and time limits. Peripheral models cover what the catalog lists; unsupported hardware access fails loudly. Timing in the simulation follows the model, not measured silicon. Do not paste secrets or credentials into firmware, prompts or diagrams.\n"
}

SHA-256 of public snapshot: 8b1cefc80600e60fe477aa52c63fde1c1b647aa74b7e136e9c2b8e3737a073d7