CLI Command Reference

Use this page as a command lookup for discovery, inspection, and execution flows in Oatty CLI mode.

Estimated time: 8-12 min

What You Will Learn

  • Understand canonical command identifiers and CLI argument shape.
  • Discover commands through the supported TUI-first workflow.
  • Inspect command schemas before execution.
  • Run workflows and exact command paths from the terminal.

Canonical Command Identifiers

Oatty resolves commands in canonical `<group> <command>` form.

Use canonical identifiers when inspecting or running commands to avoid ambiguity.

Treat canonical IDs as stable references for scripts and workflow steps.

# General pattern
oatty <group> <command> [flags]

# Example
oatty apps apps:list --project-id proj_123

expected Canonical IDs remain consistent across discovery and execution paths.

recovery If you only have vendor CLI syntax, use the TUI to discover the matching Oatty command path first, then copy the exact canonical ID into your shell command.

Command Discovery

Use the TUI when you do not know the exact command path yet.

After you import a catalog, rerun `oatty --help` or inspect command-specific help to confirm which top-level groups are available.

Once you know the exact canonical path, execute that command directly from the CLI.

# Review built-in and imported top-level commands
oatty --help

# Inspect one imported command once you know the path
oatty <group> <command> --help

tip Prefer TUI discovery over memorized commands when catalogs change.

advanced For repeated automation, validate once in TUI/CLI, then pin the exact command line in scripts.

Schema Inspection and Input Review

Review command details before sending requests to production systems.

Confirm required positional arguments, required flags, and payload shape.

Use help output to compare expected input names with your script variables.

# Inspect one command in detail
oatty <group> <command> --help

# Alternate: contextual help during TUI command selection
# press F1 in Run Command

expected Help output should identify required and optional command inputs.

recovery If execution fails due to missing inputs, map each error field to the corresponding required flag or positional argument.

Run Exact Commands and Workflows

Run exact catalog-backed commands once you know the canonical path.

Use workflow subcommands for repeatable automation that lives in workflow files or imported workflow IDs.

Keep command inputs explicit so terminal runs are easy to review and reuse.

# Run an imported command once the path is known
oatty <group> <command> [flags]

# Preview and run workflows
oatty workflow preview --file ./workflow.yaml
oatty workflow run --file ./workflow.yaml --input env=staging

tip Use preview/inspection before destructive operations.

advanced In workflows, keep destructive steps isolated and clearly labeled for easier review and rollback planning.

Automation Patterns

Use CLI mode for deterministic non-interactive runs in CI/CD or scheduled jobs.

Keep inputs explicit and environment-driven where possible.

Capture stdout/stderr in your job logs for auditability and failure triage.

# Script-friendly command
oatty workflow run --file ./workflow.yaml --input env=staging

# Standard shell guard pattern
set -euo pipefail
oatty <group> <command> [flags]

fallback When TUI discovery identifies the right command, copy that exact command into scripts instead of rewriting it from memory.

recovery If CI runs behave differently, verify catalog availability, headers, and environment variables in the job context.