// 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.
Create trigger evaluation setup for a toolkit skill. Use when the user wants to test whether a skill's description triggers correctly, set up eval workspaces, or generate trigger test queries for a skill. Use when user says 'create eval', 'test triggers', 'eval skill', or wants to measure skill triggering accuracy.
Validate toolkit components and project docs — check external doc URLs, cross-references between skills/commands/rules, and verify README.md and CLAUDE.md are in sync with actual toolkit state. Use when the user asks to validate, review, or check toolkit quality.
Helps users figure out what they can build with dlt and which workflow to start. MUST use this skill when the user asks questions like 'what can you do', 'how do I build a pipeline', 'how do I make reports', 'how do I deploy', 'what are toolkits', 'what's available', 'I'm new to dlt', 'where do I start', or seems confused about what to do next after initial setup. Also use when the user asks broad capability questions about data engineering with dlt. Do NOT use when the user has a specific task in progress like debugging a pipeline, validating data, or adding endpoints. Do NOT use when the user explicitly wants a guided end-to-end demo — use **quick-start** for that.
Use when the user wants a guided end-to-end run from data to dashboard in a few prompts: 'show me a demo', 'give me a quick start', 'take me through the full workflow', 'how do I go from data to dashboard', 'walk me through ingestion to visualization', 'I want to try everything end-to-end'. Do NOT use when the user is asking what's available or where to start in general — use the `toolkit-dispatch` skill (in init) for capability-discovery questions ('what can you do', 'what toolkits are there', 'I'm new to dlt'). Do NOT use when the user already has a specific task underway (debugging, adding an endpoint, deploying).
Adjust a working dlt pipeline for production — remove dev limits, verify pagination, configure incremental loading, expand date ranges. Use when the user wants to remove .add_limit(), load more data, fix pagination, or set up incremental loading.
Create a dlt REST API pipeline. Use for the rest_api core source, or any generic REST/HTTP API source. Not for sql_database or filesystem sources.
| name | find-source |
| description | 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. |
| argument-hint | [source-name] [context] |
Locate the best dlt source for what the user wants to extract data from.
Parse $ARGUMENTS:
source-name (required): what the user wants to extract data from (e.g., "alpaca markets", "stripe", "postgres", "csv files", "rest api")| User says (examples) | Core source |
|---|---|
| postgres, mysql, mssql, oracle, database, db, sql | sql_database |
| rest api, http api, web api, rest | rest_api |
| files, csv, parquet, jsonl, s3, gcs, azure blob, local files | filesystem |
If it matches a core source, skip to step 5 and report the core source match.
If the request looks like a specific API/service name, run:
dlthub --non-interactive pipeline init --list-sources
Search the output (case-insensitive) for the source name. If found, ensure that the verified source contains the data that the user needs (ask the user explicitly) skip to step 5
Use search_dlthub_sources mcp tool to look for sources. It is full-text search based so pass only essential keywords to it
ie. "claude analytics". You'll get description of the source and set of reference links to use in web search below.
query: <source-name> API documentation
NOTE: we can handle only REST API (step 5) and sometimes GraphQL.
This toolkit builds REST API pipelines. Before continuing, check if the user's data source actually fits.
STOP and hand off if any of these are true:
rest_api — the user needs sql_database, filesystem, or another core source. For filesystem, hand off to the filesystem-pipeline toolkit (create-filesystem-pipeline). For others, tell them which one and the dlt init command, then suggest a general coding session.dlt init <source> <destination> command. Suggest they try the verified source first.Found: <verified source or non-REST core source>
Command: dlt init <source> <destination>
This is outside the REST API pipeline workflow. You can:
1. Use the verified source / core source above (recommended)
2. Start a general coding session if you need a custom pipeline
CONTINUE only when the best path is building a REST API pipeline — either because:
rest_api core source under the hood)Ask user to pick a single endpoint to start the work - do it directly or infer it from conversation.
Do NOT run dlt init yet — wait for user confirmation.
After that continue workflow in create-rest-api-pipeline skill