dlt-bootstrap 用于按团队的“内部方式”为 dlt 管道开发搭建项目环境。它先以项目级方式安装 dltHub 官方 AI Workbench，再把 Relentless Data 的约定作为一条常驻规则叠加在其上。Workbench 自带的工具包负责管道构建，本技能不会重复或重新教授这些内容。引导完成后即交棒：日常工作通过 Workbench 自身的入口（/find-source、/explore-data 等）运行，内部规则因以规则形式存在而自动生效，不经过技能中介。
一、先检查内部规则
在项目中搜索已提交的 dlt-house-conventions.md 文件。
若存在 → 进入增量模式：读取其 frontmatter（source_types、toolkits_installed），只补齐缺失的部分，通常是为新的源类型安装额外的工具包并更新 frontmatter。
若不存在 → 执行完整引导（见下）。
若在用户正忙于其他任务、仅因规则缺失而被主动触发时，不要立即启动引导：先告知项目缺少 dlt-house-conventions.md，询问是否运行安装，除非用户同意，否则回到用户当前的任务。
二、检测而非询问
通过检查来确定现状，并在安装步骤中创建缺失的部分：
- pyproject.toml / venv —— 判断是全新项目还是已有项目（两者路径相同）。
- dlt[hub] 是否已是依赖？uv run dlthub --version 是否成功？
- 正在使用哪个代理（Claude Code / Cursor / Codex）—— 通常从会话即可看出；应通过 --agent 显式传入，而不是依赖自动检测。
- 是否存在 .dlt/ 目录、已有管道、git 仓库状态。
- dlthub ai init 把它的规则放在了哪里（见“写入内部规则”）。
三、访谈（最多三个问题，用平实语言提问）
- 本项目摄取哪些源类型——REST API、SQL 数据库，还是文件？这决定工具包的选择。可以多选。
- 管道 / 数据集名称——仅当无法从仓库名推导时才询问。
- 目标端——Snowflake 是内部默认；确认，并允许按客户覆盖（例如 BigQuery），而无需修改本技能。
四、安装（已验证的快速路径）
uv init # 仅在无 pyproject.toml 时 uv add "dlt[hub]" uv add "dlthub[mcp]" # MCP 服务器依赖——缺少它工作区 MCP 永远无法启动 uv run dlthub init # 工作区初始化；遵循其提示（uv sync） uv run dlthub ai init --agent claude uv run dlthub ai toolkit install <toolkit> --agent claude # 按源类型选择 uv run dlthub ai status # 验证：检测到代理，列出工具包与入口技能
如果任何命令失败或某个 flag 被拒绝，应先怀疑上游漂移而非直接调试：查阅 references/docs-map.md（从 workbench README 开始）并重新推导命令——绝不臆造 flag。
已知上游陷阱（2026-06 验证）：如果 dlthub ai status 警告要 pip install "dlt[workspace]"，忽略它——该 extra 并不存在；正确的修复方式是 uv add "dlthub[mcp]"（已包含在上面的快速路径中）。
五、工具包策略
安装 init（自动依赖），加上仅与访谈答案匹配的管道工具包：
源类型 → 工具包
- REST API → rest-api-pipeline
- SQL 数据库 → sql-database-pipeline
- 文件（CSV/Parquet/JSONL）→ filesystem-pipeline（需要 dltHub 注册）
绝不安装 quick-start（本技能即为入口点）或 dlthub-platform（我们通过 Prefect 部署，而非 dltHub 平台）。
data-exploration、data-quality、transformations 仅在明确要求时安装——注意后两者需要 dltHub 注册；安装前先说明，若用户没有账号则优雅跳过。
把每个已安装的工具包记录到内部规则的 frontmatter 中。
六、写入内部规则
把 references/rule-template.md 复制到项目中，并根据访谈 + 检测结果填写每一个 <placeholder>。随后重新阅读 frontmatter：模板中的每个键都存在、每行一个、不留任何 <（destination / dev_destination 很容易被写坏）。
将其命名为 dlt-house-conventions.md，并放在 dlthub ai init 安装自身规则的同一位置（找到它的 dlthub-workspace.md），使其对同一代理常驻生效。如果该代理会把规则合并进记忆文件（CLAUDE.md / AGENTS.md），则改为把填好的模板作为一段清晰分隔的托管区段追加进去。
确保代理记忆文件带有 dltHub 的凭据安全说明（它在模板中）——它们的安装器不会为 Claude Code 添加这一行。
提交规则和工作台安装的文件。绝不提交 .dlt/secrets.toml——uv init 和 dlthub ai init 都没有把它加入 gitignore（后者只写了 .claudeignore）。如果 .gitignore 中缺失，就加上 secrets.toml，然后验证：git check-ignore .dlt/secrets.toml。
七、验证后交棒
- uv run dlthub ai status 会显示代理和管道工具包——它省略 init；用 uv run dlthub ai toolkit list 确认完整集合。
- MCP：确认 dlt-workspace-mcp 已为该代理注册（Claude Code 可检查项目 .mcp.json）。
- 告诉用户现在重启代理会话——工作台技能（/find-source 等）和 MCP 服务器在此之前不会生效。
- 告诉用户工作循环：/find-source → 脚手架 → 通过 MCP secrets 工具配置密钥 → 调试 → 在 DuckDB 上验证 → 加固（增量加载、移除开发限制）→ 包装为 Prefect flow（prefect）→ 通过 /ship 发布 → 用 snowman 检查落地 Snowflake 的内容。
八、护栏
- 本技能只做搭建，不构建管道。若在引导前被要求构建管道，先引导，再转交给工作台的技能。
- 绝不在对话中索要凭据——用户直接编辑 secrets（为此存在 MCP secrets 工具）。
- 不要把工作台技能内容分叉进本仓库；上游拥有它。
- 增量重跑必须幂等：重新安装已存在的工具包或重写未改动的规则都是空操作，而非错误。