The Skills Editor

The Skills Editor is where you open one skill, edit its code and metadata, fill in its inputs, and run it on its own against a world. It is the screen for practising a single skill in isolation, without a workflow around it.

This page describes the screen. To learn how to write a skill, read Authoring a Skill.

How you get here

Two routes:

• The Skills Editor entry in the sidebar.
• The Practice Skill tile on the Home screen.

Both land on the same screen. The page heading reads Skills Editor.

The top bar

Everything that selects what you are working on, and everything that runs it, lives in one bar across the top.

Skill

A searchable dropdown labelled Skill. It lists the skills in the project by name, sorted alphabetically. While the list is loading the dropdown is disabled and reads Loading...; once loaded, the empty state reads Select skill. Typing filters the list. The search box reads Search skills... and, when nothing matches, the dropdown shows No skills found.

The last entry in the list is Add New Skill, shown in blue with a plus icon. Choosing it replaces the dropdown with a text box (placeholder Enter skill name...) plus a Save and a Cancel button. Save stays disabled until you type a name. It creates the skill from blank templates and selects it. Cancel puts the dropdown back.

If loading a skill fails, a red message appears to the right of the dropdown with the error text.

World

A searchable dropdown labelled World listing the worlds in the project by name, with a Load button beside it. The dropdown reads Loading... while the list is fetched and Select world... when nothing is chosen; the search box reads Search worlds... and the empty state reads No worlds available.

A world is preselected for you when the list arrives, and it is your project's active world, the one recorded in project.json. If you arrived here from another screen carrying a world with you, that wins; if the project names no active world, or names one that no longer exists, you get the first in the list.

Choosing a world in the dropdown does not load it. Load does. It clears whatever is currently in the scene, loads the selected world, and refreshes the list of objects that the Inputs tab offers. Both the dropdown and Load are disabled while a run is in progress.

Execution world

A dropdown showing where the skill will run.

While a run is in progress the dropdown is disabled everywhere, with the tooltip "Cannot change execution world during active execution".

Reset

Reset returns the arms to their watching positions. It does not restore a saved world state and it does not reload the selected world, so objects you have moved stay where they are.

It needs two things before it will do anything: a skill selected, and the execution world set to Simulation. On a local install the execution world starts on Real Hardware, so Reset arrives greyed out and stays that way until you switch. In the cloud the value is forced to Simulation, so only the skill selection matters.

Reset Variables

Reset Variables clears the shared variable store that skills read and write between runs, so values left behind by an earlier run do not leak into the next one. While it is working the button label changes to Resetting…. It is disabled while a run is in progress.

Sim, Pause, Stop

The run controls swap in and out depending on what is happening:

• Sim is shown when nothing is running. It runs the selected skill with the values from the Inputs tab. It is disabled until you have selected a skill and that skill has finished loading. If the run fails to start you get an alert with the error.
• Pause appears in amber while the skill is running.
• While the skill is paused, one or more resume buttons appear. The default is a green Resume. A skill can advertise its own named resume actions, and each one renders as its own amber button carrying that name.
• Stop appears in red for as long as the skill is running or paused, and cancels the run.

Panel layout

Below the top bar the screen is split into two panels with a draggable divider between them. Drag the divider to change the split.

Left: Simulator

Headed Simulator, with the tooltip "Real-time preview of skill execution in the selected world". At the top right of the panel is a gizmo toggle that reads Hide Gizmos or Show Gizmos depending on its current state, and turns the on-screen frame markers off and on.

Most of the panel is the live 3D viewport, showing the world the skill is executing against.

Right: the editor

The right panel is a set of three tabs.

The tabs

The tab strip holds Inputs, Code, and Metadata. Selecting a skill switches you to Inputs; with no skill selected you sit on Code. The Inputs tab is disabled until a skill is selected and its metadata has loaded.

Inputs

The values passed to the skill when you press Sim. The form is generated from the skill's parameters, so it changes completely when you pick a different skill.

Each parameter renders as its name, a red asterisk if it is required, its description underneath if it has one, and a control chosen by its type:

• object: a dropdown of the objects in the currently loaded world, with the placeholder Select object.... Workspace boundaries and the table are filtered out of this list, so they never appear as choices.
• string: a single-line text box, with the parameter's default shown as placeholder text.
• float: a number box accepting decimals.
• int: a number box stepping in whole numbers.
• boolean: a checkbox, with the name to its right.
• Anything else: a text box, with the type shown in brackets after the parameter name.

A parameter arrives pre-filled only when its default is a plain literal. A default the platform cannot evaluate, such as = DEFAULT_SPEED or = np.zeros(3), and a literal = None are both read as no default: the box arrives empty with no placeholder, and the parameter is left out of what is sent to the run. Write literals for anything you want pre-filled.

Switching skills reseeds the whole form from the new skill's declared defaults, and drops anything the new skill does not declare, so a value typed for one skill can never leak into another's run. Values you have typed survive flipping to Code or Metadata and back. For a normal skill, whose parameters come from its Python signature, editing the metadata does not disturb them either.

Change the function's signature in Code and save, and the form follows: the new parameters appear and the run uses them, rather than the signature as it was when the skill was last loaded.

If the selected skill takes no parameters, the tab shows a single line: No parameters defined for this skill.

The object dropdown lists the world that is currently loaded. If it is empty or stale, press Load in the top bar.

Code

A Python editor over the skill's code, with line numbers, word wrap, and a minimap.

Metadata

A YAML editor over the skill's metadata, laid out the same way. This is the description, the parameter declarations, and the rest of the skill's definition. See Skills metadata.yaml for what belongs in it.

Saving

Code and Metadata each have their own save button in a strip above the editor: Save Code and Save Metadata. Each saves only its own file. While a save is in flight the label reads Saving....

Both buttons are disabled until a skill is selected, and stay disabled in a read-only reference project.

The strip also carries a one-line banner reporting the outcome of the last save. It shows one of three things:

• Green. The save succeeded and the change was committed to your project. This banner clears itself after about three seconds.
• Amber. A warning. The edit was saved, but it was not committed to the project, so it exists only in this session and will not reach your other tools. The banner text carries the reason. It stays on screen until you dismiss it.
• Red. The save failed. Nothing was written. The banner text carries the error, and it stays until you dismiss it.

Amber and red banners have a close control at the right end. Starting another save clears whichever banner is showing.

The strip at the bottom

Below the editor is a collapsible strip. Click its header to open it. It has two tabs, and the header names whichever one is showing.

Arm State

A live readout of both arms: a Left and a Right row, each carrying that arm's tool centre point and joint angles. A badge beside the heading reads Sim or Real to match the execution world, so you always know which arms you are reading.

The header carries a Refresh button and an Auto switch that re-reads once a second while it is on. Both appear only while the strip is open, because a collapsed strip is not polling. If the feed goes stale the numbers dim rather than sitting there looking current.

This is the practical way to pin down a pose you want to hard-code: drive the arm where you want it, then copy the numbers out of here. See Skill authoring patterns.

Console Logs

Your skill's own output, live, while it runs.

Anything the skill writes with print_log() appears here as it happens. You do not have to pass runlog=True, and you do not have to opt in: writing print_log("...") the way you already would is enough to watch a skill think.

• Before a run: Run a skill to see its console output.
• During one, with nothing printed yet: Console output will appear here as the skill runs.
• The header shows a running count of entries, and a Download .txt button that gives you the whole run log as a file. It stays disabled until a run exists.

The tab stays pointed at the last run rather than clearing when the run ends, which is the point: the output is usually what you want to read once the thing has finished. Starting the next run replaces it.

Two limits worth knowing. Output is capped at 2000 lines, after which one entry tells you the rest was dropped. And this is a Skills Editor feature: a workflow run does not stream plain print_log output, so use runlog=True for anything a scientist needs to see during a workflow. See Skill state and logging.

Next