Alibaba Cloud ROS Agent

Use the bridge at scripts/ros_agent.py. Its default code transport uses the Alibaba Cloud Credentials SDK default credential chain and Tea OpenAPI V3 signing to send ROS RPCs directly and consume StartChat SSE incrementally. The bridge never reads credential environment variables or credential values from Profile files itself. A Profile explicitly pinned by local policy is delegated to the Credentials SDK Profile provider and is exclusive: it never falls back to the default chain or another Profile. Credentials exist only inside the SDK-backed request path and are never accepted as bridge arguments, persisted in job state, or returned. An optional dependency-free transport invokes the ROS CLI plugin's start-chat and stop-chat commands. Run the bridge with python3 on macOS/Linux or py -3 on Windows.

Required interaction contract

Visible narration is part of completing this workflow, not optional styling. Internal reasoning/thinking, a tool description, raw tool output, and the wording of a user question are not substitutes for a user-visible assistant text block. Keep each update concise—normally one to three sentences in the user's language. An update and the following tool call may be in the same assistant response, so do not pause merely to narrate.

Use these stage gates:

• After loading this Skill and before the first operational tool call, acknowledge the infrastructure task, identify Normal or Pipeline mode, and state the immediate next phase.
• After check succeeds and before local prompt preparation or start, report that readiness passed and what ROS Agent will work on next. Do not expose commands, Profile details, or opaque IDs.
• Whenever bridge JSON has presentationRequired: true, the next assistant response must begin with a user-visible text block before any further tool call. For every boundaryReached result, emit every ready-to-display userUpdates string—even after earlier Pipeline updates; skipping a repeated stage gate and going directly to Bash is a protocol violation. For followTimedOut, show the heartbeat without claiming completion. For turn-completed, present the authoritative finalText and relevant artifacts before starting another action or asking a follow-up question.
• Before asking the user to confirm a deployment, present the proposed architecture as a fenced Mermaid diagram after the deployment summary. The confirmation question must come after the diagram; tool output or an unrendered diagram field does not satisfy this gate. Follow the architecture rules below.
• When input is required, first explain in a separate visible update what has completed, what ROS Agent is waiting for, and why the answer is needed; then ask the question with every returned option intact using an interaction method appropriate to the host. For permissions, include the safe action, target, and permissionClass; for pendingPermissions, state how many independent Sub Pipeline steps are waiting. End the agent turn without choosing for the user.
• After the user answers a question, selects a candidate, or allows/denies a permission, begin the next assistant response by acknowledging the choice and saying that ROS Agent is resuming, then call continue or respond. Before sending any later natural-language request such as a change or cleanup through continue, similarly state what the same ROS Agent session will do next.
• On completion or failure, present the authoritative result or concise sanitized error immediately. Do not dump raw JSON, event counts, correlation IDs, or the full prior milestone history, and do not repeat already presented progress.

Do not call TodoWrite, Task, or another planning tool merely to track this managed workflow. The preserved jobId and cursor are its state; report progress directly to the user instead.