name: rauto-usage description: "Execute rauto directly for the user: run device commands, template execution, tx block, tx workflow, multi-device orchestration, replay, backup/restore, and connection/profile/template/history operations. Trigger on requests like run command for me, execute on device, check history, run workflow, orchestrate multiple devices, apply staged rollout, use inventory/groups, diagnose profile, manage templates/profiles/connections, replay records, or restore backup."

Rauto Usage

Execute rauto operations directly for users whenever possible. Do not default to tutorial-style answers.

Core Mode

Prefer action-first behavior:

1. Parse user goal and classify it as read-only or config-changing.
2. For read-only operations, run the relevant rauto command immediately.
3. For config-changing operations, prefer tx/tx-workflow/orchestrate with rollback-aware planning.
4. If commands are generated by the agent, ask for human confirmation before execution.
5. Return key results (not raw noise), plus command used.

Execution Rules

1. For read/query requests, execute immediately:
   • examples: device list, connection list, history list, templates list, replay --list.
2. For config-changing requests, prefer rollback-capable execution:
   • single block: tx
   • multi-step/multi-resource: tx-workflow
   • multi-device staged rollout: orchestrate
3. For generated change commands, do not execute immediately:
   • show planned command(s), rollback strategy, and require user confirmation.
4. For explicit read-only commands (for example show), tx/workflow is not required.
5. Resolve connection in this priority:
   • explicit command args > --connection <name> > ask for missing fields.
6. Do not ask the user to manually run commands if agent can run them.
7. Summarize outputs with important fields:
   • target, mode, success/failure, key errors, next action.

Risk Guardrails

Require explicit user confirmation before destructive actions:

• rauto backup restore ... --replace
• profile/template/connection delete operations
• tx/workflow execution that changes config when user intent is ambiguous

Additional safety requirements for config changes:

• Prefer tx/tx-workflow/orchestrate with rollback-aware planning over direct apply patterns.
• Run/offer --dry-run first for workflow-based changes.
• For orchestrate, review target scope, fail_fast, concurrency, and rollback boundary before execution.
• Never auto-run agent-generated change commands without confirmation.
• Include rollback path in the proposal before execution.

If user explicitly asks to execute destructive action, proceed.

Missing Input Strategy

Ask only for missing must-have fields:

• For exec/template/tx/tx-workflow/orchestrate/connection test:
  • need either full host credentials or usable --connection.
• For replay:
  • need record file path or JSONL source.
• For history queries:
  • need connection name.

Response Format

When command is executed, report:

1. Operation: what was run
2. Command: exact rauto command
3. Result: key output summary
4. Notes: risk, errors, or follow-up actions

Navigation (Load References On Demand)

• Agent execution decision tree and command templates: references/agent-execution.md
• Full CLI command cookbook: references/cli.md
• Runnable multi-device orchestration JSON templates (EN): references/orchestration-json-template.md
• Multi-device orchestration pre-flight review: references/orchestration-risk-check.md
• Runtime storage paths: references/paths.md
• Troubleshooting and recovery: references/troubleshooting.md
• End-to-end operation scenarios: references/scenarios.md
• English Q/A examples: references/examples.md
• Runnable workflow JSON templates (EN): references/workflow-json-template.md
• Web tab/card mapping (only when user asks for Web operations): references/web.md