---
name: engineering-workflow
description: Design, inspect, modify and validate persistent electronics, mechanical CAD, robot assemblies, firmware and device programs in the Cutu Circuits workspace using its real local tools.
---

Use the Cutu Circuits MCP tools for requested engineering work. Begin with runtime_status and list_projects. If unavailable, report the returned start command; do not invent a connection. Use get_project to inspect the chosen project, its exact opaque IDs, revision, assets and hardware manifest. Create a suitable template when a new persistent project is requested. Do not assume a selected UI project matches the conversation.

Keep authoring files in their native formats: .circuit.tsx for electronics, native Replicad JavaScript/TypeScript for CAD, and actual source programs for firmware or devices. Read existing files and preserve relevant structure. Write through write_file with the exact observed SHA-256; use null only for new files. On 409, reread and reconcile before another write. Source writes advance the project revision; refetch get_project before graph changes. Use update_graph with the observed revision to register new assets and maintain entity, asset and link relationships. Use broker tools for coordinated graph and guarded source changes; do not generate a transient preview in place of a requested saved design.

For electronics, inspect the existing circuit and constraints; author real components, named nets/connections and board layout in native source. Compile the saved source and inspect diagnostics and the returned circuit/schematic/PCB data. Resolve errors before reporting a working circuit. For advanced schematic/PCB placement, routing, simulation, readiness checks or manufacturing outputs, open the source asset in the workspace and use list_editor_tools. Invoke the discovered electronics tools with their exact schemas via call_editor_tool, the exact sessionId and the read_file hash for mutations. Do not guess handler names or claim a mounted API exists when it does not.

For mechanical work, use the actual Replicad model convention (Z-up, millimeters, default model function and defaultParams). Keep design dimensions in explicit parameters and preserve native B-rep authoring for STEP export. Ask for essential missing dimensions or use clearly labeled provisional parameters; never call illustrative robot geometry measured. Compile, inspect bounds and diagnostics, then export the requested STEP/STL/OBJ. Native editor operations such as inspection/import/render use the discovered CAD tool schemas; advanced operations require the relevant mounted editor.

For assemblies and robots, keep stable IDs across circuit components, CAD parts, joints, firmware references and device channels. Use named links and explicit coordinate frames; preserve the distinction between Z-up CAD coordinates and display transforms. Model joint axes, limits and commanded motion explicitly. Select exact IDs with set_selection to align the workspace with work under discussion.

For terminal-based authoring and adaptable programs, call project_environment to discover the actual projectRoot/cwd and projectFile; never assume a repository-relative path or the default data directory. Call list_files to inspect real project contents. Run requested terminal edits, dependency setup, scripts and local processes with this exact working directory. Keep programs and authoring files persistent in that project. The runtime watches native project files and publishes file/project events to synchronize the workspace; reread files and get_project after terminal changes to refresh hashes/revisions before guarded broker mutations. Do not manually rewrite the project manifest to bypass graph validation; register assets and capabilities through update_graph. Terminal outputs are execution evidence only for processes actually run.

For firmware and general device programs, inspect existing assets, create persistent source and register assets/capabilities in the graph. A capability has an exact ID, executable command, argument array, JSON input schema and bounded timeout; prefer project programs with input parameters over shell interpolation. Inspect hardware_capabilities before run_operation and pass schema-valid inputs. For persistent programs, inspect the project source for its exact control protocol and use send_operation with a JSON message; Makada monitor accepts status, walk and stop messages on its existing connection. Poll list_operations for actual output/telemetry and use cancel_operation for cancellation. A queued/running operation is not evidence of successful execution. Preserve existing credential handling and never place secrets in manifests, source examples or tool output.

Makada is one example, not the product boundary. Its three servos drive six wire legs; only the firmware's forward gait is implemented. Device-specific commands belong to its adapter, which owns the single TCP connection and heartbeat. Simulated poses, stored calibration, commanded pulses and measured hardware values are distinct. Makada reports no measured shaft position, angle or stall feedback; do not infer observations from commands. Describe physical device results only when returned by an actual operation.

Finish with concrete saved paths/IDs, changes, real validation and remaining unresolved constraints. Do not claim deployment, hardware motion, flashing, calibration or a live agent session without actual tool evidence.