pipeline-model-interpreter

name	pipeline-model-interpreter
description	解释 BK-CI 流水线或创作流的 Model JSON，帮助 AI 理解 Model -> Stage -> Container(Job) -> Element 的含义、启动参数、矩阵、Finally、审核与常见插件语义。用户贴出流水线 JSON、创作流 JSON、编排数据，或询问某个 Stage/Job/插件/atomCode/stepId 含义时使用。

流水线模型解释

适用场景

• 用户直接贴出 BK-CI 流水线或创作流的 Model JSON
• 用户问“这个流水线做了什么”“这个编排什么意思”“帮我理解这个 Stage/Job/插件”
• 用户要解释启动参数、矩阵、Finally、审核、脚本插件、商店插件输入输出
• 用户给出 atomCode、elementId、stepId、jobId 等信息，要求说明其在编排中的含义

不适用场景

• 修改模型代码、加字段、做兼容性改造
• 排查构建运行时失败日志或执行状态
• 设计固定摘要模板输出
• 需要理解 YAML 转换、持久化、版本兼容实现细节

快速指导

1. 先把 JSON 还原成 Model -> Stage -> Container -> Element 四层结构。
2. 第一个 Stage 里的 TriggerContainer.params 优先解释为启动参数入口；触发器插件本身通常不用当业务步骤展开。
3. 先判断容器类型：trigger、vmBuild、normal，再判断插件类型：linuxScript、windowsScript、marketBuild、marketBuildLess、subPipelineCall、manualReviewUserTask 等。
4. 解释插件时同时看 @type、atomCode、name、data.input、data.output 和 additionalOptions。
5. 如果用户问整体含义，先说明主流程、关键 Stage/Job、启动参数入口和可能产出；如果只问某个节点，只解释相关切片。
6. 遇到未知 atomCode 时，不臆测功能；明确标注“需结合插件文档确认”，并列出关键输入输出字段。
7. 解释某节点的执行时机时，结合 runCondition 判断；Element / Job / Stage 三层各有独立枚举，不要混用。
8. 详细分析步骤、常见插件速查和参数类型速查看 reference/。

高信号规则

• 创作流与流水线使用同一套模型结构，这个 skill 同时适用于两者
• containerHashId、jobId、element.id、stepId 语义不同，不能混用
• status、startEpoch、elapsed、executeCount、timeCost 等运行态字段默认忽略，除非用户明确问运行状态
• additionalOptions.enable=false、jobControlOption.enable=false、stageControlOption.enable=false 要明确标注为已禁用
• 敏感参数或 PASSWORD 类型只标注为敏感，不回显默认值

关键陷阱

• 把 TriggerContainer 里的触发器插件当成业务主流程
• 把运行态字段当成编排语义来解释
• 忽略矩阵展开后的子 Job、Finally Stage、审核控制和互斥组
• 只看 atomCode 不看 data.input / data.output，导致插件理解失真
• 对未知商店插件直接猜功能，而不是保守说明边界

延伸阅读

• 详细分析步骤：reference/1-json-analysis-playbook.md
• 容器、插件与参数类型速查：reference/2-common-plugin-and-container-hints.md
• classType / dispatchType / 枚举字面量清单：reference/3-classtype-and-enum-catalog.md
• 如果用户手里没有 Model JSON、想先取回来，可用 managing-devops-pipeline 或构建 Agent 的编排查询工具（获取流水线编排摘要/获取流水线编排）
• 如果需要理解模型代码结构、版本兼容或 YAML 转换：pipeline-model-architecture