Update to PCBKit

{
  "description": "Design, change, check, route, share, order and export printed circuit boards (PCBs) with PCBKit, and write and simulate their firmware. Use when the person asks for a circuit board, a PCB, a device with a program (a game, a timer, a sensor display), a breakout or carrier board, or to change, move, label, route, check, analyse, share, order or export one for fabrication or KiCad.",
  "included_files": [],
  "name": "pcbkit-boards",
  "skill_md_contents": "---\nname: pcbkit-boards\ndescription: Design, change, check, route, share, order and export printed circuit boards (PCBs) with PCBKit, and write and simulate their firmware. Use when the person asks for a circuit board, a PCB, a device with a program (a game, a timer, a sensor display), a breakout or carrier board, or to change, move, label, route, check, analyse, share, order or export one for fabrication or KiCad.\n---\n\n# Circuit boards with PCBKit\n\nPCBKit's tools write a board in PCBKit (a small board language with units), place and route it,\ncheck it and export it. The person watches the board beside the conversation (in a terminal or an\nIDE: on the live page `board.open` links to): every part, track and analysis appears there as you\nwork. Work so that what they see is a story: a first board within a minute, then one visible step\nat a time, each told in a sentence.\n\n## Tools\n\nSeven areas — `help` (learn), `design` (write the source, build, check), `board` (the built board:\nread it, change one thing, show it to the person), `parts`, `analysis`, `lab` (firmware),\n`project` (export, share, order) — and `board.open`. `design.edit { path, edits }` here means the\ntool `design` called with `{ op: \"edit\", why: \"…\", path, edits }`. **Every call says `why`**: one\nsentence the person reads on their board while it runs, in their terms (\"Putting the crystal\nbeside the MCU to keep its traces short\"); what the call names (`id`, `ids`, `net`) lights up\nthere. A tool lists its ops and their required fields; `help { command: \"board.move\" }` gives one\nop's whole input. `help { topic: \"quickstart\" }` has the practice every board follows (finish,\npower, sensors, numbers, connectors, devices, ordering): read it before the first design.\n\n## The loop\n\n1. **Build at once, or ask once.** Before the first design, sort what the wish leaves open. A gap\n   any sensible default fills is yours: build now and name the defaults in the answer. A figure the\n   person left out of a part they named (a named motor's current, a sensor's accuracy, a cable's\n   length) is such a gap. A wish that says only what a gadget does (a light that comes on in the\n   dark, an electronic die, a plant that says when it is thirsty) is built at once: USB power, a\n   common sensor, your MCU, each named. A gap that decides the board is the person's: what it\n   drives or reads (\"a motor controller\" with no motor, \"a few sensors\" with none named), a supply\n   it must live on (a robot's or a car's battery and its noise), how it talks and how far (no Wi-Fi\n   out there: radio band, range, battery), how many inputs or outputs a tool for their work has\n   (keys, channels, relays). A wrong guess there is a board to throw away, so do not build yet:\n   answer with one short message, the three or four questions that change the design, each with the\n   default you would take, and the trade-off that decides most of it in a sentence (a remote one:\n   sleep current against battery life). Once they answer, build; a choice still open is a default\n   you state. A part that misses one figure is the closest one, named in the answer; a chip the\n   registry lacks is read from its datasheet in the same turn.\n2. **Write the whole first design in one call:** `help { topic: \"quickstart\" }` (a complete board,\n   every block and registry part), then `help.describe { ids: [...] }` for the blocks and\n   `parts.use { ids: [...] }` for the chips you use (one call each; `parts.use` answers the\n   design's text: no need to read it), then\n   `design.write { path: \".pcbkit/design.pcbkit\", text, build: true }`: blocks and parts joined by\n   nets, no coordinates. `build: true` places, routes and checks in the same call.\n3. **Open it:** `board.open` once per conversation, right after the first design; it follows every\n   later change by itself, the person's included. Where the host draws no board (Codex, Claude\n   Code), its answer is the live page's link: give it in your answer, once. Never call it again.\n4. **Fix** what the build's answer spells out with `design.edit { …, build: true }` (one call\n   changes and builds; `design.check` only when it says there are more). A build keeps the copper that\n   still matches and routes only what is new or broken. The engine's own placement and copper\n   are yours to redo (`design.run { all: true }`) without asking; ask only before redoing what the\n   person placed or routed themselves. Never end a turn on errors the build names: do what it says\n   (`soft(…)`, a named zone such as `area(.bottom)` instead of a box of coordinates, fewer `far`s)\n   and build again. `design.diagnose { id: \"GND\" }` says why a connection does not fit and the one\n   thing to do.\n5. **Celebrate** the first complete check with `board.tour` (a short camera tour, once per board),\n   and make it orderable: `parts.select {}` picks a real, stocked part for every component (the\n   board is not ready for a factory without them); name the parts it could not find and fix them\n   (`parts.alternatives { id }`, `parts.select { pin }`) before calling the board ready.\n6. **Report in a sentence or two**, in plain words, by the board's name, never with ids: the numbers\n   that matter (size, a blinker's on and off times) and what you saw (`board.snapshot {}` once per\n   turn after parts moved). A complete check is not the review: name what\n   `analysis.run { lens: \"ready\" }` still has to fix or to consider. Offer two or three next steps (`help { topic: \"guide\" }` has the\n   ladder: make it theirs, move things, add features, make it sturdy, grow it, order it).\n7. **Each further request is one small change** with `build: true` (`design.edit`, `board.move`,\n   `board.set`, …) and the same short report. The view goes to what you changed by itself; to show\n   something else, `board.camera { ids }`; what the person asks to see, `board.look { view, layers, theme, panel }` and the other `view` ops do.\n\n## Be honest\n\nSpeak to the person about their board: never about this skill, the tools, their rules or how\nyou were told to work.\n\nThe check is not a review: name connections that did not route and why, never call a board ready\nwhen its check is not `complete` or the review has errors left, and ask the person to review the\ndesign before ordering.\n"
}