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.

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Quality

Content

88%Weight 40%Scale 1-5

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

A strong, highly actionable diagnostic runbook with a clear stop-at-first-failure workflow and copy-paste commands throughout. Its main weakness is token efficiency: inline version pins and a few dense prose interpretation blocks could be tightened, and some of the extensive failure-scenario detail could live in a separate reference file.

Suggestions

Move time-sensitive version pins (e.g. claude-opus-4-6, openai-codex/gpt-5.4, ADR numbers) into a dedicated 'Versions / ADRs' or deprecated-patterns section so they don't bloat the live diagnostic prose.

Tighten the Layer 1 interpretation paragraphs (lines ~113-120) into a compact field-by-field table; the prose re-explains several status fields that a table would convey in fewer tokens.

Consider splitting the nine Known Failure Scenarios plus Fallback Controller State into a separate FAILURE-SCENARIOS.md reference, leaving SKILL.md as a concise overview that points one level deep.

Dimension	Reasoning	Score
Conciseness	The body is dense, operational reference material that mostly earns its tokens (artifact tables, error-pattern tables, copy-paste commands) without explaining concepts Claude already knows, but inline time-sensitive version pins ('claude-opus-4-6', 'gpt-5.4') and a few dense interpretation paragraphs (Layer 1) could be trimmed. It is clearly above the 'mostly efficient with some unnecessary explanation' midpoint but not fully lean.	4 / 5
Actionability	Every layer ships concrete, copy-paste-ready commands (joelclaw gateway diagnose, tail -100 /tmp/joelclaw/gateway.err, kubectl exec ... redis-cli, curl API probe), and every Known Failure Scenario gives specific symptoms/cause/fix steps with real commands.	5 / 5
Workflow Clarity	The procedure is explicitly sequenced ('Run these steps in order. Stop and report at the first failure.') across Layer -1 through Layer 8 with per-layer commands, failure patterns, and expected/failure/exception checkpoints, plus recovery feedback loops in the failure scenarios.	5 / 5
Progressive Disclosure	No bundle files exist, so this scores the body's own organization: clear top-level sections (CLI Commands, Artifact Locations, Diagnostic Procedure, Known Failure Scenarios, Architecture Reference) with outward references to Key Code / ADR anchors / Related Skills. It is well structured, though the lengthy Known Failure Scenarios and Fallback Controller sections are inlined rather than split into a detail file.	4 / 5
	Total	18 / 20 Passed

Description

100%Weight 40%Scale 1-5

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

An exemplary description: it states concrete diagnostic capabilities, lists natural trigger phrases for both 'what' and 'when', and explicitly disambiguates itself from the operational gateway skill. No vague fluff or over-claims.

Dimension	Reasoning	Score
Specificity	Names the domain and multiple concrete data sources ('reading daemon logs, session transcripts, Redis state, and OTEL telemetry') plus a full end-to-end path triage across named layers (daemon process → Redis channel → command queue → pi session → model API → Telegram delivery), giving comprehensive coverage.	5 / 5
Completeness	It explicitly answers both what (diagnose gateway failures via named telemetry sources and full path triage) and when (a concrete 'Use when:' clause with explicit trigger phrases), matching the top anchor.	5 / 5
Trigger Term Quality	The 'Use when' clause lists many natural phrases a user would actually say ('gateway broken', 'telegram not working', 'why is gateway down', 'check gateway logs', 'fallback activated', 'gateway stuck') plus a catch-all, giving comprehensive synonym coverage.	5 / 5
Distinctiveness Conflict Risk	It carves a clear diagnostic niche and explicitly states 'Distinct from the gateway skill (operations) — this skill is diagnostic', minimizing conflict risk with the sibling operations skill.	5 / 5
	Total	20 / 20 Passed

Validation

87%

Warnings & errors only

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

Validation — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning
relative_links	Relative link issues: 3 suspicious	Warning

	Total	14 / 16 Passed

Repository: joelhooks/joelclaw
Path: skills/gateway-diagnose/SKILL.md
Commit: d952451

Reviewed: 4 days ago

Table of Contents

Discovery Implementation Validation

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.