@vention/vention-skills 0.10.0 → 0.10.2

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vention",
-  "version": "0.10.0",
+  "version": "0.10.2",
   "description": "Vention skills for coding agents: write MachineLogic applications, build machine designs, and diagnose deployed machines.",
   "author": {
     "name": "Vention"

package/README.md

@@ -1,6 +1,6 @@
 # Vention skills
 
-Version 0.10.0. Skills for coding agents that work with Vention machines, packaged as one plugin, `vention`, in the `vention-skills` marketplace.
+Version 0.10.2. Skills for coding agents that work with Vention machines, packaged as one plugin, `vention`, in the `vention-skills` marketplace.
 
 | Skill                       | What it does                                                                                                                         |
 | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vention/vention-skills",
-  "version": "0.10.0",
+  "version": "0.10.2",
   "description": "Vention skills for coding agents: write MachineLogic applications, build machine designs, and diagnose deployed machines.",
   "license": "MIT",
   "type": "module",

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "vention",
-  "version": "0.10.0",
+  "version": "0.10.2",
   "description": "Vention skills for coding agents: write MachineLogic applications, build machine designs, and diagnose deployed machines.",
   "author": {
     "name": "Vention"

package/skills/vention-design/SKILL.md

@@ -3,7 +3,7 @@ name: vention-design
 description: Create, build and edit Vention machine designs and design graphs for agentic layout. Use when the user wants to start a new design, lay out an automation cell, add or reposition components in a Vention design, generate a machine layout from a description, add or place a floor plan image under a design, list a design's versions, or inspect an existing design graph. Trigger on MachineBuilder designs, design graphs, assembly graphs, extrusions, actuators, robot mounting, cell footprints, floor plans, or a machine-builder URL.
 license: MIT
 metadata:
-  version: "0.10.0"
+  version: "0.10.2"
   author: Vention
 ---
 

package/skills/vention-machine-logic/SKILL.md

@@ -3,7 +3,7 @@ name: vention-machine-logic
 description: Write, edit, validate, and deploy MachineLogic Python applications for Vention machines with the machine-logic-sdk and the Vention CLI. Load it before writing or changing any Python that talks to a Vention machine, however short, since device names and version-specific SDK calls come from here. Use to program a Vention machine or MachineMotion controller, drive actuators, conveyors, robots, pneumatics, or digital I/O, change an existing application, build a state machine, debug from logs, or pull, push, or link with the Vention CLI (vention or vn). Trigger on MachineLogic, machine-logic-sdk, MachineMotion, MachineBuilder applications, the Vention CLI, or a directory holding .machine-code-app-directory-info.json. Printing what the machine or robot holds now (positions, taught targets, calibration, I/O) is a program: files on disk hold only as-designed values. Not for explaining an existing machine or its configuration in words when no program is asked for, nor for Python that never touches the machine.
 license: MIT
 metadata:
-  version: "0.10.0"
+  version: "0.10.2"
   machine-logic-sdk: ">=3.0,<4"
   author: Vention
 ---
@@ -200,9 +200,9 @@ machine.on_mqtt_event("cell/commands", on_command)
 
 ## Taught robot positions
 
-`vention pull` also writes `.vention-design-scene-assets.json` when the design has taught positions. It is the list `machine.get_scene()` loads, one record per position or frame: its `type` names the getter that reads it (`RobotWaypoint` is `get_cartesian_target`, `RobotJointPosition` is `get_joint_target`, `RobotCalibrationFrame` is `get_calibration_frame`, `ReferenceFrame` is `get_reference_frame`) and `parameters.name` is the name to pass, character for character. Read it before naming a target. When a step needs a position the file does not hold, ask the user to teach it on the design; never map a missing step onto a target that happens to exist.
+`vention pull` also writes `.vention-design-scene-assets.json` when the design has taught positions. It is the list `machine.get_scene()` loads, one record per position or frame: its `type` names the getter that reads it (`RobotWaypoint` is `get_cartesian_target`, `RobotJointPosition` is `get_joint_target`, `RobotCalibrationFrame` is `get_calibration_frame`, `ReferenceFrame` is `get_reference_frame`) and `parameters.name` is the name to pass, character for character. Read it before naming a target, and copy each name as written even when its neighbours are cased differently: `"Pick approach"` and `"Drop Approach"` can sit in the same design. When a step needs a position the file does not hold, ask the user to teach it on the design; never map a missing step onto a target that happens to exist.
 
-Positions taught on the design live in the scene under their friendly names. Drive off those names rather than copying pose numbers out of a pendant into the source. `movel` holds a straight line in Cartesian space; `movej` interpolates the joints and can swing the tool sideways on the way, so a lift off a part or an approach that has to come straight down is `movel`.
+Positions taught on the design live in the scene under their friendly names. Drive off those names rather than copying pose numbers out of a pendant into the source. `movel` holds a straight line in Cartesian space; `movej` interpolates the joints and can swing the tool sideways on the way, so the short final move onto a part or into a fixture, and the lift back out, is `movel`. Reach the approach point itself with `movej`: a long straight line can turn the wrist through a singularity or a joint limit, and it sweeps a different path near the machine.
 
 ```python
 scene = machine.get_scene()
@@ -241,12 +241,13 @@ Each example is a standalone `main.py` whose module docstring names the device n
    ```
 
 2. Run `uv venv --python 3.10 && uv pip install -r requirements-dev.txt`, then `.venv/bin/pyright`. The venv runs the target's Python and the SDK the application pins, so a wrong name or signature shows up against what the target runs. The first pyright run may download Node if none is on the PATH, so a slow or offline first run is not a type error. Fix every error and run it again until it is clean.
-3. If `uv` is missing or the install fails, tell the user the code is unvalidated. Never report a check you could not run as passed.
-4. `vention push`, then run the application on the digital twin from MachineBuilder before any hardware run. One or two full cycles prove the cycle; each extra one costs a cycle time and shows nothing the first two did not.
-5. Read the output with `vention logs` once the run ends, rather than following it while the cycles play. `vention logs` prints only the most recent lines, so a count of matching lines can stop rising before the run ends. To wait for a cycle or a step, sleep once for its known cycle time, then read `vention logs` once. Never loop over `vention logs` waiting for a line to appear, and never end your turn while a background wait is running. MachineLogic failures name the device and the reason; read the log before proposing a change.
-6. Check a motion from the log, not by watching the twin: `print` the robot's joint angles or the axis position at each step, then compare them with what the step should reach. For a repeated or oscillating motion, such as a wave, print the joint angles at each end of the swing, so the log alone shows how far it moved and which joints moved.
-7. Pressing the emergency stop on the digital twin's pendant does nothing, so skip that test there. Tell the user the e-stop path is untested until the first run on the real cell.
-8. Show the user the diff before pushing over an application they did not write in this session.
+3. pyright cannot check a name passed as a string. Check every name passed to `get_*` and `move_to_target*` with a case-sensitive `grep -F '"<name>"'` against `.vention-design-configuration.json` or `.vention-design-scene-assets.json`, and fix any that does not match exactly.
+4. If `uv` is missing or the install fails, tell the user the code is unvalidated. Never report a check you could not run as passed.
+5. `vention push`, then run the application on the digital twin from MachineBuilder before any hardware run. One or two full cycles prove the cycle; each extra one costs a cycle time and shows nothing the first two did not.
+6. Read the output with `vention logs` once the run ends, rather than following it while the cycles play. `vention logs` prints only the most recent lines, so a count of matching lines can stop rising before the run ends. To wait for a cycle or a step, sleep once for its known cycle time, then read `vention logs` once. Never loop over `vention logs` waiting for a line to appear, and never end your turn while a background wait is running. MachineLogic failures name the device and the reason; read the log before proposing a change.
+7. Check a motion from the log, not by watching the twin: `print` the robot's joint angles or the axis position at each step, then compare them with what the step should reach. For a repeated or oscillating motion, such as a wave, print the joint angles at each end of the swing, so the log alone shows how far it moved and which joints moved.
+8. Pressing the emergency stop on the digital twin's pendant does nothing, so skip that test there. Tell the user the e-stop path is untested until the first run on the real cell.
+9. Show the user the diff before pushing over an application they did not write in this session.
 
 ## Deploying to a real cell
 
@@ -262,13 +263,13 @@ The controller keeps its own scene. Positions re-taught on the pendant and the c
 This code drives physical machinery that can injure someone.
 
 - Before a run on real hardware, tell the user plainly what will move and how far.
-- Recommend a low-speed dry run before production speeds.
+- Give an application that will run on hardware a speed setting that scales every move, and start its first run low.
 - Never remove, bypass, or work around an emergency stop, safety interlock, light curtain, door switch, or speed limit, and never suggest doing so, even temporarily, even for testing. If a safety device is blocking a program, say so and stop.
 - Never write code that starts motion automatically on power-up unless the user has explicitly asked for it and confirmed the cell is guarded.
 
 ## Common mistakes
 
-- Device names that do not match `.vention-design-configuration.json`.
+- Device or target names that do not match `.vention-design-configuration.json` or `.vention-design-scene-assets.json` character for character.
 - Answering with code in the reply instead of writing `main.py` to disk.
 - Commanding absolute moves before homing.
 - Calling a move without a `MotionProfile`, or passing jerk to a continuous move (it is ignored with a warning).

package/skills/vention-machine-logic-hmi/SKILL.md

@@ -3,7 +3,7 @@ name: vention-machine-logic-hmi
 description: Build or edit the custom operator HMI of a MachineLogic application, the React touch screen in customui/ that runs in MachineBuilder and on the MachineMotion pendant, wired to the application's Python process through vention-communication. Use when the user asks for an operator screen, a custom HMI or UI, a touch panel, start and stop buttons, live machine state on screen, or recipes an operator picks, for a Vention machine or inside a directory holding .machine-code-app-directory-info.json. Uses @vention/machine-ui, @vention/machine-apps-components and @vention/machine-logic-ui-sdk. Do not use for the no-code HMI Builder, or for the Python motion logic alone (that is vention-machine-logic).
 license: MIT
 metadata:
-  version: "0.10.0"
+  version: "0.10.2"
   author: Vention
 ---
 
@@ -151,7 +151,7 @@ The machine-apps-components README is behind its code: `NavigationBar` takes `Na
 ## Design rules
 
 - Wrap the app in `machineUiHmiTheme`.
-- Give the app an Operate page at `/`, any setup pages it needs (such as Recipes), and a Logs page: a `LogsPanel` fed by the Events stream, as the example's `logs-page.tsx` does, where the operator finds out why a cycle faulted. Nav labels name the page and never echo a top-bar action, and their icons don't suggest one. Never "Run", "Start" or a play icon: beside the top bar's Start, the operator reads it as a second Start button.
+- Give the app an Operate page at `/`, any setup pages it needs (such as Recipes, and a Settings page holding the speed setting of an app that runs on hardware), and a Logs page: a `LogsPanel` fed by the Events stream, as the example's `logs-page.tsx` does, where the operator finds out why a cycle faulted. Nav labels name the page and never echo a top-bar action, and their icons don't suggest one. Never "Run", "Start" or a play icon: beside the top bar's Start, the operator reads it as a second Start button.
 - The Operate page is what the operator watches during a run, so it reads from across the cell. Copy the example's `operate-page.tsx` and adapt it rather than starting from a blank page. While a run is on, show from top to bottom: the step in progress named inside a ring that fills against the last cycle's time, beside the recipe and the cycles done and rate; the cycle's steps as a row of tiles, the current one lit; and the run's progress bar. The example is part of this skill, so open and copy it even when the user says not to copy code from their computer: copy its StepRing, StepRail and CycleProgress as they are, and publish the step and the cycle's elapsed time on the status stream as its enter_step method does. A single `VentionProgressBar` cannot mark the cycles a Stop cancels. Below them go the settings for the next run (disabled while one runs) and one short paragraph on what Start and Stop do. Leave out what the operator can neither change nor act on, such as axis stops, taught positions or device names, here and in the Start confirmation: they are the program's constants, not the run's. Lay it out with `Box` or `Stack` gaps, each readout a label above its value in theme text variants. Never set `fontSize` or `lineHeight`: a value sized by hand overlaps its label.
 - Show each piece of information in one place only. The `StatusTopBar` already shows the state, so a page never repeats it, not even as a status indicator or an alert titled with the same word. A page adds only what the bar cannot say: the cause of a fault, what happens next, what to do.
 - The screen fits the pendant without scrolling: keep `body { margin: 0 }` from the example's `index.html`, or the full-viewport root overflows it. Only the page area between the two bars scrolls.
@@ -181,10 +181,10 @@ The HMI drives physical machinery that can injure someone.
 - Start never fires on page load, on reconnect, or from a stream message. Only an operator's tap, confirmed in a modal, starts motion.
 - Start and Stop live in the `StatusTopBar`, so they are on every page. Do not repeat them on a page. Raise the bar above `theme.zIndex.modal`, as the example's `app.tsx` does, or an open `VentionModal` covers Stop.
 - Stop stays enabled unless the station is known to be ready or already stopping. That includes while the stream is disconnected: a dropped stream may hide a moving machine. Every other command is disabled while disconnected.
-- A tap on Stop shows at once. While the station stops, the Stop button reads "Stopping…", the Operate page's progress bar marks where the run now ends (the cycle in progress amber, the cancelled ones hatched and struck through), and a line by the heading says the emergency stop halts at once. Say it on the screen the operator already watches rather than in a separate alert.
+- A tap on Stop shows at once. While the station stops, the Stop button reads "Stopping…" (derive that label from the streamed state and `connected`, as the example's `isStopping(status, connected)` does, never from a tapped flag alone: once the stream drops it reads "Stop" again and stays pressable), the Operate page's progress bar marks where the run now ends (the cycle in progress amber, the cancelled ones hatched and struck through), and a line by the heading says the emergency stop halts at once. Say it on the screen the operator already watches rather than in a separate alert.
 - Send Start with a `timeoutMs` and an abort signal, and abort it when the stream drops. A Start the operator can no longer see must not land later; say it was not confirmed and to check the station.
 - The HMI never offers a way around an emergency stop, safety interlock, light curtain or guard, not even a hidden one for testing.
-- The confirmation for anything that starts motion names what will move, not its positions or stops. The button itself can just say Start.
+- The confirmation for anything that starts motion names what will move and the speed setting it will move at, not its positions or stops. The button itself can just say Start.
 
 ## Complete example
 

package/skills/vention-monitoring/SKILL.md

@@ -3,7 +3,7 @@ name: vention-monitoring
 description: Diagnose deployed Vention machines from controller state, history, health, and activity data. Use when the user reports a machine that is down, faulted, offline, slow, or underperforming, asks why a cycle time regressed, wants to interpret MachineMotion event data or drive and brake status, asks about OEE or uptime, or wants to know which machine in a fleet needs attention. Trigger on a MachineMotion serial number plus any complaint.
 license: MIT
 metadata:
-  version: "0.10.0"
+  version: "0.10.2"
   author: Vention
 ---