[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BSX7QYCTVJF85TFBCA2JVQ":3,"skill-same:01M6BSX7QYCTVJF85TFBCA2JVQ":49},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":22,"linkOnly":23,"markdownContent":24,"markdownBody":25,"frontMatter":26,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":30,"repositoryHtmlUrl":31,"repositoryHomepageUrl":32,"ownerHtmlUrl":33,"ownerBlogUrl":32,"ownerDescription":6,"updatedAt":34,"install":35,"resources":48},"01M6BSX7QYCTVJF85TFBCA2JVQ","llm-explanation",null,"Explains failures of LLM connections from their definition, their failed completions and the successes around them","zatosource\u002Fzato","zatosource","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F900466?v=4","01M6BSWH1DGG5H44DZJ7XY5R9P","ESB, SOA, REST, APIs and Cloud Integrations in Python","01M6BSWH5BGH69JBA2QQEVTZQT",1018,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002Fzatosource\u002Fzato\u002Fblob\u002Fmain\u002Fcode\u002Fzato-common\u002Fsrc\u002Fzato\u002Fcommon\u002Falerting\u002Fexplain\u002Fskills\u002Fllm\u002FSKILL.md",[],[19,20,21],"llm explanation","connections","definition","2026-11-10 10:12:30",false,"---\nname: llm-explanation\ndescription: Explains failures of LLM connections from their definition, their failed completions and the successes around them\n---\n\n# LLM connection explanation\n\nYou are explaining a failing LLM connection in a Zato environment. You receive an evidence\ndocument with four sections - Alert, Object, Failures and Baseline - and nothing else.\nEverything you say must follow from what is in them. Do not guess at causes the evidence\ndoes not support, and say when the evidence is not enough to tell.\n\n## How to read the evidence\n\nAlert - the rule that fired, the measures it compared and the thresholds it compared them against,\nboth as they were in force for this object, and the window the measures were taken over. A window\nof none means a reading taken at the time of the sweep. The \"Also measured\" line gives the other\nnumbers the sweep took at the same time. The message is what a person received. The rules are\n`Connection_Down`, `Slow_Completions`, `Slow_Completions_Error` and `Error_Rate`, then `Status_Codes`,\nwhich says the provider answered with one of the HTTP status codes the connection alerts on often enough,\n`Connection_Failures`, which says enough of its calls failed before any response arrived - a timeout,\na refused connection or a TLS failure - and the three that are the LLM's own: `Truncated_Completions`,\n`Refusals` and `Token_Budget`.\n\nA truncated completion is a reply the provider cut short because the connection's max tokens was reached -\nOpenAI says `length`, Claude `max_tokens`, Gemini `MAX_TOKENS`, and the evidence writes all three as\n`finish_reason=length`. A refusal is a reply the provider declined to give or a content filter blocked -\nOpenAI's `content_filter` or `refusal`, Claude's `refusal`, Gemini's `SAFETY`, `RECITATION`,\n`PROHIBITED_CONTENT`, `BLOCKLIST` or `SPII` on a candidate and a `promptFeedback.blockReason` on the prompt -\nwritten as `finish_reason=refusal`. Both arrive with an HTTP 200 and read as successes to everything but\nthe finish reason, so their Failures rows carry `200 OK` in their status and are not errors of the connection.\nA token budget alert adds the input and the output tokens of every call in the window and says the sum\ncrossed the budget - it has no failed rows at all, the numbers in the Alert are its whole evidence.\nA 429 is the provider's rate limit, a fault of the traffic or the account and not of the connection.\n\nObject - the connection's definition with the API key left out - its name, whether it is active,\nthe provider address, the model, the pool size, the timeout and the max tokens each reply may run to.\nWhen the connection has alert settings of its own, the `Alerts` line says whether they are on and the\n`Alert settings of its own` line gives the thresholds that differ from the defaults - among them the\nstatus codes the connection alerts on, with `429, 401, 403, 5xx` as the default, the truncation and\nrefusal thresholds, the two latencies in seconds and the token budget with its window.\n\nFailures - the calls the measures counted, newest first, grouped by their status and their text together,\nwith a count and the first and last time per group, and the provider address each group called. Every row\ncarries the model, the finish reason and the input and output tokens of its call, `model=gpt-4o,\nfinish_reason=length, input_tokens=1200, output_tokens=300`, next to its status. A call the provider\nrejected carries its HTTP status line, `429 Too Many Requests`, a call that never got a response carries\n`timeout`, `connection-error`, `tls-error` or `error` in its place, and a Gemini prompt block is an error\nrow with `finish_reason=refusal`. This section is the only one that may have been shortened to fit - when\nit was, a line at its end says how many older groups or how much of the lists were left out.\n\nBaseline - how many events succeeded in the same window and when the last one was, the current\nstreak of failures and the last success before it, and nothing about test transfers, which this source does not run. Use it to tell an outage from\na partial problem - an object with successes between its failures is not down.\n\n## Failure modes to consider\n\nRate limiting - HTTP 429 or the error text mentions rate limits, quotas or too many requests.\nThe traffic exceeds what the provider account allows. These calls are safe to repeat once\nthe window resets, but repeating them immediately reproduces the failure.\n\nAuthentication errors - HTTP 401 or 403, or the error text mentions an invalid API key. The key\nexpired or was rotated - the remedy is the connection's definition.\n\nProvider outages - HTTP 5xx or connection errors across every call in a stretch of time.\nThe provider is down or degraded. These are transient and the Baseline says whether the\nsuccesses have resumed.\n\nContext and payload errors - HTTP 400 or the error text mentions token limits, context length\nor an invalid request. The prompts themselves exceed what the model accepts - repeating\nthem unchanged will fail again.\n\nSlow completions - no errors, but the alert is about the average duration climbing. Either\nthe provider is degraded, the prompts grew, or the model behind the connection changed.\nSay which one the evidence supports.\n\nTruncated completions - the rows are `200 OK` with `finish_reason=length`, and their output tokens\nsit at or near the connection's max tokens. The replies are incomplete rather than wrong. The remedy is\nthe connection's max tokens or shorter prompts, and the Object says what the limit is now.\n\nRefusals - the rows are `200 OK` with `finish_reason=refusal`, or a Gemini error row with the same reason.\nThe provider or its content filter declined the prompts. Repeating them unchanged will be refused again -\nthe prompts, the skill behind them or the provider's safety settings are what a person should look at,\nand a burst of refusals from one model after a stretch of none may mean the provider tightened its filters.\n\nToken budget - no failures, the sum of tokens over the window crossed what the connection is allowed.\nThe split into input and output says whether the prompts grew or the replies did, and the Baseline's\ncount of calls says whether the traffic grew or each call got costlier.\n\n## What to produce\n\nReply with a single JSON object and nothing else - no markdown fences, no prose around it:\n\n{\n  \"explanation\": \"What failed, why, and what in the evidence says so - a few sentences of plain prose, naming times and counts from the evidence.\",\n  \"confidence\": \"low | medium | high\",\n  \"remediation\": null\n}\n\nConfidence is high when one failure mode explains every failure the alert counted and the\nBaseline agrees with it, medium when the failures are explained but the Baseline leaves\nroom for another reading, low when the error texts do not say enough to tell.\n\nNo automated remediation exists for this source yet - always set remediation to null and say\nin the explanation what a person should check or change.\n","# LLM connection explanation\n\nYou are explaining a failing LLM connection in a Zato environment. You receive an evidence\ndocument with four sections - Alert, Object, Failures and Baseline - and nothing else.\nEverything you say must follow from what is in them. Do not guess at causes the evidence\ndoes not support, and say when the evidence is not enough to tell.\n\n## How to read the evidence\n\nAlert - the rule that fired, the measures it compared and the thresholds it compared them against,\nboth as they were in force for this object, and the window the measures were taken over. A window\nof none means a reading taken at the time of the sweep. The \"Also measured\" line gives the other\nnumbers the sweep took at the same time. The message is what a person received. The rules are\n`Connection_Down`, `Slow_Completions`, `Slow_Completions_Error` and `Error_Rate`, then `Status_Codes`,\nwhich says the provider answered with one of the HTTP status codes the connection alerts on often enough,\n`Connection_Failures`, which says enough of its calls failed before any response arrived - a timeout,\na refused connection or a TLS failure - and the three that are the LLM's own: `Truncated_Completions`,\n`Refusals` and `Token_Budget`.\n\nA truncated completion is a reply the provider cut short because the connection's max tokens was reached -\nOpenAI says `length`, Claude `max_tokens`, Gemini `MAX_TOKENS`, and the evidence writes all three as\n`finish_reason=length`. A refusal is a reply the provider declined to give or a content filter blocked -\nOpenAI's `content_filter` or `refusal`, Claude's `refusal`, Gemini's `SAFETY`, `RECITATION`,\n`PROHIBITED_CONTENT`, `BLOCKLIST` or `SPII` on a candidate and a `promptFeedback.blockReason` on the prompt -\nwritten as `finish_reason=refusal`. Both arrive with an HTTP 200 and read as successes to everything but\nthe finish reason, so their Failures rows carry `200 OK` in their status and are not errors of the connection.\nA token budget alert adds the input and the output tokens of every call in the window and says the sum\ncrossed the budget - it has no failed rows at all, the numbers in the Alert are its whole evidence.\nA 429 is the provider's rate limit, a fault of the traffic or the account and not of the connection.\n\nObject - the connection's definition with the API key left out - its name, whether it is active,\nthe provider address, the model, the pool size, the timeout and the max tokens each reply may run to.\nWhen the connection has alert settings of its own, the `Alerts` line says whether they are on and the\n`Alert settings of its own` line gives the thresholds that differ from the defaults - among them the\nstatus codes the connection alerts on, with `429, 401, 403, 5xx` as the default, the truncation and\nrefusal thresholds, the two latencies in seconds and the token budget with its window.\n\nFailures - the calls the measures counted, newest first, grouped by their status and their text together,\nwith a count and the first and last time per group, and the provider address each group called. Every row\ncarries the model, the finish reason and the input and output tokens of its call, `model=gpt-4o,\nfinish_reason=length, input_tokens=1200, output_tokens=300`, next to its status. A call the provider\nrejected carries its HTTP status line, `429 Too Many Requests`, a call that never got a response carries\n`timeout`, `connection-error`, `tls-error` or `error` in its place, and a Gemini prompt block is an error\nrow with `finish_reason=refusal`. This section is the only one that may have been shortened to fit - when\nit was, a line at its end says how many older groups or how much of the lists were left out.\n\nBaseline - how many events succeeded in the same window and when the last one was, the current\nstreak of failures and the last success before it, and nothing about test transfers, which this source does not run. Use it to tell an outage from\na partial problem - an object with successes between its failures is not down.\n\n## Failure modes to consider\n\nRate limiting - HTTP 429 or the error text mentions rate limits, quotas or too many requests.\nThe traffic exceeds what the provider account allows. These calls are safe to repeat once\nthe window resets, but repeating them immediately reproduces the failure.\n\nAuthentication errors - HTTP 401 or 403, or the error text mentions an invalid API key. The key\nexpired or was rotated - the remedy is the connection's definition.\n\nProvider outages - HTTP 5xx or connection errors across every call in a stretch of time.\nThe provider is down or degraded. These are transient and the Baseline says whether the\nsuccesses have resumed.\n\nContext and payload errors - HTTP 400 or the error text mentions token limits, context length\nor an invalid request. The prompts themselves exceed what the model accepts - repeating\nthem unchanged will fail again.\n\nSlow completions - no errors, but the alert is about the average duration climbing. Either\nthe provider is degraded, the prompts grew, or the model behind the connection changed.\nSay which one the evidence supports.\n\nTruncated completions - the rows are `200 OK` with `finish_reason=length`, and their output tokens\nsit at or near the connection's max tokens. The replies are incomplete rather than wrong. The remedy is\nthe connection's max tokens or shorter prompts, and the Object says what the limit is now.\n\nRefusals - the rows are `200 OK` with `finish_reason=refusal`, or a Gemini error row with the same reason.\nThe provider or its content filter declined the prompts. Repeating them unchanged will be refused again -\nthe prompts, the skill behind them or the provider's safety settings are what a person should look at,\nand a burst of refusals from one model after a stretch of none may mean the provider tightened its filters.\n\nToken budget - no failures, the sum of tokens over the window crossed what the connection is allowed.\nThe split into input and output says whether the prompts grew or the replies did, and the Baseline's\ncount of calls says whether the traffic grew or each call got costlier.\n\n## What to produce\n\nReply with a single JSON object and nothing else - no markdown fences, no prose around it:\n\n{\n  \"explanation\": \"What failed, why, and what in the evidence says so - a few sentences of plain prose, naming times and counts from the evidence.\",\n  \"confidence\": \"low | medium | high\",\n  \"remediation\": null\n}\n\nConfidence is high when one failure mode explains every failure the alert counted and the\nBaseline agrees with it, medium when the failures are explained but the Baseline leaves\nroom for another reading, low when the error texts do not say enough to tell.\n\nNo automated remediation exists for this source yet - always set remediation to null and say\nin the explanation what a person should check or change.\n",{"name":5,"description":7},"main","ee14a521e114176adb68f4254058dffd4d3929f8","code\u002Fzato-common\u002Fsrc\u002Fzato\u002Fcommon\u002Falerting\u002Fexplain\u002Fskills\u002Fllm",250,"https:\u002F\u002Fgithub.com\u002Fzatosource\u002Fzato","https:\u002F\u002Fzato.io","https:\u002F\u002Fgithub.com\u002Fzatosource","2026-11-15 00:59:46",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add zatosource\u002Fzato --skill llm-explanation",{"tool":41,"command":42},"bunx","bunx skills add zatosource\u002Fzato --skill llm-explanation",{"tool":44,"command":45},"pnpm","pnpm dlx skills add zatosource\u002Fzato --skill llm-explanation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzatosource\u002Fzato\u002Fblob\u002Fmain\u002Fcode\u002Fzato-common\u002Fsrc\u002Fzato\u002Fcommon\u002Falerting\u002Fexplain\u002Fskills\u002Fllm\u002FSKILL.md",true,[],[50,70,80,90,99,112],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":54,"categories":55,"keywords":66,"publishedAt":22},"01M6BSXZX6XC519SAVMTXNJ530","sql-outgoing-explanation","Explains failures of SQL connections from their definition, their failed queries and the successes around them","https:\u002F\u002Fgithub.com\u002Fzatosource\u002Fzato\u002Fblob\u002Fmain\u002Fcode\u002Fzato-common\u002Fsrc\u002Fzato\u002Fcommon\u002Falerting\u002Fexplain\u002Fskills\u002Fsql-outgoing\u002FSKILL.md",[56,61],{"categoryNo":57,"categoryName":58,"taxonomyType":59,"taxonomyTypeDesc":60},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":62,"categoryName":63,"taxonomyType":64,"taxonomyTypeDesc":65},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[67,68,69,20,21],"sql","sql outgoing explanation","queries",{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":22},"01M6BSXXCT75K9BE42DCAHJH17","soap-outgoing-explanation","Explains failures of SOAP outgoing connections from their definition, their failed calls and faults and the successes around them","https:\u002F\u002Fgithub.com\u002Fzatosource\u002Fzato\u002Fblob\u002Fmain\u002Fcode\u002Fzato-common\u002Fsrc\u002Fzato\u002Fcommon\u002Falerting\u002Fexplain\u002Fskills\u002Fsoap-outgoing\u002FSKILL.md",[],[77,78,21,79,20],"soap","soap outgoing explanation","calls",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":22},"01M6BSXTXYW08R1JCEAD847FFV","scheduler-explanation","Explains failures of scheduler jobs from their failed runs and the runs around them","https:\u002F\u002Fgithub.com\u002Fzatosource\u002Fzato\u002Fblob\u002Fmain\u002Fcode\u002Fzato-common\u002Fsrc\u002Fzato\u002Fcommon\u002Falerting\u002Fexplain\u002Fskills\u002Fscheduler\u002FSKILL.md",[],[87,88,89],"scheduler","scheduler explanation","jobs",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":22},"01M6BSXRNTWVN596VQ7JBBFV17","rest-outgoing-explanation","Explains failures of REST outgoing connections from their definition, their failed calls and the successes around them","https:\u002F\u002Fgithub.com\u002Fzatosource\u002Fzato\u002Fblob\u002Fmain\u002Fcode\u002Fzato-common\u002Fsrc\u002Fzato\u002Fcommon\u002Falerting\u002Fexplain\u002Fskills\u002Frest-outgoing\u002FSKILL.md",[],[97,98,21,79,20],"rest outgoing explanation","REST",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":22},"01M6BSXP6BGKR034CXAPEF9WVA","rest-channel-explanation","Explains alerts of REST and SOAP channels from their definition, the calls they answered with an error and the callers behind them","https:\u002F\u002Fgithub.com\u002Fzatosource\u002Fzato\u002Fblob\u002Fmain\u002Fcode\u002Fzato-common\u002Fsrc\u002Fzato\u002Fcommon\u002Falerting\u002Fexplain\u002Fskills\u002Frest-channel\u002FSKILL.md",[],[106,107,98,21,79,108,109,110,111,77],"channel","rest channel explanation","with","channels","error","alerts",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":22},"01M6BSXKYYKNGT3K8YWHQKQV6Q","odoo-explanation","Explains failures of Odoo connections from their definition, their failed calls and the successes around them","https:\u002F\u002Fgithub.com\u002Fzatosource\u002Fzato\u002Fblob\u002Fmain\u002Fcode\u002Fzato-common\u002Fsrc\u002Fzato\u002Fcommon\u002Falerting\u002Fexplain\u002Fskills\u002Fodoo\u002FSKILL.md",[],[119,120,21,79,20],"odoo explanation","odoo"]