Flutter CI/CD 技能用于创建、修复或加固供应商中立的 Flutter CI/CD 流水线，覆盖质量门禁、缓存、构建产物、密钥以及分阶段交付。它适用于 GitHub Actions、GitLab CI、Codemagic、Bitrise、Xcode Cloud 等环境，以及 monorepo 场景。
使用原则方面，该技能要求在仓库现有的交付模型之上构建可复现的流水线。除非用户明确要求迁移，否则应保留当前供应商、Flutter 版本来源、包管理器、flavors、签名流程和部署工具。
预检阶段需要阅读 pubspec.yaml、锁文件、SDK/版本管理器文件、工作区布局、生成代码策略、flavors、测试、原生目标、现有流水线文件、仓库脚本、发布工具、受保护环境以及密钥名称，之后才编写流水线变更。在诊断可靠性或速度问题时，应检查实际作业依赖图和最近的耗时/失败输出。当仓库证据不可用时，应请求或列出所需的精确文件和日志，并将建议保持在不变式层面，不得把占位工作流当作已完成的修复呈现。任何签名材料或服务凭证都不得被打印、移动、合成或提交。
该技能区分拉取请求的置信度与发布权限：一个通过的 CI 作业可以证明检查通过和产物创建，但不授权打标签、上传商店、生产部署或更改凭证。
在任务路由上，确定性的格式、分析、生成、测试、覆盖率、golden、矩阵与缓存门禁应查阅 quality gates 参考；签名、密钥、产物、符号、受保护环境、分阶段发布与发布边界应查阅 delivery and secrets 参考；GitHub Actions、GitLab CI、Codemagic、Bitrise、Xcode Cloud、monorepo 以及保留供应商的决策应查阅 provider and monorepo 参考。只加载当前流水线所需的参考内容。
边界方面，flavors、签名配置、版本控制、符号生成和本地可上架产物由 flutter-build-release 负责；本技能应检查并编排这些既有命令，而不是在供应商 YAML 中重新实现。测试策略与测试实现由 flutter-testing 负责，本技能将仓库选定的测试套件作为门禁运行。更广泛的安全审计由 flutter-security 负责，但本技能仍应用最小权限、密钥隔离、可信依赖固定和不可信 fork 边界。不得为了更方便地编写流水线而更改应用架构、状态管理或依赖包。
验证阶段应使用供应商当前的 linter/dry-run 设施验证供应商语法，并在环境允许时本地运行每一个底层仓库命令。需要检查冷路径与缓存路径、拉取请求与受保护分支条件、预期产物、取消/并发行为以及失败传播。缓存命中与未命中必须产生相同的正确性结果。格式化和 golden 门禁不得重写源代码或期望值。新鲜度门禁可以在一次性检出中运行既有的生成器，但必须在产生差异时失败，且绝不能提交或隐藏该差异。对于交付，在任何经授权的外部变更之前，优先使用 dry run 或非生产目标。
报告应包含更改的命令和流水线路径、演练过的环境、产物证据，以及任何 macOS runner、签名、密钥、配额或商店侧的缺口。绝不能仅仅为了让流水线变绿而削弱门禁。
该技能的资料来源包括 Flutter 持续交付文档、Flutter 应用测试文档以及 GitHub Actions 安全指南。更多安装与使用细节暂未提供。