用途
该技能用于在涉及 PyTorch CI 数据（任意 pytorch/* 组织仓库）、torchci/HUD 代码库或 PyTorch HUD ClickHouse 数据库的工作场景中优先加载，提供访问 PyTorch HUD ClickHouse 后端的两套 MCP 服务器路径。两套服务器连接同一后端，按任务选择。
主要能力
pytorch-hud：精选分类查询（无需 SQL）
每个工具回答一个具体问题，无需编写 SQL：
- get_recent_commits_with_jobs_resource：查询某分支或 SHA 上的失败情况，支持 job_name_filter_regex、failure_line_filter_regex 以及 include_success/pending/failures 标志，用于控制上下文规模。
- get_job_details_resource：在缩小范围后获取单个任务的完整详情。
- get_master_commit_red_resource：查看一段时间内主干的红绿状态。
- get_queued_jobs_resource：查看 CI 队列是否积压。
- find_commits_with_similar_failures_resource：通过全文搜索与日期范围二分定位某失败首次出现的时间。
- get_disabled_test_historical_resource：查询偶发或禁用测试的历史。
- get_artifacts_resource：获取任务的构建或测试产物。
- 日志工具：download_log_to_file_resource 先下载，再用 extract_log_patterns_resource、filter_log_sections_resource、extract_test_results_resource 分析；get_s3_log_url_resource 直接给出原始 URL 而不下载。
pytorch-hud：约 145 个命名查询
提供手工调优并维护的命名查询。可用 get_clickhouse_queries_resource 列出目录（例如 master_commit_red、queue_times_historical、commit_jobs_query、flaky_tests），用 get_clickhouse_query_params_resource(query_name) 查看参数与测试样例，用 query_clickhouse_resource(query_name, parameters) 执行，parameters 为 JSON 字符串。这些查询对应仓库中的 torchci/clickhouse_queries/ 目录，可通过 query.sql 与 params.json 查看具体实现；加载器为 torchci/lib/clickhouse.ts 中的 queryClickhouseSaved。参数使用 {name: Type} 类型占位符进行服务端绑定；params.json 可声明默认值与测试样例，其中 {"from_now": N} 表示相对当前 N 天，负值为过去。目录覆盖主干健康、提交/任务/工作流状态、测试（偶发、禁用、耗时）、队列与延迟、成本与时长、运行器利用率、合并/回滚/PR 指标、自动回滚、基准测试和 CRCR。
clickhouse-mcp：原始 SQL、调试与优化
- get_clickhouse_tables：列出表，database 默认 default，传入 databases='all' 可跨三个库。
- get_clickhouse_schema(table)：查看完整 CREATE TABLE DDL，包括引擎、ORDER BY、跳过索引与列注释。
- explain_clickhouse_query：执行 EXPLAIN，可加 explain_plan=true 查看索引/粒度裁剪，explain_estimate=true 查看待读取的 parts/rows/marks。
- run_clickhouse_query：执行查询；measure_performance=true 返回 duration_ms 与 memory_usage；大结果写入 result_file，total_result_rows_n 为真实行数。
- get_query_details(name)：取回已提交的命名查询作为模板，需传 include_performance_samples=0。
- semantic_search_docs：搜索 ClickHouse 官方文档。
技能还给出优化慢查询的步骤：先读 DDL 找 ORDER BY、PARTITION BY 与跳过索引；按排序键前缀或跳过索引列过滤；复用已有查询；用 EXPLAIN 确认裁剪（Granules kept 约等于 total 即全扫描）；用 measure_performance 获取真实耗时与内存；迭代缩小时间范围、去掉 SELECT *、避免 FINAL。并给出首轮写出高性能查询的检查清单。
使用方式
每次会话开始时先调用 mcp__pytorch-hud__readme_howto_pytorch_treehugging_guide 了解分类工作流，再调用 mcp__clickhouse-mcp__readme_howto_use_clickhouse_tools 了解原始查询用法。这些 MCP 工具为延迟加载，需先用 ToolSearch 加载其 schema，例如 query select:mcp__pytorch-hud__readme_howto_pytorch_treehugging_guide。
数据模型要点
存在三个数据库：default（CI/GitHub 相关表，如 workflow_job、workflow_run、test_run_s3、push、pull_request、merges 等）、benchmark（oss_ci_benchmark_* 等）、misc（autorevert_、disabled_tests_historical、queue_times_、oss_ci_utilization_、greenlight_pr_state 等）。_mv 为物化视图，*_dict 为字典。
不能假设按时间列过滤就一定快，需查看 DDL。例如 default.workflow_job 的 ORDER BY 以 id 开头，按 created_at 过滤没有主键裁剪，但可借助 created_at 的 minmax 跳过索引获得约 99% 裁剪；既不在 ORDER BY 也非跳过索引的过滤列会触发全表扫描。
核心表为 SharedReplacingMergeTree，后台合并前行可能重复，精选查询用 FINAL 或 ORDER BY _inserted_at DESC LIMIT 1 BY id 去重。misc.greenlight_pr_state 的排序键以每行唯一的 emit_id 结尾，FINAL 不折叠任何行，argMax 会丢弃 run_id 的平局决胜；读取每个 PR 的当前状态应使用 ORDER BY pr_number, run_id DESC, version DESC LIMIT 1 BY pr_number。
default.merges 每次合并推送一行而非每个落地 PR 一行，ghstack 栈中非最终提交不会出现在 merges 中；如需所有落地 PR，可从主分支提交标题推导或展开 commits 数组。reverts 与 num_reverts 查询只读取 push.head_commit.message，多提交推送中以非最终提交落地的回滚对它们不可见，输出应视为下界。
已知限制
- 不要追加尾部分号；工具可容忍，但应按 readme 省略。
- lint_clickhouse_query 对所有输入均返回内部 SQLFluff 错误，不可依赖。
- get_query_execution_stats 对当前用户权限拒绝（system.query_log 未授权），get_query_details 的性能样本同样被拒，因此始终传 include_performance_samples=0；性能测量只能依靠 explain 与 run(measure_performance=true)。
- run_clickhouse_query 内联输出受 inline_result_limit_bytes 限制（默认 1024，最大 10240），大结果需用 LIMIT 并读取 result_file。