القائمة
Find a dlt destination for a given storage provider. Use when the user asks about a destination, wants to find a connector, or asks to implement a pipeline for a specific data destination.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Create a dlt REST API pipeline to run as a Tower app. Use for the rest_api core source, or any generic REST/HTTP API source. Not for sql_database or filesystem sources.
Explore and profile loaded data from a data consumer perspective. Scores 5 dimensions (completeness, freshness, consistency, queryability, discoverability). Absorbs validate-data. Modes — PROFILE (automated after load), VALIDATE (cross-reference against source), EXPLORE (interactive queries). Routes issues to responsible persona.
Debug and inspect a Tower app after running it. Supports dlt pipelines, ASGI apps, and plain Python scripts. Use after a run (success or failure) to inspect logs, diagnose errors, and fix issues.
Find a dlt source for a given API or data provider. Use when the user asks about a source, wants to find a connector, or asks to implement a pipeline for a specific data source.
Detect existing project stack, learn conventions from code, and produce a project profile. Run before other skills to give them richer context, or let skills invoke it automatically when no profile exists.
Create a Tower app — either a hello-world scaffold (greenfield) or a wrapper around existing Python pipeline code.
| name | find-destination |
| description | Find a dlt destination for a given storage provider. Use when the user asks about a destination, wants to find a connector, or asks to implement a pipeline for a specific data destination. |
| argument-hint | [destination-name] [context] |
| allowed-tools | ["Read","Glob","Grep","Bash","AskUserQuestion","WebFetch","WebSearch"] |
Locate the best dlt destination for what the user wants to load data into.
Parse $ARGUMENTS:
destination-name (optional): what the user wants to load data into (e.g., "duckdb", "postgres", "snowflake", "iceberg", "filesystem"). This is the main input to classify the request and find the best destination.Read .tower/project-profile.md if it exists.
If the user has NOT EXPLICITLY mentioned a specific destination assume iceberg tables with rest catalog (polaris) and credentials. The following iceberg catalog configuration is known to work with dlt and can be used as a default. Secret credentials will be injected as environment variables at runtime:
# config.toml
[destination.iceberg]
catalog_type = "rest"
Read up on iceberg destination configuration here: https://dlthub.com/docs/dlt-ecosystem/destinations/iceberg
Only If the user has EXPLICITLY mentioned a destination other than iceberg, continue with steps 2-5 to identify the right destination, otherwise jump straight to step 6
IMPORTANT: dlt[iceberg] extra does NOT exist. You must add pyiceberg as a separate dependency:
uv add pyiceberg
The following PYICEBERG_CATALOG__DEFAULT__* env vars are automatically injected by the Tower runtime — they are NOT Tower secrets and do NOT need to be created via tower_secrets_create:
| Tower runtime env var | Format | Description |
|---|---|---|
PYICEBERG_CATALOG__DEFAULT__URI | https://your-catalog.example.com | REST catalog endpoint |
PYICEBERG_CATALOG__DEFAULT__WAREHOUSE | my_warehouse | Warehouse name |
PYICEBERG_CATALOG__DEFAULT__CREDENTIAL | client_id:client_secret | OAuth2 credentials (colon-separated) |
PYICEBERG_CATALOG__DEFAULT__SCOPE | PRINCIPAL_ROLE:your_role | OAuth2 scope (colon-separated) |
These are available in tower_run_local runs automatically. NEVER create these as Tower secrets.
CRITICAL: dlt's iceberg destination does NOT read PYICEBERG_CATALOG__DEFAULT__* env vars automatically. It uses its own config resolution (DESTINATION__ICEBERG__CREDENTIALS__*). You must manually bridge these env vars in your pipeline code.
import os
import json
# Bridge PyIceberg env vars → dlt's Iceberg REST catalog config.
# dlt expects DESTINATION__ICEBERG__CREDENTIALS__* but Tower exposes PYICEBERG_CATALOG__DEFAULT__*.
env_map = {
"DESTINATION__ICEBERG__CREDENTIALS__URI": "PYICEBERG_CATALOG__DEFAULT__URI",
"DESTINATION__ICEBERG__CREDENTIALS__CREDENTIAL": "PYICEBERG_CATALOG__DEFAULT__CREDENTIAL",
"DESTINATION__ICEBERG__CREDENTIALS__WAREHOUSE": "PYICEBERG_CATALOG__DEFAULT__WAREHOUSE",
}
for dlt_key, pyiceberg_key in env_map.items():
if dlt_key not in os.environ and pyiceberg_key in os.environ:
os.environ[dlt_key] = os.environ[pyiceberg_key]
# Extra catalog properties (scope, etc.) must be passed as a JSON dict.
# dlt does not resolve nested dict keys from individual env vars for MetastoreProperties.
props = {}
if scope := os.environ.get("PYICEBERG_CATALOG__DEFAULT__SCOPE"):
props["scope"] = scope
if props:
os.environ["DESTINATION__ICEBERG__CREDENTIALS__PROPERTIES"] = json.dumps(props)
[destination.iceberg]
catalog_type = "rest"
catalog_type must be set in .dlt/config.toml — it is not auto-detected.
dlt --non-interactive init --list-destinations
Search the output (case-insensitive) for the destination name. If found, skip to step 5
Use the table below to find the documentation URL for the requested destination, then fetch and read it.
This toolkit builds only DLT pipelines for known destinations. Before continuing, check if the user's destination actually exists.
STOP and hand off if the destination requested by the users does not unambiguously match any of the known destinations listed above, or if the documentation indicates that it's not a destination that dlt can load into.
Loading data into [destination] is not currently supported by dlt. Sorry for the inconvenience!
CONTINUE only if the destination requested by the users DOES unambiguously match any of the known destinations listed above, and if the documentation indicates that it's a destination that dlt can load into.
Use the documentation to determine the different ways and credential set that users can use to authenticate with their chosen destination. Also check whether the pipeline supports different table formats or different file formats. See step 5 for how to use this information.
CRITICAL: When user input is needed, use the AskUserQuestion tool. Present each viable destination/auth method as a concrete option. Make the recommended option first with "(Recommended)" in the label. Do NOT ask questions via plain text output.
Report one of these status codes when the skill finishes:
| Status | Meaning |
|---|---|
| DONE | Destination identified, configuration requirements clear, user confirmed |
| DONE_WITH_CONCERNS | Destination works but with caveats (e.g. limited feature support, complex auth) |
| BLOCKED | Requested destination is not supported by dlt |
| NEEDS_CONTEXT | User must clarify which destination, auth method, or table format they want |
Destination not in dlt's supported list:
Run dlt --non-interactive init --list-destinations to get the current list. If the user's destination is not listed, check whether it maps to a supported one (e.g. "Redshift Serverless" maps to redshift, "Azure SQL" maps to mssql). If no mapping exists, tell the user and suggest the closest alternative. Status: BLOCKED if no viable match.
Destination docs page returns an error or is missing:
Fall back to the dlt docs index at https://dlthub.com/docs/llms.txt and search for the destination name. If the destination was recently added, the docs may lag — check the dlt GitHub repo for the latest destination support.
Destination requires unsupported auth method: Some destinations support multiple auth methods. Check the docs for alternatives (e.g. service account vs. OAuth, connection string vs. individual fields). If none work, Status: BLOCKED with a clear explanation of what is missing.
User wants Iceberg but with a non-Tower catalog: The default Tower-managed catalog is the only tested path. If the user wants a custom catalog (e.g. AWS Glue, Hive), warn that this is outside the standard workflow and may require custom configuration. Status: DONE_WITH_CONCERNS.