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.

Use tilebox-cli first to ensure the CLI is up to date and inspect command schemas. The scoped-project release baseline is CLI >=0.14 and Tilebox Python packages >=0.68; check availability and installed capabilities rather than assuming these releases are already available. Regularly check and update project packages using authoring's reference/tilebox/dependencies-and-packaging.md, especially after cloning, copying a template, or resuming an older project.

Always submit workflow-scoped jobs for these projects, including development and smoke tests: use --workflow . or an exact remote reference. Running tilebox runner start locally still requires scoped jobs. Unscoped submissions are only for an explicitly requested direct Python runner or a Python script executed as a direct runner for testing; follow tilebox-workflow-jobs for that exception. Missing links or deployments are prerequisites to resolve, not reasons to drop scope.

Agent Release Loop

For routine iteration, do the smallest safe loop:

1. Inspect the existing project and local link. For a new project, discover a named source workflow when the user asks to adapt one, then use init --template; otherwise initialize the embedded scaffold. Resolve an unlinked checkout before publishing using the linking policy below.
2. Edit workflow code and ensure changed files are covered by [build].include and not excluded.
3. Optional local verification: tilebox workflow build-release --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 with --workflow . 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.