Desired Behavior
An agent-runnable skill for diagnosing self-hosted OpenHands Enterprise (Replicated VM-based) installs, usable by customers self-serving, by an FDE during a support call, or as a first-response step before escalating to the platform team.
It should triage the eight failure modes that recur across real installs — sandbox startup timeouts, git provider auth, certificate errors, LLM connectivity, Keycloak login, Replicated Admin Console access, stuck upgrades, and resource exhaustion — from a described symptom, pasted log output, or a support bundle. Recovery should validate each step before the next rather than only at the end, so a failed step is caught before a later one buries the evidence.
Support bundles need particular attention: the signal is spread across analysis.json, per-namespace pod objects, and node metrics, so the skill should summarise a bundle offline and rank findings into a most likely root cause rather than listing everything it sees. Where the bundle's own tooling misleads — warn-severity analyzers rendering under a FAIL heading, and per-object analyzers collapsing to one arbitrary example per family — the skill should say so, because both invite a confident wrong answer.
When an issue cannot be resolved, it should produce an escalation handoff stating what was tried, what the logs show, and the likely root cause.
Acceptance Criteria
Context
Implemented by PR #456. Derived from Linear PLTF-2910, which tracks the same work internally.
Known limitation to resolve before this can be trusted in the field: the skill hard-codes namespaces, label selectors, deployment names, and secret names that cannot be verified offline. A wrong selector returns No resources found and exits 0, which reads as "healthy" rather than "wrong query", so these need checking against a real install.
This issue was created by an AI agent (OpenHands) on behalf of @ai.vong.
Desired Behavior
An agent-runnable skill for diagnosing self-hosted OpenHands Enterprise (Replicated VM-based) installs, usable by customers self-serving, by an FDE during a support call, or as a first-response step before escalating to the platform team.
It should triage the eight failure modes that recur across real installs — sandbox startup timeouts, git provider auth, certificate errors, LLM connectivity, Keycloak login, Replicated Admin Console access, stuck upgrades, and resource exhaustion — from a described symptom, pasted log output, or a support bundle. Recovery should validate each step before the next rather than only at the end, so a failed step is caught before a later one buries the evidence.
Support bundles need particular attention: the signal is spread across
analysis.json, per-namespace pod objects, and node metrics, so the skill should summarise a bundle offline and rank findings into a most likely root cause rather than listing everything it sees. Where the bundle's own tooling misleads —warn-severity analyzers rendering under aFAILheading, and per-object analyzers collapsing to one arbitrary example per family — the skill should say so, because both invite a confident wrong answer.When an issue cannot be resolved, it should produce an escalation handoff stating what was tried, what the logs show, and the likely root cause.
Acceptance Criteria
warnunderFAIL,[xN]family collapse) are documented.kubectlinvocations parse,jqprograms compile, and no code block references an undefined shell variable.uv run pytest -qpasses andnpm run build:skillsregenerates the catalogue with no diff.Context
Implemented by PR #456. Derived from Linear PLTF-2910, which tracks the same work internally.
Known limitation to resolve before this can be trusted in the field: the skill hard-codes namespaces, label selectors, deployment names, and secret names that cannot be verified offline. A wrong selector returns
No resources foundand exits 0, which reads as "healthy" rather than "wrong query", so these need checking against a real install.This issue was created by an AI agent (OpenHands) on behalf of @ai.vong.