REPLACE-WITH-PLATFORM-NAME

Platform Name

Standalone install? If this session was not initialized by the TAO skill bank plugin, run the tao-setup skill first (host preflight, credentials, cross-skill discovery).

Short summary of the platform's execution model. Instance-based or job-based? API-first or docker-first? Single-node or multi-node? Managed or self-hosted?

For generic docker conventions, defer to tao-skill-bank:tao-run-on-docker. This skill covers the platform-specific layering on top.

External dependencies

Authentication

Env vars:

Preflight

# 1. CLI installed
which <cli-name> || echo "MISSING: install from <url>"

# 2. Logged in
<cli-name> ls >/dev/null 2>&1 || echo "NOT LOGGED IN"

# 3. Platform-specific checks

Quick start

Docker-native workflow

<platform-cli> exec <target> -- docker run --gpus all --rm \
  -e <env-vars> \
  -v <host-path>:<container-path> \
  nvcr.io/... \
  <command>

Execution — the four verbs

A platform skill is a consumer: it runs a model/data skill's spec-bundle by implementing submit/status/logs/cancel over the native CLI, mutating only the job-record. No SDK. See tao-skill-bank:tao-launch-workflow for the shared contract and tao-skill-bank:tao-run-on-docker for a worked example.

• submit — stage inputs via tao-data-io, lint the command with redact_secrets.py, then tao_job_record.py open (mints the id + binds results_dir before launch), launch naming the backend object after the id, and mark ... --state RUNNING.
• status / logs — poll the native backend; map states to the fixed vocab PENDING RUNNING COMPLETE ERROR CANCELED UNKNOWN.
• cancel — native cancel + teardown, then mark ... --state CANCELED.

Platform-specific notes

• Storage model (shared NFS/Lustre? S3 only? instance-local?)
• Pricing / lifecycle considerations
• Known limitations

Known pitfalls