Agent skill
rca:kind
Root cause analysis on local Kind cluster - fast local debugging with full access
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/rca-kind
SKILL.md
RCA Kind
Root cause analysis workflow for failures on local Kind clusters.
When to Use
- Kind E2E tests failed locally or in CI
- Need to reproduce and debug CI Kind failures
- Ollama/agent issues specific to the Kind environment
Auto-approved: All read and debug operations on Kind clusters are auto-approved.
Cluster Concurrency Guard
Only one Kind cluster at a time. Before any cluster operation, check:
kind get clusters 2>/dev/null
- No clusters → proceed normally (create cluster)
- Cluster exists AND this session owns it → reuse it (skip creation, inspect directly)
- Cluster exists AND another session owns it → STOP. Do not proceed. Inform the user:
A Kind cluster is already running (likely from another session). Options: (a) wait for that session to finish, (b) switch to
rca:cifor log-only analysis, (c) explicitly destroy the existing cluster first withkind delete cluster --name kagenti.
To determine ownership: if the current task list or conversation created this cluster, it's yours. Otherwise assume another session owns it.
flowchart TD
START(["/rca:kind"]) --> GUARD{"Kind cluster?"}
GUARD -->|No clusters| CREATE["Deploy Kind cluster"]:::rca
GUARD -->|Owned| REUSE[Reuse existing]:::rca
GUARD -->|Another session| STOP([Stop - cluster busy])
CREATE --> P1["Phase 1: Reproduce"]:::rca
REUSE --> P2["Phase 2: Inspect"]:::rca
P1 --> P2
P2 --> P3["Phase 3: Diagnose"]:::rca
P3 --> P4["Phase 4: Fix and Verify"]:::rca
P4 --> RESULT{"Fixed?"}
RESULT -->|Yes| TDD["tdd:kind"]:::tdd
RESULT -->|No| P2
classDef rca fill:#FF5722,stroke:#333,color:white
classDef tdd fill:#4CAF50,stroke:#333,color:white
Follow this diagram as the workflow.
Workflow
Failure → Reproduce locally → Inspect cluster → Identify root cause → Fix → Verify
Create working directory for analysis:
mkdir -p /tmp/kagenti/rca
Phase 1: Reproduce
Deploy the cluster if not running:
./.github/scripts/local-setup/kind-full-test.sh --skip-cluster-destroy
Phase 2: Inspect
Check pod status:
kubectl get pods -n kagenti-system
Check for crashes:
kubectl get pods -n kagenti-system --field-selector=status.phase!=Running
Check events:
kubectl get events -n kagenti-system --sort-by='.lastTimestamp'
Phase 3: Diagnose
Check component logs:
kubectl logs -n kagenti-system deployment/kagenti-ui --tail=50
Check Ollama (Kind-specific):
kubectl logs -n kagenti-system deployment/ollama --tail=50
Check agent namespace:
kubectl get pods -n team1
kubectl logs -n team1 deployment/weather-service --tail=50
Phase 4: Fix and Verify
After fixing, re-run the specific failing test:
uv run pytest kagenti/tests/e2e/ -v -k "test_name"
Kind-Specific Issues
| Issue | Cause | Fix |
|---|---|---|
| Ollama OOM | Model too large for Kind | Use smaller model or increase Docker memory |
| DNS resolution | CoreDNS not ready | Wait or restart CoreDNS pod |
| Port conflicts | 8080 already in use | lsof -i :8080 and kill process |
| Image pull errors | Local registry not configured | Check kind-registry container is running |
Escalation
If the issue can't be reproduced locally, escalate:
- CI-only failure → Use
rca:cito analyze from logs - Need real OpenShift → Use
rca:hypershiftwith a live cluster
Related Skills
rca:ci- RCA from CI logs onlyrca:hypershift- RCA with live HyperShift clustertdd:kind- TDD workflow on Kindkind:cluster- Create/destroy Kind clustersk8s:pods- Debug pod issueskagenti:ui-debug- Debug UI issues (502, API, proxy)
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?