Releasing And Deploying Tilebox Workflows

Use this skill to initialize workflow projects, turn workflow code changes into immutable releases, and deploy those releases to one or more Tilebox clusters. Use tilebox-workflow-authoring for task code and this skill for project scaffold, config, publish, deploy, and runner iteration.

Agent Release Loop

For routine iteration, do the smallest safe loop:

1. For a new project, choose a reusable capability name using the policy below, then initialize once with tilebox workflow init --name "Scene QA" --json before creating project files by hand. Omit --name only when the current directory already has an appropriate capability-based name.
2. Edit workflow code and ensure changed files are covered by [build].include and not excluded.
3. Optional local verification: tilebox workflow build-release --debug --json.
4. Publish: tilebox workflow publish-release --json.
5. Deploy the new release. For quick first results, omit --cluster to use the API default cluster instead of asking the user to choose one.
6. If the user requested an actual processed artifact, use tilebox-workflow-jobs to submit and verify a representative job after deployment; deployment alone does not create the artifact.
7. If no compatible runner is active and local execution is appropriate, start a dynamic runner for the same cluster; omitting --cluster also uses the API default cluster.

Prefer a specific release ID for production-like targets; use --latest for dev iteration only when that is acceptable.

For failed existing jobs caused by a compatible task bug, prefer deploying the fixed release and retrying the failed job over submitting a fresh job from scratch.