Excel DuckDB ETL 运行器

要解决什么问题

很多 Excel/CSV 分析任务形态相似：表结构已经标准或已规范化，核心逻辑就是 DuckDB SQL（关联、聚合、窗口、过滤），却每次从零写一套 Python。更麻烦的是，分析跑完若只留下对话里的结论，很难 重复执行、交给调度器，或在变更输入后做同样的校验与留痕。

本技能面向「能用通用 Runner 跑通」的场景：scripts/duckdb_etl_runner.py 既是技能内的执行助手，也是默认可导出的复用脚本，与前置技能一脉相承：脚本优先、DuckDB 优先、不把原始电子表塞进 LLM 上下文，并保留校验、运行清单、字段映射、SQL 与回退日志。

技能如何工作

Runner 倾向 配置驱动，而不是重写 Python：

• 支持直接 SQL 参数、--sql-file、以及 recipe 查询；这些路径彼此独立，即使没有 recipe.steps 依赖链也应可用。
• 需要分步 ETL 时，用 recipe.steps：每步执行只读 SQL，按 --formats 或 recipe 写出结果，并可 register_as 把中间 CSV 注册为后续步骤的表。
• 多表场景用 recipe 的 inputs.tables，或 CLI 的 --table-files name=path；JOIN 必须在 SQL 里写清 ON / USING。
• 业务结果用可读文件名导出（--output-name / recipe.outputs.name），技术元数据仍用稳定文件名写入 run_manifest.json 等。

每次正式交付应包含：duckdb_etl_runner.py（或等价脚本）、script_usage.md、request.json、table_profile.json、queries.sql、validation.json、至少一个业务命名的结果文件，以及 run_manifest.json。没有可复用脚本与用法文档，不应视为分析完成。

适用边界

• 适合：标准表、已规范化数据、逻辑可表达为 SQL、步骤间可依赖中间 CSV 表、需要可调度脚本与稳定产物。
• 不适合：复杂 Excel 规范化、多阶段 DataFrame 变换、强报告定制输出——应改用更完整的 scaffold 技能。
• DuckDB 不可用、必须先做表前清洗、或任务本身非 SQL 形态时允许回退，原因记入 fallback_log.json 或 validation.json。实现细节可参考 references/runner-design.md 与用户提供的 duckdb_analyzer.py 思路（只读 SQL 检查、多表注册等），而非整文件照搬。