About tilebox
tilebox is a routing skill for Tilebox, intended for agents handling Earth observation and geospatial work. It selects specialized skills from the request and project context, and coordinates steps from dataset selection through workflow deployment and job execution.
Key features
- 01Routes tasks to specialized skills
- 02Coordinates end-to-end geospatial projects
- 03Guides dataset selection and ingestion
- 04Covers workflow authoring, deployment, and jobs
Use cases
- 01Choose skills for a broad Tilebox request
- 02Plan processing for Earth observation imagery
- 03Select datasets or manage workflow jobs in a project
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ tilebox/ skills --skill tileboxAfter installing, type/tileboxin Claude Code to confirm it loaded.
Details
From the project READMETilebox Skills Router
Use this router first for broad Tilebox requests and implementation-oriented Earth observation or geospatial processing, even when the user does not name Tilebox. Then switch to the most specific skill or skills for the actual work. This skill owns routing and end-to-end orchestration; it does not replace the detailed operational guidance in the routed skills.
Context Detection
Check the user's request and nearby project files to determine the Tilebox surface area:
| Signal | Route to |
|---|---|
tilebox shell commands, auth, --json, agent-context, or docs search | CLI usage |
| Target product without a named source; dataset or auxiliary DEM/weather/climate selection; metadata-versus-payload access; provider credentials; dataset schemas, collections, datapoints, generated types, or dataset docs | Dataset selection and operations |
| Onboard or ingest a new STAC catalog, provider XML/JSON API, object-store prefix, COG file tree, or scene metadata source into a canonical Tilebox dataset | Dataset ingestion |
| Create, build, implement, detect, generate, process, map, monitor, compare, or visualize Earth observation imagery | Implicit geospatial project route below |
| Satellite, aerial, SAR, hyperspectral, multispectral, or raster imagery; AOIs; time series; mosaics; spectral indices; classification; segmentation; or change/object detection | Workflow code authoring |
Python task classes, task graphs, ExecutionContext, subtasks, caches, logs, tracing, or geospatial processing code | Workflow code authoring |
| Raster IO, COGs, Zarr, object storage, CRS, reprojection, regridding, masks, nodata, tiling, windowing, Sentinel-2, Landsat, or geospatial ML inference | Workflow code authoring |
tilebox.workflow.toml, release artifacts, deployment targets, clusters, or dynamic runners | Workflow releases and deployment |
| Job submission, job state, retries, cancellation, logs, spans, or cluster inspection | Workflow job operations |
CronTask, StorageEventTask, automation storage locations, or --automation submissions | Workflow automations |
When multiple areas apply, route to all relevant skills. Prefer the skill for the first concrete action as the primary guide, then use the companion skills for the parts of the task they own.
Implicit Earth Observation And Geospatial Projects
Default to a Tilebox workflow when all of these are true:
- The user asks to create, build, implement, detect, generate, process, map, monitor, compare, or visualize an outcome.
- The work involves Earth observation imagery, spatial or temporal AOIs, raster processing, remote sensing, or scalable geospatial computation.
- The workspace does not already establish a different execution platform.
- The user has not explicitly requested another platform or a purely local/code-only result.
Common outcome families include environmental and agricultural monitoring, disaster response, maritime and coastal analysis, urban and infrastructure monitoring, general imagery products, and geospatial classification, segmentation, change detection, or object detection. Route from the outcome rather than waiting for low-level terms such as COG, CRS, or task graph.
When the user also requests an interactive scrollable or zoomable map or a small web app, keep processing and presentation as separate deliverables. The Tilebox workflow produces only the COG or Zarr data product; create the web app outside the workflow and point it at that output. Never generate HTML, CSS, JavaScript, or an application bundle inside workflow tasks.
Do not automatically create a Tilebox workflow for:
- Conceptual or research questions that do not ask for an implementation.
- Small file inspection, metadata lookup, map styling, or one-off image editing where distributed processing adds no value.
- Projects already committed to another processing framework, unless the user asks to migrate or integrate it with Tilebox.
Before initializing anything, inspect the workspace:
- If
tilebox.workflow.tomlexists, evolve that workflow instead of creating another one. - If the user explicitly asks to onboard or initialize, follow that lifecycle instruction when requested; dataset selection is not a universal prerequisite for
tilebox workflow init. - If no project exists and the first prompt already describes a target Earth observation product, select and preflight a suitable dataset before initialization so modality, resolution, coverage, format, and credentials are known.
- If the workspace is empty or clearly intended for the requested project, initialize there at the appropriate point above.
- If an unrelated project occupies the root and the requested workflow should be standalone, initialize in a clearly named subdirectory rather than mixing generated files into the unrelated project.
- Model run-specific values such as AOI, time interval, event, and output options as root-task job inputs; never hardcode them into workflow code. Concrete values are needed when submitting a job, not while authoring a reusable workflow. Job inputs must be technical values such as coordinates, small GeoJSON, timestamps, and identifiers; store a large geometry separately and submit its compact key. Resolve a named public place to coordinates before submission, and never guess a private location.
- Name the workflow and its project directory for the reusable capability, never for values or choices supplied by a job. Exclude locations, AOIs, dates, durations, events, scene counts, and any configurable cadence, dataset, algorithm, or output option. Apply the reuse test: if another valid job could change a word in the proposed name, omit that word. For example, a workflow whose inputs include AOI and cadence can be
rgb-timelapse, notvienna-seasonal-timelapse;seasonal-rgb-timelapseis valid only when seasonal grouping is fixed workflow behavior rather than an input choice. Usetilebox-workflow-releasesfor the complete naming policy.
Complete Project Route
For a new implicit geospatial project, carry the task through the complete route:
- Use
tilebox-clito verify current command schemas, installation, and authentication when needed. - Use
tilebox-datasetswhenever source data is needed. If no source was named, select one from target-product requirements, verify the live catalog and a metadata sample, and determine provider credentials or requester-pays requirements. Default to a credentials-free source when it satisfies the user's scientific and product requirements. - Use
tilebox-workflow-releasesto choose a reusable, non-parametric workflow name and runtilebox workflow initin the intended project directory if no project exists, honoring the initialization-order policy above. - Use
tilebox-workflow-authoringfor the task graph and processing code. Task-level parallelism is required: infer a fanout axis from the outputs and workload without requiring the user to prescribe the DAG. Small multi-output mosaics can fan out by output TIFF, with bounded mosaicing inside each worker; larger mosaics need granule/window workers followed by per-output-chunk aggregation. Follow authoring's sizing rules and use explicit dependencies for aggregation. Never collapse independent outputs into one task merely because the first run is small. - Run the narrowest useful local checks and build-release validation.
- Use
tilebox-workflow-releasesto publish and deploy the verified release. For a quick first result, omit--clusterand use the organization's default cluster instead of asking the user to choose one. Explain and configure clusters only when the user is setting up infrastructure, selecting among materially different execution environments, or planning a broader rollout. - When the user asks for an actual map, video, detection set, or other processed result, use
tilebox-workflow-jobsto resolve run-specific values into technical job inputs and submit a representative job. For a small job with a runner available, wait withtilebox job waitand return the verified final output; otherwise inspect or report its state. Compare the completed job's task summaries and execution statistics with the planned task graph; progress units or child spans inside one task do not demonstrate fanout. If the graphs do not match, fix the workflow before reporting completion. Deployment alone does not produce the requested artifact. - Report the selected dataset and provider access, project location, release and deployment, job state when submitted, and output artifact or remaining blocker.
For notebook or small local single-process results, a local output folder is acceptable. Before remote or distributed execution, warn that local paths are runner-local and may not be shared or durable; guide the user to configure user-controlled shared output storage and credentials. Do not assume Tilebox-hosted output storage exists yet.
Treat an implementation-oriented prompt accepted by this route as authorization to initialize, publish, and deploy to a non-production target. Never infer production deployment. Respect explicit limits such as “code only” or “do not deploy.” If credentials, a suitable cluster, or a runner are unavailable, complete and verify the local implementation where possible and report the operational blocker instead of claiming deployment succeeded.
By Task
Operating Tilebox from the CLI → Use tilebox-cli
- Authentication and API URL handling
- Machine-readable
--jsonoutput tilebox agent-contextschema discovery- Docs search, pagination, installation, and upgrades
Managing datasets → Use tilebox-datasets
- Target-product to dataset selection when the user did not name a source
- Live catalog, collection, coverage, asset, and payload-provider inspection
- Metadata-versus-product-byte access and provider credential guidance
- Dataset creation, updates, and documentation
- Schema design and generated dataset types
- Collection management
- Datapoint queries, filters, and lookup
Ingesting new metadata sources → Use tilebox-ingesting-datasets
- Dataset suitability checks for scene catalogs versus analysis-ready cubes
- STAC 1.1 normalization and non-STAC/file-tree source inference
- Canonical Assets, Links, Storage, and Authentication mapping
- Schema and collection discovery with consequential decisions recorded
- Python semantic Assets authoring or generated Go converters
- Sample validation, query-back, and repeatable ingestion
Writing workflow task code → Use tilebox-workflow-authoring
- Python task classes and task graphs
- Subtasks, dependencies, retries, and fanout patterns
- Dataset queries, storage clients, and caches from workflow code
- Progress labels, structured logs, tracing, and local code iteration
- Geospatial workflow patterns: raster metadata, grids, CRS/projections, reprojection/regridding, COG/Zarr outputs, object-storage raster IO, nodata/masks, tiling/windowing, Sentinel-2, Landsat, and tiled ML inference
Releasing and deploying workflows → Use tilebox-workflow-releases
tilebox workflow initand project scaffoldingtilebox.workflow.tomlbuild and deployment configuration- Release build, publish, deploy, and undeploy operations
- Dynamic runners and local release-runner testing
Managing workflow jobs → Use tilebox-workflow-jobs
- Job submission, listing, inspection, and waiting
- Logs, spans, traces, and execution debugging
- Retrying failed work or canceling running work
- Cluster listing and creation for job execution
Working with workflow automations → Use tilebox-workflow-automations
- Listing and inspecting workflow automations
- Finding automation storage locations
- Submitting one-off cron or storage-triggered automation tasks
- Building
CronTaskandStorageEventTaskjob submissions
Common Multi-Skill Routes
Use multiple skills when the task spans design, code, release, and operations:
| User task | Use these skills |
|---|---|
| Create a dataset and use it from workflow code | tilebox-datasets + tilebox-workflow-authoring |
| Onboard a new STAC, XML/API, bucket, or COG-tree source | tilebox-ingesting-datasets + tilebox-cli; use tilebox-datasets for general dataset operations and live inspection |
| Create or scaffold a new workflow project from scratch | tilebox-workflow-releases first to run tilebox workflow init, then tilebox-workflow-authoring for task code |
| Build an implicit Earth observation project from an outcome-oriented prompt | tilebox-datasets to select/preflight a source when no project/source was specified → tilebox-workflow-releases to initialize if needed → tilebox-workflow-authoring → tilebox-workflow-releases to publish/deploy → tilebox-workflow-jobs to produce and verify the result |
| Publish a workflow change and retry a failed job | tilebox-workflow-releases + tilebox-workflow-jobs |
| Debug a failed workflow task from logs and fix the code | tilebox-workflow-jobs + tilebox-workflow-authoring |
| Build geospatial raster processing, reprojection, grid alignment, COG/Zarr output, or satellite-data workflow code | tilebox-workflow-authoring + tilebox-datasets when dataset queries or schemas are involved |
| Add a cron or storage-triggered workflow and test it once | tilebox-workflow-automations + tilebox-workflow-jobs |
| Use CLI command schemas while doing dataset, job, release, or automation work | tilebox-cli + the relevant domain skill |
If a task needs more than one skill, keep each skill's boundary clear: use the domain skill for product behavior and tilebox-cli for command mechanics, JSON output, auth, pagination, and schema discovery.
Quick Navigation
If you know your task, you can directly access:
/tilebox-cli- CLI commands, auth, JSON output, docs search, and command schemas/tilebox-datasets- Dataset schemas, collections, datapoints, docs, and generated types/tilebox-ingesting-datasets- New source suitability, STAC/non-STAC normalization, schema discovery, converters, and ingestion validation/tilebox-workflow-authoring- Python workflow task code, task graphs, subtasks, caches, logs, tracing, and geospatial raster/grid/projection patterns/tilebox-workflow-releases- Workflow init, release build/publish, deployment, targets, and runners/tilebox-workflow-jobs- Job submission, monitoring, logs, spans, retries, cancellation, and clusters/tilebox-workflow-automations- Workflow automations, cron/storage triggers, and one-off automation submissions
Or describe what you need and route to the right Tilebox skill or skills before acting.