[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXEZ96FRFWMSHFA93WF7ZF":3,"skill-same:01M6DXEZ96FRFWMSHFA93WF7ZF":81},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6DXEZ96FRFWMSHFA93WF7ZF","motherduck-create-flight",null,"Create, schedule, run, and debug MotherDuck Flights — Python jobs that run on MotherDuck compute. Use whenever someone wants to create a flight, schedule a Python script or recurring job on MotherDuck, set up scheduled ingestion from Postgres, dlt sources, S3, BigQuery, Snowflake, or APIs, refresh aggregates or transformations on a cron, or operate flights with get_flight_guide, create_flight, run_flight, flight logs, secrets, schedules, and versions.","cianfhoghlaim\u002Fcianfhoghlaim","cianfhoghlaim","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F57019547?v=4","01M6DWR3GAV495PYDTZSR1FZNX","Cian Mac (an Déisigh Uí) Liatháin || Deacy-Lyons","01M6DWR3N3Z768BB64XVJN0AY2",4,"MIT","https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim\u002Fcianfhoghlaim\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmotherduck\u002Fmotherduck-create-flight\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"motherduck create flight","create","motherduck","ingestion","get","compute","aggregates","python script","postgres","flights","up","python","use","recurring","refresh","schedule","SET","logs","snowflake","debug","2026-11-10 10:12:30",false,"---\nname: motherduck-create-flight\ndescription: Create, schedule, run, and debug MotherDuck Flights — Python jobs that run on MotherDuck compute. Use whenever someone wants to create a flight, schedule a Python script or recurring job on MotherDuck, set up scheduled ingestion from Postgres, dlt sources, S3, BigQuery, Snowflake, or APIs, refresh aggregates or transformations on a cron, or operate flights with get_flight_guide, create_flight, run_flight, flight logs, secrets, schedules, and versions.\nlicense: MIT\n---\n\n# Create and Manage MotherDuck Flights\n\nUse this skill when the user needs Python to run *on MotherDuck* — on a schedule or on demand — instead of in their own infrastructure. A Flight is a single-file Python program that MotherDuck executes in a managed runtime with a MotherDuck token injected, pip dependencies installed from a `requirements.txt`, and stdout\u002Fstderr captured as run logs. The primary use cases are scheduled ingestion (pull from Postgres, S3, APIs, other warehouses, or any dlt source into MotherDuck tables) and scheduled transformation (refresh aggregates, run dbt, recompute reporting tables).\n\n## Source Of Truth\n\n- **Non-negotiable ordering:** when MotherDuck MCP is available, call `get_flight_guide` before `create_flight`, `update_flight`, or `edit_flight_source`. The guide defines the current authoring contract, runtime limits, and tool semantics.\n- Prefer current MotherDuck Flights docs over memory; the feature is in Preview and details shift.\n- Without MCP, the same operations exist as SQL functions (`MD_CREATE_FLIGHT`, `MD_RUN_FLIGHT`, `MD_FLIGHTS()`, ...) that execute server-side on a MotherDuck connection. Parameter names differ slightly between the two surfaces; see the naming table in `references\u002FFLIGHTS_GUIDE.md`.\n\n## Default Posture\n\n- One Flight = one single-file Python script with `def main(): ...` and `if __name__ == \"__main__\": main()`. No CLI args — every knob comes from env vars via `config` (non-secret) or `TYPE flights` secrets (sensitive).\n- Connect with `duckdb.connect(\"md:\")`; the runtime injects `MOTHERDUCK_TOKEN` automatically. Never hardcode a token in source, config, or requirements.\n- Always pin dependencies in `requirements_txt`, and pin `duckdb` to the latest MotherDuck-supported version (currently `duckdb==1.5.2`); an unpinned `duckdb` can install a release MotherDuck does not accept yet and fail at connect.\n- Each secret param arrives as the env var `\u003Csecret_name>_\u003CPARAM>`, not the bare param name. This is the single most common authoring mistake.\n- Bulk-load, never row-by-row: stage to `\u002Ftmp\u002F` and `read_csv_auto`\u002F`read_json_auto`\u002F`read_parquet`, or one CTAS \u002F `INSERT ... SELECT`. No `executemany()` against MotherDuck.\n- Make every run idempotent: `CREATE OR REPLACE TABLE` full refresh, partition `DELETE` + `INSERT`, or dlt `write_disposition=\"merge\"` with a primary key. Bootstrap with `CREATE DATABASE IF NOT EXISTS` \u002F `CREATE SCHEMA IF NOT EXISTS` so the first run succeeds on a fresh account.\n- Validate any config-supplied identifier (database, schema, table names) against `[A-Za-z_][A-Za-z0-9_]*` before interpolating it into DDL; bind all data values as `?` parameters.\n- Create the flight **without** a schedule first, trigger one on-demand run, read the logs, and only then attach `schedule_cron` (5-field cron, UTC).\n- For production, use a service-account token via `access_token_name` and keep its database permissions as narrow as the workload allows.\n- A Flight is sized for orchestration and light processing (2 cores, 16GB RAM, ~150GB scratch at `\u002Ftmp\u002F`), not for crunching large tables in Python memory — push heavy compute into SQL.\n\n## Workflow\n\n1. Classify the job: ingestion, transformation\u002Frefresh, export or alerting, or admin automation. If the job is interactive analysis or a one-off query, use `motherduck-query` instead — no Flight needed.\n2. Call `get_flight_guide` (MCP) and confirm which database the flight writes to with `motherduck-explore`.\n3. Start from the closest template in `references\u002FFLIGHT_EXAMPLES.md` (dlt source, Postgres mirror, or S3 partition refresh) rather than writing from scratch; adapt via config knobs, not code surgery.\n4. Create any required `TYPE flights` secret first, then `create_flight` with `name`, `source_code`, pinned `requirements_txt`, `config`, and secret names — no `schedule_cron` yet.\n5. `run_flight`, poll `list_flight_runs` until terminal, and read `get_flight_logs`. Iterate with `edit_flight_source` (surgical) or `update_flight` (full field replacement); each content change creates a new version.\n6. Once a run succeeds, set the schedule with `update_flight(schedule_cron = ...)` and tell the user the cron is UTC. Clear it later with `schedule_cron = \"\"`.\n\n## Open Next\n\n- Read `references\u002FFLIGHTS_GUIDE.md` for the full concept and operations reference: anatomy, runtime environment, config vs secrets, scheduling, versioning, run lifecycle, the complete MCP tool reference, MCP-vs-SQL naming, loading strategies by data volume, and troubleshooting.\n- Read `references\u002FFLIGHT_EXAMPLES.md` for three complete, best-practice flight templates (dlt ingestion, Postgres ingestion, scheduled S3 partition refresh) with their `requirements.txt`, secret setup, and deploy calls.\n\n## Related Skills\n\n- `motherduck-load-data` for choosing the ingestion SQL the flight will run (CTAS, `INSERT ... SELECT`, cloud-storage secrets)\n- `motherduck-query` for validating the DuckDB SQL inside the flight before deploying it\n- `motherduck-explore` for confirming target databases, schemas, and tables exist\n- `motherduck-build-data-pipeline` when the work is a full raw\u002Fstaging\u002Fanalytics pipeline design and the flight is just its scheduler\n","# Create and Manage MotherDuck Flights\n\nUse this skill when the user needs Python to run *on MotherDuck* — on a schedule or on demand — instead of in their own infrastructure. A Flight is a single-file Python program that MotherDuck executes in a managed runtime with a MotherDuck token injected, pip dependencies installed from a `requirements.txt`, and stdout\u002Fstderr captured as run logs. The primary use cases are scheduled ingestion (pull from Postgres, S3, APIs, other warehouses, or any dlt source into MotherDuck tables) and scheduled transformation (refresh aggregates, run dbt, recompute reporting tables).\n\n## Source Of Truth\n\n- **Non-negotiable ordering:** when MotherDuck MCP is available, call `get_flight_guide` before `create_flight`, `update_flight`, or `edit_flight_source`. The guide defines the current authoring contract, runtime limits, and tool semantics.\n- Prefer current MotherDuck Flights docs over memory; the feature is in Preview and details shift.\n- Without MCP, the same operations exist as SQL functions (`MD_CREATE_FLIGHT`, `MD_RUN_FLIGHT`, `MD_FLIGHTS()`, ...) that execute server-side on a MotherDuck connection. Parameter names differ slightly between the two surfaces; see the naming table in `references\u002FFLIGHTS_GUIDE.md`.\n\n## Default Posture\n\n- One Flight = one single-file Python script with `def main(): ...` and `if __name__ == \"__main__\": main()`. No CLI args — every knob comes from env vars via `config` (non-secret) or `TYPE flights` secrets (sensitive).\n- Connect with `duckdb.connect(\"md:\")`; the runtime injects `MOTHERDUCK_TOKEN` automatically. Never hardcode a token in source, config, or requirements.\n- Always pin dependencies in `requirements_txt`, and pin `duckdb` to the latest MotherDuck-supported version (currently `duckdb==1.5.2`); an unpinned `duckdb` can install a release MotherDuck does not accept yet and fail at connect.\n- Each secret param arrives as the env var `\u003Csecret_name>_\u003CPARAM>`, not the bare param name. This is the single most common authoring mistake.\n- Bulk-load, never row-by-row: stage to `\u002Ftmp\u002F` and `read_csv_auto`\u002F`read_json_auto`\u002F`read_parquet`, or one CTAS \u002F `INSERT ... SELECT`. No `executemany()` against MotherDuck.\n- Make every run idempotent: `CREATE OR REPLACE TABLE` full refresh, partition `DELETE` + `INSERT`, or dlt `write_disposition=\"merge\"` with a primary key. Bootstrap with `CREATE DATABASE IF NOT EXISTS` \u002F `CREATE SCHEMA IF NOT EXISTS` so the first run succeeds on a fresh account.\n- Validate any config-supplied identifier (database, schema, table names) against `[A-Za-z_][A-Za-z0-9_]*` before interpolating it into DDL; bind all data values as `?` parameters.\n- Create the flight **without** a schedule first, trigger one on-demand run, read the logs, and only then attach `schedule_cron` (5-field cron, UTC).\n- For production, use a service-account token via `access_token_name` and keep its database permissions as narrow as the workload allows.\n- A Flight is sized for orchestration and light processing (2 cores, 16GB RAM, ~150GB scratch at `\u002Ftmp\u002F`), not for crunching large tables in Python memory — push heavy compute into SQL.\n\n## Workflow\n\n1. Classify the job: ingestion, transformation\u002Frefresh, export or alerting, or admin automation. If the job is interactive analysis or a one-off query, use `motherduck-query` instead — no Flight needed.\n2. Call `get_flight_guide` (MCP) and confirm which database the flight writes to with `motherduck-explore`.\n3. Start from the closest template in `references\u002FFLIGHT_EXAMPLES.md` (dlt source, Postgres mirror, or S3 partition refresh) rather than writing from scratch; adapt via config knobs, not code surgery.\n4. Create any required `TYPE flights` secret first, then `create_flight` with `name`, `source_code`, pinned `requirements_txt`, `config`, and secret names — no `schedule_cron` yet.\n5. `run_flight`, poll `list_flight_runs` until terminal, and read `get_flight_logs`. Iterate with `edit_flight_source` (surgical) or `update_flight` (full field replacement); each content change creates a new version.\n6. Once a run succeeds, set the schedule with `update_flight(schedule_cron = ...)` and tell the user the cron is UTC. Clear it later with `schedule_cron = \"\"`.\n\n## Open Next\n\n- Read `references\u002FFLIGHTS_GUIDE.md` for the full concept and operations reference: anatomy, runtime environment, config vs secrets, scheduling, versioning, run lifecycle, the complete MCP tool reference, MCP-vs-SQL naming, loading strategies by data volume, and troubleshooting.\n- Read `references\u002FFLIGHT_EXAMPLES.md` for three complete, best-practice flight templates (dlt ingestion, Postgres ingestion, scheduled S3 partition refresh) with their `requirements.txt`, secret setup, and deploy calls.\n\n## Related Skills\n\n- `motherduck-load-data` for choosing the ingestion SQL the flight will run (CTAS, `INSERT ... SELECT`, cloud-storage secrets)\n- `motherduck-query` for validating the DuckDB SQL inside the flight before deploying it\n- `motherduck-explore` for confirming target databases, schemas, and tables exist\n- `motherduck-build-data-pipeline` when the work is a full raw\u002Fstaging\u002Fanalytics pipeline design and the flight is just its scheduler\n",{"name":5,"license":15,"description":7},"main","5ace051462d0639f59bcc60912f4ec08c1a96772",".agents\u002Fskills\u002Fmotherduck\u002Fmotherduck-create-flight",1,"https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim\u002Fcianfhoghlaim","https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim","cianfhoghlaim.ie","Irish-British teacher, mathematician, foghlaimeoir || minority-language AI researcher || Lucht Siúil ||\r\nFine Gael + Alliance Party + Liberal Democrats Member","2026-11-14 03:06:52",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add cianfhoghlaim\u002Fcianfhoghlaim --skill motherduck-create-flight",{"tool":59,"command":60},"bunx","bunx skills add cianfhoghlaim\u002Fcianfhoghlaim --skill motherduck-create-flight",{"tool":62,"command":63},"pnpm","pnpm dlx skills add cianfhoghlaim\u002Fcianfhoghlaim --skill motherduck-create-flight","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim\u002Fcianfhoghlaim\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmotherduck\u002Fmotherduck-create-flight\u002FSKILL.md",true,[67,73,77],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"index.json","REFERENCE","参考文档",642,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fnetwork\u002Fcapture\u002Fscapy\u002Fdetect\u002Findex.json",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002FFLIGHT_EXAMPLES.md",27230,"https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim\u002Fcianfhoghlaim\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmotherduck\u002Fmotherduck-create-flight\u002Freferences\u002FFLIGHT_EXAMPLES.md",{"path":78,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002FFLIGHTS_GUIDE.md",15524,"https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim\u002Fcianfhoghlaim\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmotherduck\u002Fmotherduck-create-flight\u002Freferences\u002FFLIGHTS_GUIDE.md",[82,102,120,140,164,190],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":39},"01M6DXR6F7GB4JSD67XTX6WY4A","dagster-init","Initialize a dagster project using the create-dagster cli. Create a dagster project, uv virtual environment, and everything needed for a user to run dg dev or dg check defs successfully. (project)","https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim\u002Fcianfhoghlaim\u002Fblob\u002Fmain\u002Fdocs\u002Fresearch\u002Fdagster\u002Fdagster-dspy\u002F.claude\u002Fskills\u002Fdagster-init\u002FSKILL.md",[],[89,90,91,92,93,94,95,96,97,98,99,100,20,101],"init","dagster","dagster init","run","project","uv","environment","user","initialize","check","virtual","dev","cli",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":113,"publishedAt":39},"01M6DXQZ2HSP548JH2V3FQ7H2V","create-custom-dagster-component","Create a custom Dagster Component with demo mode support, realistic asset structure, and optional custom scaffolder using the dg CLI. Use this skill if there is no Component included in an existing integration or if Dagster does not have the integration.","https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim\u002Fcianfhoghlaim\u002Fblob\u002Fmain\u002Fdocs\u002Fresearch\u002Fdagster\u002Fdagster-dspy\u002F.claude\u002Fskills\u002Fcreate-custom-dagster-component\u002FSKILL.md",[108],{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[114,20,90,115,116,101,117,118,31,119],"component","create custom dagster component","support","demo","structure","integration",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":39},"01M6DXHPZMQ4VAXH9PGBK2PNNP","pydantic-ai-harness","Extend Pydantic AI agents with batteries-included capabilities from pydantic-ai-harness -- currently Code Mode, which collapses many tool calls into one sandboxed Python execution. Use when the user mentions pydantic-ai-harness, CodeMode, Monty, code mode, or tool sandboxing, when they want an agent to run agent-written Python, or when a Pydantic AI agent would benefit from orchestrating multiple tool calls in a single sandboxed script.","https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim\u002Fcianfhoghlaim\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fpydantic\u002Fpydantic-ai-harness\u002FSKILL.md",[],[127,128,129,130,92,131,132,31,96,133,134,135,136,137,138,30,139],"Pydantic","harness","pydantic ai","pydantic ai harness","batteries","pydantic-ai","tool","sandboxing","execution","capabilities","code","ai agents","ai agent",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":150,"publishedAt":39},"01M6DXH7JE54YEHM58JY8KY2AK","building-pydantic-ai-agents","Build AI agents with Pydantic AI — tools, capabilities (including on-demand loading), structured output, streaming, testing, and multi-agent patterns. Use when the user mentions Pydantic AI, imports pydantic_ai, or asks to build an AI agent, add tools\u002Fcapabilities, defer capability loading, stream output, define agents from YAML, or test agent behavior.","https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim\u002Fcianfhoghlaim\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fpydantic\u002Fbuilding-pydantic-ai-agents\u002FSKILL.md",[146,149],{"categoryNo":147,"categoryName":148,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},[138,127,129,151,30,152,139,153,154,155,156,157,31,158,159,160,161,162,136,163],"building pydantic ai agents","testing","structured output","define","agent patterns","patterns","build","behavior","multi-agent","Tools","yaml","streaming","test",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":175,"publishedAt":39},"01M6DXGCVB0WSHBQ7BSA56A12C","motherduck-share-data","Create and manage MotherDuck data shares for zero-copy, read-only data distribution. Use whenever someone wants to share a database with team members, another organization, or the public — covers CREATE SHARE, access\u002Fvisibility\u002Fupdate modes, GRANT READ ON SHARE, attaching share URLs, UPDATE SHARE, and REFRESH DATABASE.","https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim\u002Fcianfhoghlaim\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmotherduck\u002Fmotherduck-share-data\u002FSKILL.md",[170],{"categoryNo":171,"categoryName":172,"taxonomyType":173,"taxonomyTypeDesc":174},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[176,177,21,178,31,179,180,181,182,33,183,184,185,186,187,188,189,20],"share","data","motherduck share data","distribution","organization","manage","only","read","public","access","team","ZeRO","database","update",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":39},"01M6DXG9NMFYC72KJWQVJ1D6BZ","motherduck-security-governance","Explain MotherDuck security, governance, and access-control patterns. Use for any question about SOC 2, GDPR, compliance, data residency, regions, SSO, service accounts, token handling, tenant isolation, sharing boundaries, snapshots and recovery, or governance posture — including when a security_compliance_owner, technical_owner, or application_builder is evaluating MotherDuck.","https:\u002F\u002Fgithub.com\u002Fcianfhoghlaim\u002Fcianfhoghlaim\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmotherduck\u002Fmotherduck-security-governance\u002FSKILL.md",[],[197,198,199,21,200,201,202,185,203,204,205,206,207,177,208,209,210,211,31,212],"governance","security","motherduck security governance","sso","sharing","recovery","explain","technical","compliance","soc","gdpr","snapshots","token","control","question","builder"]