Update to LabWired
Snapshot Nov 2, 2026 · 06:11 UTC · version 1.1.1
Collection source: downloaded plugin package.
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.
Up to 10 plugins free · no card required.
All fields and original values.
Full description
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.
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
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....
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 JSONSKILL.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
"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."
"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
"---\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""---\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