From 7457e983c7ef768443c7bfa79476b25c9216f44d Mon Sep 17 00:00:00 2001 From: Yogesh Rao Date: Thu, 14 May 2026 09:28:17 +0530 Subject: [PATCH] =?UTF-8?q?feat:=20improve=20mobius-error-id-skill=20score?= =?UTF-8?q?=20(59%=20=E2=86=92=2089%)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hey @eigengravy 👋 I ran your skills through `tessl skill review` at work and found some targeted improvements for `mobius-error-id-skill`. Here's the full before/after: | Skill | Before | After | Change | |-------|--------|-------|--------| | mobius-error-id-skill | 59% | 89% | +30% | | sip-flow-skill | 85% | — | unchanged | | architecture-endpoints-skill | 74% | — | unchanged | I picked `mobius-error-id-skill` because it had the most headroom — it's a useful skill that was missing a few structural pieces that help agents select and use it reliably.
Changes made **Description improvements (biggest impact):** - Added explicit "Use when..." clause with trigger conditions (error codes, response_status fields, call IDs, registration/call failures) - Listed concrete actions: decode error codes (101–5xx), trace call IDs, map HTTP response statuses to root causes - Added natural trigger terms users would say: "Mobius error", "debugging", "response_status", "registration failures" **Content improvements:** - Added "Error ID Formats" section documenting how Mobius errors appear in logs (HTTP status + mobius-error codes, response_status fields, device/call IDs) - Restructured workflow into clear 4-step diagnostic process: extract → look up → report → handle unknowns - Merged redundant "Error Detection and Root Cause Analysis" / "Root Cause Analysis" sub-bullets into a single clear step - Added concrete worked example showing a 503 SERVICE UNAVAILABLE registration failure, the lookup, and the root cause attribution
I also stress-tested your `mobius-error-id-skill` against a few real-world task evals and it held up really well on tracing 503 SERVICE UNAVAILABLE registration failures across SSE/CPAPI/Redis dependencies. Kudos for the thorough reference doc. Honest disclosure — I work at @tesslio where we build tooling around skills like these. Not a pitch — just saw room for improvement and wanted to contribute. Want to self-improve your skills? Just point your agent (Claude Code, Codex, etc.) at [this Tessl guide](https://docs.tessl.io/evaluate/optimize-a-skill-using-best-practices) and ask it to optimize your skill. Ping me — [@yogesh-tessl](https://github.com/yogesh-tessl) — if you hit any snags. Thanks in advance 🙏 --- .../skills/mobius_error_id_skill/SKILL.md | 27 ++++++++++++------- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/agents/analyze_agent_v2/skills/mobius_error_id_skill/SKILL.md b/agents/analyze_agent_v2/skills/mobius_error_id_skill/SKILL.md index 8a5d048..98ee03e 100644 --- a/agents/analyze_agent_v2/skills/mobius_error_id_skill/SKILL.md +++ b/agents/analyze_agent_v2/skills/mobius_error_id_skill/SKILL.md @@ -1,20 +1,29 @@ --- name: mobius-error-id-skill -description: Interpret Mobius error and call IDs from logs using the reference documentation. +description: "Decode Mobius error codes (mobius-error 101–5xx), trace call IDs, and map HTTP response statuses to root causes in Mobius logs. Use when analyzing Mobius log output containing error codes, response_status fields, call IDs, or registration/call failures and the user needs help debugging or understanding them." --- # Mobius Error ID Lookup -When analyzing Mobius logs, use this skill to interpret error IDs and call-related identifiers. +When analyzing Mobius logs, use this skill to decode error codes, trace call IDs to root causes, and map error patterns to known issues. -## Instructions +## Error ID Formats -1. **Identify Mobius error IDs and call IDs** in the logs you are analyzing (e.g. from `mobius_logs`, or any field containing Mobius error codes, call IDs, or tracking identifiers that map to known error semantics). +Mobius errors appear in logs as: +- **HTTP status + mobius-error code**: `403 FORBIDDEN — mobius-error 101` (registration), `503 SERVICE UNAVAILABLE` (transient backend failure) +- **response_status fields**: `fields.response_status: 503`, `fields.response_status: 404` +- **Call/device IDs**: `deviceId`, `sipCallId`, `USER_ID`, `DEVICE_ID` — used to correlate across services -2. **Consult the reference document** `references/mobius_error_ids.md` to look up each such ID. That document contains the authoritative mapping of Mobius error/call IDs to their meanings, causes, and remediation notes. +## Workflow -3. **Include the interpretation in your analysis:** - - In **Error Detection and Root Cause Analysis**: For each Mobius error ID found, state what the ID means (from the reference), likely cause, and suggested fix. - - In **Root Cause Analysis** (if applicable): Reference the documentation so your explanation is consistent with the defined semantics of each ID. +1. **Extract error identifiers** from the logs — look for `mobius-error` codes, HTTP status codes in `response_status` fields, and call/device IDs (`deviceId`, `sipCallId`, `correlationId`). -4. If an ID is not present in the reference document, say so and describe the ID and context so a human can triage or update the documentation. +2. **Look up each error** in `references/mobius_error_ids.md`. For each match, note the meaning, user/call impact, root cause direction, and what to check next. + +3. **Include findings in your analysis**: For each error ID, state what it means, the likely cause, the affected dependency (SSE, CPAPI, Redis, CI), and suggested next steps. + +4. **If an ID is not in the reference**, say so and describe the ID, surrounding context, and log fields so a human can triage or update the documentation. + +## Example + +A log line shows `Registration: Error code: 503 SERVICE UNAVAILABLE` with message `"No more retries left, failed to setup connection with all remote hosts"`. Look up **503 SERVICE UNAVAILABLE (registration)** in the reference — this means Mobius tried all SSE nodes and failed to connect. Root cause: SSE cluster or network issue. Next step: check SSE health and network path in the same time window.