CtrlK
BlogDocsLog inGet started
Tessl Logo

gateway-diagnose

Diagnose gateway failures by reading daemon logs, session transcripts, Redis state, and OTEL telemetry. Full Telegram path triage: daemon process → Redis channel → command queue → pi session → model API → Telegram delivery. Use when: 'gateway broken', 'telegram not working', 'why is gateway down', 'gateway not responding', 'check gateway logs', 'what happened to gateway', 'gateway diagnose', 'gateway errors', 'review gateway logs', 'fallback activated', 'gateway stuck', or any request to understand why the gateway failed. Distinct from the gateway skill (operations) — this skill is diagnostic.

72

Quality

88%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Advisory

Suggest reviewing before use

SKILL.md
Quality
Evals
Security

Quality

Content

77%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a highly actionable and well-structured diagnostic skill with excellent workflow clarity — the layered diagnostic procedure with concrete commands and error pattern tables is exemplary. Its main weakness is length: at 400+ lines with no bundle files for progressive disclosure, it consumes significant context window. Some interpretation paragraphs (especially in Layer 1 status fields) are verbose and could be condensed into tables or bullet points.

Suggestions

Extract the 'Known Failure Scenarios' section (scenarios 0-7) into a separate FAILURE-SCENARIOS.md reference file to reduce the main SKILL.md size by ~40%

Condense the Layer 1 CLI Status interpretation paragraphs into a compact table mapping status fields to diagnostic meaning, rather than prose paragraphs

DimensionReasoningScore

Conciseness

The skill is extremely long (~400+ lines) with significant detail that is valuable for a complex diagnostic workflow, but includes some verbose explanations (e.g., lengthy interpretation guidance in Layer 1 CLI Status, detailed known failure scenario narratives). Some sections like the channel-health/channel-healing interpretation paragraphs could be tightened. However, much of the content is genuinely necessary reference material for a complex multi-layer diagnostic system.

2 / 3

Actionability

Excellent actionability throughout — every diagnostic layer has concrete, copy-paste-ready bash commands, specific log patterns to grep for, structured error pattern tables with meanings and fixes, and clear expected outputs. The CLI commands, kubectl commands, curl tests, and redis-cli queries are all fully executable.

3 / 3

Workflow Clarity

Outstanding workflow clarity with a clearly sequenced top-down diagnostic procedure (Layers -1 through 8) with explicit 'stop at first failure' instruction. Each layer has validation checkpoints, failure patterns with specific fixes, and the known failure scenarios include detailed recovery steps with feedback loops (e.g., watchdog auto-abort → retry → escalate pattern).

3 / 3

Progressive Disclosure

The skill references related skills (gateway, joelclaw-system-check, k8s) and key code files clearly, but the SKILL.md itself is monolithic — the known failure scenarios, fallback controller state, and architecture reference sections could potentially be split into separate reference files. No bundle files are provided to offload detail, so everything is inline in one very long document.

2 / 3

Total

10

/

12

Passed

Description

100%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is an excellent skill description that hits all the marks. It provides specific concrete actions and data sources, includes a comprehensive list of natural trigger terms, clearly separates 'what' from 'when', and explicitly differentiates itself from a related operational skill. The description is detailed without being padded, and uses proper third-person voice throughout.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions: reading daemon logs, session transcripts, Redis state, OTEL telemetry, and describes the full triage path (daemon process → Redis channel → command queue → pi session → model API → Telegram delivery).

3 / 3

Completeness

Clearly answers both 'what' (diagnose gateway failures by reading logs, Redis state, telemetry, full Telegram path triage) and 'when' (explicit 'Use when:' clause with extensive trigger phrases). Also distinguishes itself from a related skill.

3 / 3

Trigger Term Quality

Excellent coverage of natural trigger terms users would say: 'gateway broken', 'telegram not working', 'why is gateway down', 'gateway not responding', 'check gateway logs', 'fallback activated', 'gateway stuck', etc. These are realistic phrases a user would naturally use.

3 / 3

Distinctiveness Conflict Risk

Explicitly distinguishes itself from the gateway operations skill by stating 'Distinct from the gateway skill (operations) — this skill is diagnostic.' The specific diagnostic focus and trigger terms like 'diagnose', 'why is gateway down', 'review gateway logs' create a clear niche.

3 / 3

Total

12

/

12

Passed

Validation

90%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

10

/

11

Passed

Repository
joelhooks/joelclaw
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.