tsParticles 仓库中的 monitor-ci 技能深度解析基于 Nx Cloud 自愈能力的 CI 流水线监控编排【免费下载链接】tsparticlestsParticles - Easily create highly customizable JavaScript particles effects, confetti explosions and fireworks animations and use them as animated backgrounds for your website. Ready to use components available for React.js, Vue.js (2.x and 3.x), Angular, Svelte, jQuery, Preact, Inferno, Solid, Riot and Web Components.项目地址: https://gitcode.com/GitHub_Trending/ts/tsparticles本文以 tsParticles monorepo当前版本 4.3.3仓库内.cursor/skills/monitor-ci/SKILL.md为骨架配合仓库中真实存在的确定性决策脚本ci-poll-decide.mjs、ci-state-update.mjs、子代理定义ci-monitor-subagent.md以及 Nx 配置nx.json完整讲解如何用 Agent 技能编排 Nx Cloud CI 监控、识别自愈修复状态并执行受预算约束的本地修复流程。读完本文你将掌握 monitor-ci 的完整状态机、MCP 工具调用策略、轮询循环与循环分类逻辑以及如何通过用户指令覆盖默认行为。技能定位与使用场景monitor-ci是仓库.cursor目录下定义的 Cursor/Claude Agent 技能用于编排 Nx Cloud CI 流水线执行的监控并处理自愈self-healing修复。它的核心价值在于普通 CI 提供方 CLI如gh pr checks --watch、glab ci status -w只能读取原生流水线状态而无法访问 Nx Cloud 的自愈修复链路。该技能通过与 Nx Cloud 的 MCP 工具ci_information、update_self_healing_fix交互实现了「监控 → 决策 → 执行修复 → 追踪新 CI Attempt」的完整闭环。从仓库现状看nx.json 根配置中确实存在nxCloudId: 62a6df5ddbaff92c46e3b366即该工作区已连接 Nx Cloud这正是技能运行的前提条件同时根 package.json 声明了大量 Nx 相关依赖nx/devkit、nx/js等并使用nx run-many -t build --parallel50%、nx affected -t build等命令组织构建说明这是一个典型的 Nx 驱动 monorepoCI 状态完全依赖 Nx Cloud 数据源。技能触发词包括monitor ci、watch ci、ci monitor、watch ci for this branch、track ci、check ci status以及任何希望追踪 CI 状态或需要自愈 CI 修复帮助的场景。配置默认值与参数合并技能定义了一系列可配置默认值用户可通过$ARGUMENTS传入覆盖合并后的参数驱动整个监控循环设置默认值说明--max-cycles10Agent 主动触发的 CI Attempt 循环上限超限视为超时--timeout120监控最大时长分钟--verbositymedium输出级别minimal、medium、verbose--branch自动检测要监控的分支--freshfalse忽略上次会话上下文重新开始--local-verify-attempts3本地验证 增强循环的最大次数推送到 CI 前--new-cipe-timeout10执行动作后等待新 CI Attempt 的分钟数注意--max-cycles只统计agent 主动触发的循环在 ci-state-update.mjs 的postAction()中可以看到fix-auto-applying自愈自动应用被标记为agentTriggered false因为它是 Nx Cloud 自愈完成的而非监控 Agent 触发其余动作apply-mcp、local-fix-push等均计为 agent 触发。前置校验Nx Cloud 连接检查监控循环开始前必须先验证工作区已连接 Nx Cloud否则没有任何 CI 数据可用整个技能无法运行。校验步骤SKILL.md 中的 Step 0检查工作区根目录的nx.json是否存在nxCloudId或nxCloudAccessToken若nx.json缺失或两者都不存在 → 直接退出并提示Nx Cloud not connected.若已连接 → 进入主循环。结合本仓库 nx.json 第 4 行可以看到真实连接示例nxCloudId: 62a6df5ddbaff92c46e3b366。这是该技能在当前仓库能够运作的事实基础。架构总览四层协作技能采用四层架构职责边界清晰SKILL.md编排者负责派生子代理、运行确定性脚本、打印状态以及本地编码工作如本地修复ci-monitor-subagent.md子代理fast 模型每次调用只执行一个 MCP 工具ci_information或update_self_healing_fix返回结构化结果后立即退出不循环、不轮询、不睡眠ci-poll-decide.mjs确定性决策脚本接收ci_information结果与状态参数返回action 状态码 消息ci-state-update.mjs确定性状态脚本管理预算闸门gate、动作后状态迁移、循环分类。子代理的命令契约见 ci-monitor-subagent.md包括四种FETCH_STATUS按 select 字段拉取 CI 状态、FETCH_HEAVY拉取重字段并摘要、UPDATE_FIX对 shortLink 执行 APPLY/REJECT/RERUN_ENVIRONMENT_STATE、FETCH_THROTTLE_INFO节流信息仅返回{ shortLink, cipeUrl }。子代理被要求绝不转储完整 MCP 响应只返回契约中指定的字段以控制上下文消耗。状态报告约定决策脚本根据 verbosity 级别格式化消息minimal仅当状态与上次不同才输出medium默认Poll #N | 消息verbose输出Poll #N | CI / Self-healing / Verification三元组加消息正文。无论哪个级别主 Agent 在向用户打印时都要为每条来自脚本message字段的消息加上[monitor-ci]前缀自己主动产生的动作消息如 Applying fix via MCP...同样加上该前缀保证日志可归因。MCP 工具与字段集控制技能定义了三套字段集来控制轮询效率原则是「能用最轻的就不用重的」WAIT_FIELDS: cipeUrl,commitSha,cipeStatus LIGHT_FIELDS: cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,autoApplySkipped,autoApplySkipReason,shortLink,confidence,confidenceReasoning,hints,selfHealingSkippedReason,selfHealingSkipMessage HEAVY_FIELDS: taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescriptionci_information工具接受branch可选默认当前 git 分支、select逗号分隔的字段名列表、pageToken0 起始的分页参数用于超长字符串update_self_healing_fix接受shortLink和动作APPLY、REJECT、RERUN_ENVIRONMENT_STATE。轮询模式决定 select 字段等待模式用WAIT_FIELDS普通模式首次轮询或检测到新 CI Attempt 后用LIGHT_FIELDS。反模式清单技能明确列出会导致「与自愈抢跑、丢失 CI 进度、浪费上下文」的行为监控时必须规避反模式危害使用 CI 提供方 CLI 的--watch标志如gh pr checks --watch、glab ci status -w完全绕过 Nx Cloud 自愈链路自写 CI 轮询脚本不可靠、污染上下文、无自愈能力取消 CI 工作流/流水线破坏性操作丢失 CI 进度在主 Agent 上直接跑 CI 检查浪费主 Agent 上下文 token轮询的同时独立分析/修复 CI 失败与自愈抢跑造成重复修复与状态混乱如果技能无法激活回退方案是先用 CI 提供方 CLI 做一次性只读状态检查单次调用不带 watch/轮询标志拿到上下文后立即交给本技能绝不在主 Agent 上继续轮询。主循环从初始化到动作处理主循环由 4 个步骤构成Step 1Step 4是技能的核心执行逻辑。Step 1初始化跟踪状态cycle_count 0 # 仅统计 agent 主动触发的循环计入 --max-cycles start_time now() no_progress_count 0 local_verify_count 0 env_rerun_count 0 last_cipe_url null expected_commit_sha null agent_triggered false # monitor 执行了会触发新 CI Attempt 的动作后置 true poll_count 0 wait_mode false prev_status null prev_cipe_status null prev_sh_status null prev_verification_status null prev_failure_classification null会话上下文行为如果用户在本会话中运行过/monitor-ci可能存在先前状态轮询计数、上次 CI Attempt URL 等默认从中恢复除非设置了--fresh才丢弃并从头开始。Step 2轮询循环2a. 派生 FETCH_STATUS 子代理根据模式选择 select 字段wait 模式用WAIT_FIELDS普通模式用LIGHT_FIELDS对当前分支调用ci_information等待结果返回后再继续。2b. 运行决策脚本node skill_dir/scripts/ci-poll-decide.mjs subagent_result_json poll_count verbosity \ [--wait-mode] \ [--prev-cipe-url last_cipe_url] \ [--expected-sha expected_commit_sha] \ [--prev-status prev_status] \ [--timeout timeout_seconds] \ [--new-cipe-timeout new_cipe_timeout_seconds] \ [--env-rerun-count env_rerun_count] \ [--no-progress-count no_progress_count] \ [--prev-cipe-status prev_cipe_status] \ [--prev-sh-status prev_sh_status] \ [--prev-verification-status prev_verification_status] \ [--prev-failure-classification prev_failure_classification]脚本输出单行 JSON{ action, code, message, delay?, noProgressCount, envRerunCount, fields?, newCipeDetected?, verifiableTaskIds? }。2c. 处理脚本输出解析 JSON 并更新跟踪状态no_progress_count、env_rerun_count、prev_cipe_status、prev_sh_status、prev_verification_status、prev_failure_classification、prev_status output.action : (output.code || subagent_result.cipeStatus)并poll_count。根据action分流poll打印output.message休眠output.delay秒回到 2a若output.newCipeDetected为真清除 wait 模式wait_mode falsewait打印消息、休眠、回到 2adone携带output.code进入 Step 3。从 ci-poll-decide.mjs 源码可以看到决策引擎的具体实现classify()是纯函数决策树自上而下按优先级判断wait 模式优先于普通模式并依据以下规则noProgressCount的增量/重置wait 模式下新 CI 重置、否则保持普通模式下状态有变化cipeStatus、selfHealingStatus、verificationStatus、failureClassification任一改变或检测到新 CI 则重置为 0否则 1熔断器circuit breaker连续 5 次无进展即done退避延迟backoff(count)为[60, 90, 120]秒三档封顶wait 模式下每条轮询按 30 秒估算poll_count * 30 new_cipe_timeout判定等待超时任务分类categorizeTasks()按taskId冒号分隔的第二段是否包含e2e区分 e2e 任务据此产出all_verified/e2e_only/needs_local_verify三种类别消息模板按 verbosity 处理minimal 只在状态变化时输出verbose 增加轮询序号与三元组详情。Step 3处理可动作状态决策脚本返回action done时按顺序先做循环检查Step 4→ 查看返回的code→ 查默认行为表 → 检查用户指令是否覆盖默认行为 → 执行动作 → 若动作预期产生新 CI Attempt则更新跟踪Step 3a→ 若动作导致循环则回到 Step 2。各状态对应的工具调用fix_apply_ready调用update_self_healing_fix动作APPLYfix_needs_local_verify先用HEAVY_FIELDS拉取修复详情再做本地验证fix_needs_review用HEAVY_FIELDS拉取suggestedFixDescription、suggestedFixSummary、taskFailureSummaries进行分析fix_failed/no_fix用HEAVY_FIELDS拉取taskFailureSummaries作为本地修复上下文environment_issue调用update_self_healing_fix动作RERUN_ENVIRONMENT_STATEself_healing_throttled用HEAVY_FIELDS拉取selfHealingSkipMessage然后对每个旧修复调用update_self_healing_fix。Step 3a为新 CI Attempt 检测跟踪状态node skill_dir/scripts/ci-state-update.mjs post-action \ --action type \ --cipe-url current_cipe_url \ --commit-sha git_rev_parse_HEAD动作类型有 8 种fix-auto-applying、apply-mcp、apply-local-push、reject-fix-push、local-fix-push、env-rerun、auto-fix-push、empty-commit-push。脚本返回{ waitMode, pollCount, lastCipeUrl, expectedCommitSha, agentTriggered }用输出更新所有跟踪状态后回到 Step 2。从 ci-state-update.mjs 源码看postAction()把动作分为两组MCP 触发或自愈自动应用类fix-auto-applying、apply-mcp、env-rerun按cipeUrl跟踪本地推送类apply-local-push、reject-fix-push、local-fix-push、auto-fix-push、empty-commit-push按commitSha跟踪。wait 模式被置为 truepollCount归零——等待模式的轮询只关心「是否出现新 CI Attempt」。Step 4循环分类与进度跟踪node skill_dir/scripts/ci-state-update.mjs cycle-check \ --code code \ [--agent-triggered] \ --cycle-count cycle_count --max-cycles max_cycles \ --env-rerun-count env_rerun_count脚本返回{ cycleCount, agentTriggered, envRerunCount, approachingLimit, message }。规则若上一循环为 agent 触发cycleCount源码中wasAgentTriggered为 true 时才计数非environment_issue状态时重置envRerunCountapproachingLimit cycleCount maxCycles - 2即接近上限时询问用户是继续5 或 10 循环还是停止若上一循环非 agent 触发人工推送记录检测到人工触发的推送。进度跟踪分工no_progress_count、熔断器5 次轮询与退避重置由 ci-poll-decide.mjs 负责进展 四个状态字段任一变化env_rerun_count在非环境状态下的重置由 ci-state-update.mjs 的cycle-check负责检测到新 CI Attempt 时重置local_verify_count 0、env_rerun_count 0。状态与默认行为表决策脚本可返回以下状态码表格定义默认行为用户指令可覆盖任意项。简单退出类——仅报告并退出状态默认行为ci_success成功退出cipe_canceled退出CI 被取消cipe_timed_out退出CI 超时polling_timeout退出轮询超时circuit_breaker退出连续 5 次轮询无进展environment_rerun_cap退出环境重跑次数用尽fix_auto_applying自愈正在处理——只需记录last_cipe_url进入等待模式无需 MCP 调用或本地 git 操作error等待 60 秒后循环需要动作类——Step 3 处理时需阅读 fix-flows.md 的详细流程状态摘要fix_auto_apply_skipped修复已验证但自动应用被跳过如防循环。告知用户提供手动应用fix_apply_ready修复已验证全部任务或仅 e2e。通过 MCP 应用fix_needs_local_verify修复含未验证的非 e2e 任务。本地运行验证然后应用或增强fix_needs_review修复验证失败/未尝试。分析后决策fix_failed自愈失败。拉取重数据尝试本地修复先过闸门检查no_fix无可用修复。拉取重数据尝试本地修复先过闸门或退出environment_issue通过 MCP 请求环境重跑先过闸门self_healing_throttled拒绝旧修复尝试本地修复no_new_cipeCI Attempt 从未生成。执行自动修复工作流或带指引退出cipe_no_tasksCI 失败但无任务记录。用空提交重试一次从 ci-poll-decide.mjs 的classify()可以看到这些状态码的判定顺序自上而下优先级递减wait 模式新 CI 检测 → 等待超时 → 继续等待→ 轮询超时 → 熔断器 →SUCCEEDED/CANCELED/TIMED_OUT终态 →cipe_no_tasksFAILED 且无 failedTaskIds 且无自愈状态→environment_state分类重跑次数 ≥2 则封顶退出→THROTTLED跳过原因 → CI 进行中 → 自愈进行中 → flaky 自动重跑 → 修复自动应用 → 自动应用路径跳过/验证中/已验证→ 自愈完成后的任务分类 → 自愈失败 → 无修复 → 兜底轮询。其中「真实进展」状态ci_success、fix_auto_applying、fix_auto_apply_skipped、fix_needs_review、fix_apply_ready、fix_needs_local_verify会触发noProgressCount归零。始终适用的关键规则Git 安全只按文件名暂存特定文件——git add -A或git add .有把用户无关的进行中工作或密钥提交进去的风险环境类失败立即退出OOM、命令未找到、权限拒绝等不是代码缺陷在这些问题上消耗本地修复预算纯属浪费闸门检查任何本地修复尝试前运行ci-state-update.mjs gate预算耗尽则打印消息并退出。修复动作流程fix-flowsfix-flows.md 详述了各状态的具体处置与三种修复动作流程。Apply via MCPMCP 应用派生 UPDATE_FIX 子代理执行APPLY。新 CI Attempt 会自动生成无需本地 git 操作。Apply Locally Enhance Flow本地应用 增强nx-cloud apply-locally shortLink状态置为APPLIED_LOCALLY增强代码以修复失败任务本地运行失败任务验证仍失败则运行ci-state-update.mjs gate --gate-type local-fix不允许则提交当前状态并推送让 CI 做最终裁判允许则回到增强循环通过则提交并推送进入等待模式。Reject Fix From Scratch Flow拒绝 从零修复gate --gate-type local-fix检查不允许则打印消息退出派生 UPDATE_FIX 子代理执行REJECT本地从零修复提交并推送进入等待模式。环境 vs 代码失败识别任何本地修复路径运行任务失败时先判断是代码问题还是环境/工具链问题再决定是否走闸门。环境/工具链失败指标非穷举命令未找到/二进制缺失、OOM/堆分配失败、权限拒绝、网络超时/DNS 失败、系统库缺失、Docker/容器问题、磁盘空间耗尽。检测到环境类失败应立即退出且不消耗预算代码类失败编译错误、测试断言失败、lint 违规、类型错误才是本地修复的正当候选。提交消息格式git commit -m fix(projects): brief description Failed tasks: taskId1, taskId2 Local verification: passed|enhanced|failed-pushing-to-ci闸门Gate机制与预算控制ci-state-update.mjs 提供三个子命令其中gate是预算控制的闸门gate --gate-type local-fix读取--local-verify-count与--local-verify-attempts默认 3超限返回{ allowed: false, message: Local fix budget exhausted }否则allowed: true并递增计数gate --gate-type env-rerun环境重跑上限硬编码为 2 次超限返回{ allowed: false, message: Environment issue persists after N reruns. Manual investigation needed. }。cycle-check中还能看到approachingLimit的判定maxCycles - 2与envRerunCount的非环境状态重置逻辑。这些脚本均为纯 Node 脚本#!/usr/bin/env node输入输出为 JSON 单行便于主 Agent 确定性解析这正是「决策由确定性脚本完成、判断由 Agent 完成」这一架构原则的体现。错误处理矩阵错误动作Git rebase 冲突报告用户退出nx-cloud apply-locally失败通过 MCP 拒绝修复action: REJECT然后尝试手动补丁Reject Fix From Scratch Flow或退出MCP 工具错误重试一次仍失败则报告用户子代理派生失败重试一次仍失败则报错退出决策脚本错误视为error状态递增no_progress_count未检测到新 CI Attempt若启用--auto-fix-workflow尝试 lockfile 更新否则报告用户并给出指引Lockfile 自动修复失败报告用户带「查看 CI 日志」的指引退出用用户指令覆盖默认行为用户可以在触发时提供自然语言指令覆盖任何默认行为常用示例指令效果never auto-apply应用任何修复前总是先询问always ask before git push每次推送前询问reject any fix for e2e tasks若failedTaskIds含 e2e 则自动拒绝apply all fixes regardless of verification跳过验证检查全部应用if confidence 70, reject应用前检查 confidence 字段run nx affected -t typecheck before applying增加本地验证步骤auto-fix workflow failures对 pre-CI-Attempt 失败尝试 lockfile 更新wait 45 min for new CI Attempt覆盖新 CI Attempt 超时默认 10 分钟在本仓库中的落地要点tsParticles 是一个使用 pnpm 工作区 Nx 组织的巨型 monorepo根 package.json 中有packageManager相关脚本如pnpm run prettify:readme nx run-many -t build --parallel50%。对应当前仓库nx.json 已配置nxCloudId因此monitor-ci技能可直接运行。实际使用时注意两点与仓库环境的衔接包管理器检测fix_needs_local_verify流程要求先探测包管理器——pnpm-lock.yaml存在则用pnpm nxyarn.lock存在则用yarn nx否则npx nx本仓库使用 pnpm 工作区对应pnpm nx前缀Git 安全仓库中包含大量子包与生成文件任何本地修复提交都必须按文件名精确暂存避免误提交无关变更。对于希望将此类「CI 监控 自愈修复编排」模式复用到自己 Nx 项目的团队可参考本仓库.cursor目录下的完整实现技能本体SKILL.md、修复流程细化fix-flows.md、决策脚本ci-poll-decide.mjs、状态脚本ci-state-update.mjs与子代理定义ci-monitor-subagent.md它们共同构成了一个职责分明、可确定性测试的 CI 编排方案。【免费下载链接】tsparticlestsParticles - Easily create highly customizable JavaScript particles effects, confetti explosions and fireworks animations and use them as animated backgrounds for your website. Ready to use components available for React.js, Vue.js (2.x and 3.x), Angular, Svelte, jQuery, Preact, Inferno, Solid, Riot and Web Components.项目地址: https://gitcode.com/GitHub_Trending/ts/tsparticles创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考