菜单
MUST READ before creating or moving any operator (create_op, copy_op, set_op_position, or execute_python builds). Required verification, canonical positioning recipe, and error-checking steps.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/dylanroscover/Embody --skill create-operator命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
MUST READ before first MCP tool call in a session. Complete Envoy tool catalog with parameters and usage.
Procedure for preparing version release commits -- changelog, README, templates, versioning
Merge or compare two divergent TouchDesigner .tox/.toe binaries that git cannot three-way-merge. Load when a merge/rebase conflicts on a .tox or .toe, when asked to merge, port, reconcile, or diff two versions of a TD component, or when comparing a component across branches, machines, or TD builds.
正在显示 SKILL.md
基于 SOC 职业分类
| name | create-operator |
| description | MUST READ before creating or moving any operator (create_op, copy_op, set_op_position, or execute_python builds). Required verification, canonical positioning recipe, and error-checking steps. |
Follow these steps every time you create operators via MCP:
/ one run, /project1 the next). The fix is to anchor on the user's own structure, which is stable across runs -- not on a transient pane:
/local or /local/* -- volatile storage, not saved with the .toe.Embody COMP. execute_python with result = op.Embody.parent().path. Embody in /project1 -> build in /project1; Embody at the root / -> build at /. It returns the SAME home every run -- this is the consistency mechanism, and it is the level the user chose by placing Embody there.ui.panes.current.owner.path) -- UNLESS that pane is sitting at the bare root / (a non-deliberate default, e.g. right after the project opens), in which case ignore it and use the Embody home above. Never treat bare / as a content home.query_network on -- never hardcode (it may be renamed, and there may be more than one).//project1query_network on the target parent to confirm it exists and see existing operatorsget_network_layout on the parent COMP. Note each operator's nodeX, nodeY, nodeWidth, and nodeHeight — operators vary in size (100–300+ units wide)create_op with the desired type and nameset_op_position to place it at the pre-computed grid position. Auto-placement is NOT acceptable — it produces messy, unreadable networks. You MUST explicitly position every operator you create. Moving a host via set_op_position carries its docked companions along (re-hugged below the new spot, reported as docks_moved), so position the host FIRST and any deliberately-placed dock after.create_op, copy_op, and set_op_position auto-hug every docked op in a tight row ~30 units below its host (docks_placed / docks_moved in the result) — do not re-plan grid slots for them. Ops created inside execute_python get NO such placement at create time (Envoy only auto-hugs badly scattered docks after the call, with a LAYOUT WARNING); if you create dock-spawning ops (GLSL TOP/MAT, execute DATs, OSC in/out) in a script, place their docks yourself per the Docked companion layout formula below.connect_ops to wire inputs/outputs. Wires must flow left-to-right (positive X). If a wire would go backward, the downstream op is misplaced — reposition it.cam) or relative paths (../shared/lut) — NEVER absolute paths (/project1/scene/cam). See parameters.md § OP-Reference Parameter Values.get_network_layout again. Confirm no overlaps, grid alignment is intact, signal flows left-to-right, and every entry carrying dockedTo sits in a tight row just below its named host (docked ops are the one exception to 200-grid spacing — they hug).get_op_errors with recurse=true to check for errors and warnings. Fix all errors before considering the task completecapture_top and confirm it actually renders (not black) and matches intent; for a 3D render, confirm a camera, a light, and geometry display/render flags are present. For anything but a trivial op, load the /visual-aesthetics skill to judge composition/value/color/contrast.A freshly created geometryCOMP ships with a default torus1 SOP inside, render flag ON. The moment you add your OWN geometry to that COMP -- a SOP chain, a POP chain terminating in a nullPOP, or imported geometry -- delete torus1 (or turn OFF its render flag). It is the RENDER flag (purple) that selects a SOP for the Render TOP, so leaving it on draws BOTH: your geometry AND a phantom torus. It is easy to miss: adding your own SOP auto-clears the torus's DISPLAY flag (blue, exclusive per viewer) so the SOP / geometry viewer looks correct, while its RENDER flag (non-exclusive) stays on and keeps drawing it in the render output. Applies to EVERY geometryCOMP you populate, not just POP builds. (TDN import already strips these auto-created defaults, so this bites only live create_op builds -- which is why it shows up in some projects and not others.)
size + gap, BOTH axes, ALWAYS -- never a fixed step. This is the #1 overlap bug: stepping by a constant (e.g. nodeY - 100, nodeX + 300) while the tiles are bigger than the step (a 134-tall node stepped by 100 overlaps by 34). The step MUST be computed from the ACTUAL node extent on that axis plus a gap, then snapped up to the grid:
next_x = prev_nodeX + prev_nodeWidth + gap (gap >= 200), rounded up to the next 200 multiple.next_y = prev_nodeY - (prev_nodeHeight + gap), rounded so the step clears the tile. For a stack of same-size tiles: step = ceil((maxNodeHeight + gap) / 200) * 200 and place tile i at y = -i * step. A 134-tall stack -> step = 200 (66 gap); a 260-tall stack -> step = 400. Bigger nodes => bigger spacing, mechanically.size + gap), NEVER a flat 200. 400 units vertical minimum between parallel chains or annotation groups (widen when tiles are tall). Y increases upward; new rows go downward.nodeX than each operator feeding it. The classic mistake: placing a source at the SAME nodeX as its destination (directly above or below) -- the source's output then sits right of the dest's input and the wire loops back. Place each source so its right edge (nodeX + nodeWidth) is left of the destination's nodeX. If a wire bends backward, move the downstream op right or the source left.rightmost_nodeX + rightmost_nodeWidth + 200, snapped); a parallel chain goes DOWN (lowest Y in group - 400). Don't fill a gap mid-row of a finished chain.get_network_layout to verify.Operators that reference each other belong near each other, even with no wire or dock: a MAT beside the Geometry COMP it shades; a camera and light(s) near their Render TOP; a CHOP/DAT that drives parameters by reference near the op it drives; any COMP named in an op() call, expression, or material slot near the op that references it. Rule of thumb: if op A names op B, a reader should see both without scrolling.
Buttons/fields/containers inside an align-driven panel (Container/Button laid out verttb/horizlr) render by their align + order pars, so their nodeX/nodeY are cosmetic to the UI -- BUT they still get network tiles, and a verttb container full of 134-tall buttons stepped by 100 overlaps in the editor exactly like data-flow ops do. Apply the same size + gap stepping to panel-widget tiles (stack by panel order); it never affects the rendered panel. This is the one layout class the LAYOUT WARNING lint does NOT police -- it is on you to tidy.
Hosts that dock: execute/callback DATs (chopExecuteDAT, datExecuteDAT, panelExecuteDAT, parameterExecuteDAT, executeDAT); input DATs (keyboardinDAT, mouseinDAT, oscinDAT/oscoutDAT); and GLSL ops -- a glslTOP/glslmultiTOP docks a pixel DAT, a compute DAT, AND an info DAT (the multi variant also docks a vertex DAT); a glslMAT docks a vertex DAT, a pixel DAT, AND an info DAT (no compute DAT); a glslPOP docks a compute DAT and an info DAT.
Given host bottom-left (sx,sy), size (sw,sh), and N docks (use max dw,dh across docks). Docks HUG the host -- the one deliberate exception to 200-grid spacing:
row_y = sy - dh - 30 -- a tight ~30-unit gap below the host's bottom edge, NOT a full grid step.step = dw + 20 -- one compact cluster under the host.i at nodeX = (sx + sw/2) + (i - (N-1)/2) * step - dw/2, filling per this table; overflow stacks into a second tight row (row_y - dh - 30) rather than widening:| N | Pattern |
|---|---|
| 1 | [C] |
| 2 | [C, R] |
| 3 | [L, C, R] |
| 4 | [L, C, R, R2] |
| 5 | [L2, L, C, R, R2] |
If another op occupies a dock's slot, move that other op -- docked ops take priority, are never threaded around obstacles, never overlap, never stranded. For execute_python builds: query [d.path for d in op('PATH').docked], reposition EVERY dock per the formula, then get_network_layout to confirm. A glslTOP built inside execute_python is the classic trap.
/manage-annotations before create_annotation or set_annotation -- nodeX/nodeY is the bottom-left corner.execute_python-created ops at (0, 0) / overlapping -- Envoy emits a LAYOUT WARNING, but position + verify regardless.nodeX + 300 without nodeWidth -- the #1 cause of overlaps.COMP.layout() -- overlapping, unreadable results.set_op_position into an unverified slot (it has no overlap detection).layout() for production networksexecute_python build, check every dockedTo entry in get_network_layout yourselfexecute_python with result = ui.panes.current.owner.pathop.Embody.parent().path) for a consistent home; override only when the user has deliberately navigated into a content network (never bare /); discover, never guess, /project1; keep one task's COMPs in one homegeometryCOMP: delete its default torus1 the moment you add your own geometry, or it renders a phantom torus behind your scene